Most of the consumer internet you use every day routes through Fastly before it reaches you. When you load Shopify’s storefront infrastructure, GitHub’s repository pages, Reddit’s feed, Stripe’s checkout, the New York Times website, or any of dozens of other major brands, the bytes you receive were almost certainly served from a Fastly point-of-presence rather than directly from the brand’s origin servers. Fastly is one of the major edge cloud platforms, alongside Cloudflare and Akamai, that quietly handle the content delivery and edge compute infrastructure that the modern web depends on. It is also the platform whose June 2021 outage took down a substantial portion of the internet for an hour, including the BBC, Amazon, Reddit, and the UK government’s homepage, in one of the more memorable infrastructure incidents of the decade.
This piece is a foundational pillar on Fastly. We cover what the platform is, what it does, the product surface across content delivery and edge compute and security and media, the customer profile that explains the business, the pricing model that matters for evaluating it, and the place Fastly occupies in the edge cloud landscape relative to Cloudflare and the other major players. The goal is that after reading this, you can read any Fastly product page, any case study, or any discussion of edge architecture decisions and know what is being talked about.
The short version is that Fastly is the publicly-traded San Francisco-headquartered edge cloud platform founded in 2011 by Artur Bergman that operates a global network of points of presence (POPs) running customized Varnish caching servers, a WebAssembly-based serverless platform called Compute@Edge, image and video optimization APIs, the Next-Gen Web Application Firewall from the Signal Sciences acquisition, and a set of security and analytics products built on top of that infrastructure. It competes most directly with Cloudflare for similar workloads, with substantial overlap in capability and substantial difference in pricing model, customer profile, and engineering culture. Fastly’s brand position is "the developer-respected high-performance CDN that powers the brands you have heard of."
The founding story and what it explains
Fastly was founded in 2011 by Artur Bergman, who had previously been the operations engineer at Wikia (now Fandom) responsible for the Varnish-based caching infrastructure that kept Wikia running through massive traffic spikes. The founding insight was that the existing CDN market (dominated at the time by Akamai, with Limelight and EdgeCast as competitors) was built around the assumption that cache contents would change slowly, with TTLs measured in hours or days. This was wrong for the modern web. News sites needed to invalidate cached pages within seconds of editorial changes. E-commerce sites needed to invalidate product pages on inventory changes. Real-time applications needed cache behavior closer to a database than a static-asset store.
Fastly’s founding pitch was that it could invalidate any cached object across its entire global network within 150 milliseconds. This was a step-change improvement over the existing CDNs, where global cache invalidation could take minutes. The instant-purge capability was the wedge that got Fastly into customers who had previously found CDNs unusable for dynamic content. It is still a meaningful differentiator in 2026.
The second founding decision was to use Varnish as the caching engine rather than build a new caching layer from scratch. Varnish is an open-source HTTP accelerator with a powerful configuration language called VCL (Varnish Configuration Language) that lets operators express complex caching, routing, and transformation logic at the cache layer. Fastly built a customized commercial version of Varnish, extended VCL with platform-specific capabilities, and exposed VCL to customers as the configuration mechanism for their edge logic.
The VCL exposure is the third defining decision and the one that explains Fastly’s "developer-respected" brand position. Customers can write arbitrary VCL to control how their traffic is handled at the edge, including request routing, response manipulation, cache key construction, and conditional logic. This gives Fastly customers operational control that competing CDNs historically gated behind product-team feature requests. It also creates a learning curve that customers without engineering depth find off-putting, which is part of why Fastly’s customer base skews technical.
The edge POP network
Fastly operates approximately 90 points of presence globally as of mid-2026, with the network concentrated in major internet exchange points rather than distributed maximally widely. The Fastly POP architecture philosophy is that fewer, larger, better-connected POPs deliver better performance than more, smaller, less-well-connected POPs.
The architectural argument is that a smaller number of POPs at major peering exchanges have superior connectivity to the broader internet, which means traffic from end users reaches the POP through fewer network hops and with less latency variance than it would through a more-distributed network with worse peering. This is a different architectural philosophy from Cloudflare, which operates over 330 POPs globally and emphasizes geographic proximity, and from Akamai, which operates over 4,200 POPs and emphasizes worst-case geographic proximity above all else.
The architectural difference matters because the right strategy depends on the workload. Workloads dominated by cache hits benefit more from geographic proximity (the cached content is on the closest POP and the round-trip latency is short). Workloads dominated by cache misses benefit more from connectivity (the closest POP has to go back to origin anyway, so the right question is which POP has the best path back to origin). Fastly’s POP architecture is optimized for the second pattern, and Fastly’s customer base is heavy on workloads where the cache-miss path matters: e-commerce, news, dynamic API responses.
Fastly’s POP architecture also has implications for pricing. Each POP is more expensive for Fastly to build and operate than each Cloudflare POP because the Fastly POPs are bigger and more capable. The cost gets passed through to customers in the form of higher per-request pricing than Cloudflare charges. The pricing comparison is complicated because the workloads each platform is optimized for produce different request patterns, but the headline observation is that Fastly is meaningfully more expensive than Cloudflare for comparable raw bandwidth.
Compute@Edge
Fastly’s serverless edge compute platform is called Compute@Edge. It runs customer code at the edge POPs in response to incoming requests, allowing programmable edge logic that goes beyond what VCL can express. Compute@Edge is the platform’s bet on programmable edge as the future of CDN architecture.
The Compute@Edge execution model uses WebAssembly (Wasm) as the runtime. Customers write code in any language that compiles to Wasm (Rust, Go via TinyGo, JavaScript via SpiderMonkey-compiled-to-Wasm, AssemblyScript, and several others) and Fastly executes the Wasm modules in a sandbox at the edge. The cold-start time for Wasm modules is single-digit milliseconds, which is meaningfully faster than the JavaScript-V8-isolate cold-start of Cloudflare Workers (typically tens of milliseconds) and dramatically faster than the AWS Lambda@Edge cold-start (hundreds of milliseconds or more).
The fast cold start is the architectural differentiator. Compute@Edge can attach edge compute to every request without paying a meaningful latency penalty. This makes patterns like per-request authentication, per-request personalization, and per-request A/B testing viable in ways that slower-cold-start platforms struggle with.
The language story is also a differentiator. WebAssembly’s language-neutrality means Compute@Edge customers can write Rust for performance-critical paths, Go for general business logic, JavaScript for code-portability with browser frontends, all on the same platform. Cloudflare Workers is primarily a JavaScript runtime with limited support for other languages through Wasm compilation, which is more restrictive in practice than the Compute@Edge polyglot story.
The Compute@Edge limitations are real and worth being explicit about. The platform’s request-handling model is request-response: each request invokes a Compute@Edge function which returns a response. Long-running connections, WebSockets, and background processing are not first-class. The state model is also limited: persistent state across requests requires explicit storage in Fastly’s KV store, in an external database, or in a CDN-cached object. Customers expecting full backend capabilities find Compute@Edge restrictive; customers expecting fast programmable request handling find it more than sufficient.
VCL and the Varnish heritage
For customers who do not need the full programming power of Compute@Edge, the VCL configuration layer remains the primary way to express edge logic. VCL is the Varnish Configuration Language, a domain-specific language for HTTP request and response manipulation that has been the standard configuration mechanism for the Varnish caching engine since Varnish’s open-source release in 2006.
VCL is procedural and event-driven. A VCL file defines subroutines that get invoked at specific points in the request lifecycle: when a request arrives at the cache, when a cached response is being served, when a cache miss requires going back to origin, when an origin response is being received, when the response is being prepared for the client. Each subroutine can inspect the request and response state, modify headers, change the cache key, route to different origins, or return an early response.
Fastly’s customized VCL extends standard Varnish VCL with capabilities specific to the platform. The extensions include integration with Fastly’s logging streams, support for Fastly’s instant-purge invalidation system, integration with the image and video optimization APIs, integration with the security products, and access to Fastly’s edge dictionaries (the platform-managed key-value stores for VCL).
The VCL learning curve is steep. The language is unusual in modern web development, the procedural model is different from the request-handler patterns of modern frameworks, and the debugging tooling is primitive compared to general-purpose languages. Customers who have invested in learning VCL describe it as powerful and worth the investment. Customers who have not invested in learning VCL describe it as a barrier to using Fastly for complex configurations.
The relationship between VCL and Compute@Edge in the Fastly product strategy has evolved. Earlier in the platform’s history, VCL was the primary configuration mechanism and Compute@Edge was the newer alternative for advanced cases. The strategy through 2024-2026 has shifted toward Compute@Edge as the recommended path for new development, with VCL maintained for compatibility and for cases where VCL is genuinely the right tool. Most Fastly customers in 2026 use both, with VCL for cache control and request routing and Compute@Edge for application-specific edge logic.
Image and video optimization
Fastly’s image-optimization API resizes, transforms, and reformats images on the fly at the edge. The pattern is that customers serve their canonical images from origin in their original format and size, and Fastly transforms them per request based on URL parameters. A request to /images/hero.jpg?width=800&format=webp&quality=85 returns the canonical image resized to 800 pixels wide, converted to WebP, at 85 percent quality. The transformation is cached at the edge so repeated requests for the same transformation hit cache.
The image API is the platform’s response to the practical problem that most websites have images sized wrong for their actual display. A site with a hero image at 4,000 pixels wide that gets displayed at 800 pixels on a phone is wasting both bandwidth and bytes. The image API solves this by letting the browser-relevant image be generated on the fly, with the origin maintaining only the canonical high-resolution version.
The video API operates similarly for video content with adaptive bitrate streaming, low-latency HLS, and integrated DRM through partner providers. Video is a meaningfully smaller business for Fastly than images, both because the technical complexity is higher and because the customer base for video CDN services has consolidated around a few specialized providers (Mux, Cloudflare Stream) that Fastly has not directly competed against.
The image API in particular is a significant part of why some customers choose Fastly: the API is well-designed, the transformation quality is high, and the performance is good. Sites that are image-heavy (e-commerce especially) often see image API adoption as a primary driver of their Fastly relationship.
Security: Next-Gen WAF and bot management
Fastly acquired Signal Sciences in October 2020 for approximately $775 million. The acquisition brought in a Web Application Firewall (WAF) product that was widely regarded as one of the best in the market for defending modern web applications against the OWASP Top 10 vulnerabilities. The Signal Sciences product was rebranded as the Fastly Next-Gen WAF and integrated into the Fastly platform as the primary security product.
The Next-Gen WAF differs from older WAF approaches in several ways. The first is the detection model. Older WAFs work primarily through signature-based detection against known attack patterns, which means they require continuous signature updates and tend to produce many false positives on legitimate-but-unusual traffic. The Signal Sciences model uses behavioral detection: the WAF learns the normal behavior of each customer’s application and flags anomalies, with attack patterns identified by their effect on the application rather than by signature matching alone. The behavioral model produces fewer false positives and adapts to application changes without requiring signature updates.
The bot management product is the second pillar of Fastly’s security surface. It distinguishes between legitimate users, legitimate bots (search engine crawlers, monitoring tools, AI training crawlers), and malicious bots (scrapers, credential-stuffing tools, DDoS botnets, scalpers). The detection uses a combination of fingerprinting, behavioral analysis, and threat intelligence feeds. Customers configure which bot categories are allowed, which are challenged, and which are blocked.
The third security product is DDoS protection, which is largely a byproduct of the Fastly POP network’s capacity. A POP that can handle high traffic volumes for legitimate use can also absorb DDoS traffic without affecting customer applications. Fastly’s DDoS protection is comparable to the equivalents from Cloudflare and Akamai, with similar capacity and similar response times.
The security products together represent a meaningful fraction of Fastly’s revenue, particularly in the enterprise segment. Customers buying Fastly for content delivery often expand to the security products as a natural fit, and customers who came to Fastly through the Signal Sciences acquisition often expand to the content delivery products.
Real-time analytics and logging
Fastly’s real-time analytics and logging capabilities are notable for the speed at which data becomes available. Most CDNs have batch-oriented log processing that exposes log events to customers minutes or hours after the events occurred. Fastly’s logging pipeline exposes events within seconds, which makes the logs usable for real-time monitoring and alerting in ways that batch logs are not.
The logging system streams events to customer-chosen destinations (Splunk, Datadog, Elasticsearch, S3, Cloud Storage, BigQuery, and many others) in real time. Customers configure the log format using VCL, which means the logs can be tailored to capture exactly the fields the customer’s analytics pipeline needs. The flexibility is appreciated by operations-mature customers and can be overkill for customers who would prefer a default dashboard.
The real-time analytics dashboard exposes aggregate metrics on traffic volume, cache hit rates, response times, and error rates at second-level granularity. The dashboard is sufficient for operational monitoring; deeper analysis typically happens in the customer’s own analytics platform after the log stream lands there.
The customer profile
Fastly’s customer base skews toward engineering-heavy organizations with sophisticated infrastructure needs. The named customers (Shopify, GitHub, Stripe, Reddit, Spotify, The New York Times, BBC, Pinterest, Slack, Yelp, Vimeo, and so on) share a pattern: they have engineering teams capable of working with VCL or Compute@Edge, they have performance requirements that justify the higher pricing relative to Cloudflare, and they have brand equity such that an outage on their CDN provider is a major business event. Fastly’s pitch to these customers is that the platform’s reliability, performance, and configurability is worth the premium.
The customer profile creates a virtuous cycle. The engineering-heavy customer base produces a developer community that shares knowledge through blog posts, conference talks, and open-source tooling. The community attracts more engineering-heavy customers. The community-driven knowledge depth on VCL and Compute@Edge is meaningfully greater than the equivalent for any competing CDN.
The customer profile also creates limits. Customers without engineering depth find Fastly harder to use than competing CDNs that offer more out-of-the-box configurations. Customers without performance requirements that justify the premium pricing find Cloudflare or AWS CloudFront more economical. Customers without brand equity that justifies the reliability investment can be served well by lower-tier alternatives. Fastly’s addressable market is real but is a specific segment of the broader CDN market.
Pricing model
Fastly’s pricing is usage-based with several components. The first is request volume, billed per million requests. The standard rate is approximately $0.50 per million requests for content delivery, though enterprise contracts vary substantially. The second is bandwidth, billed per gigabyte transferred. The standard rate is approximately $0.12 per gigabyte for North America and Europe, with higher rates for other regions. The third is per-product fees for the optional surfaces: Compute@Edge requests, image transformations, security products, real-time analytics tiers.
The pricing structure has both advantages and disadvantages relative to competing CDNs. The advantages are that the pricing is transparent and that customers pay for what they use without committed-spend requirements. The disadvantages are that the pricing is meaningfully higher than Cloudflare’s and AWS CloudFront’s for equivalent raw bandwidth, and that the per-component pricing means total costs are harder to predict than Cloudflare’s flatter-rate structure.
The enterprise pricing model is different. Large customers negotiate committed-spend contracts that include the standard surfaces plus the optional products at predictable monthly rates. The committed-spend model is what Fastly’s largest customers operate under and is the basis for the company’s revenue forecasting. Customers in the middle (substantial usage but not enterprise scale) often find that the usage-based pricing produces meaningful month-to-month variance that the committed-spend contracts would smooth out.
When Fastly is the right choice
Fastly is the right choice for organizations with engineering depth, performance-critical workloads, and brand-equity-justified reliability requirements. The pattern is clearest for major consumer-internet brands, e-commerce at scale, news and media properties, and developer-tools companies whose customers expect their CDN provider to perform well.
Fastly is not the right choice for organizations primarily optimizing for cost. The pricing premium is real and the lower-cost alternatives (Cloudflare, AWS CloudFront, BunnyCDN) serve most workloads well enough at meaningfully lower cost. Organizations whose CDN spend is in the hundreds of dollars per month rather than the tens of thousands are usually better served by the cost-optimized alternatives.
Fastly is also not the right choice for organizations without engineering capacity to work with VCL or Compute@Edge. The platform’s power comes from its configurability, and configurability requires engineering investment. Organizations expecting a click-and-deploy CDN experience find the lower-touch alternatives a better fit.
The platforms most often compared against Fastly in enterprise procurement are Cloudflare Enterprise, Akamai, and (increasingly) Vercel for sites that fit the Vercel platform’s deployment pattern. Each has a different position. Cloudflare Enterprise has comparable capabilities to Fastly at meaningfully lower pricing but with a less mature edge-compute story for advanced configurations. Akamai has the largest POP network and the most established enterprise relationships but with a more conservative product surface and higher friction for engineering-driven workflows. Vercel offers a much more opinionated workflow that fits Next.js sites particularly well but lacks the general-purpose edge cloud capabilities of Fastly.
Frequently asked questions
Is Fastly a CDN or an edge cloud platform? Both, depending on the framing. Fastly started as a CDN and has expanded into the broader edge cloud category through Compute@Edge, security products, and image and video optimization. The company’s own positioning emphasizes "edge cloud" because that better describes the current product surface, but the CDN business is still the largest revenue contributor.
Can I use Fastly without writing any VCL or Compute@Edge code? Yes. Fastly has a web-based configuration UI that exposes the common patterns (caching policies, origin shielding, redirects, basic security rules) without requiring code. The web UI generates VCL under the hood, but customers do not need to interact with the VCL directly for these patterns. The web UI is sufficient for simpler use cases.
How does Fastly handle the 2021 outage incident in its current reliability story? The June 2021 outage was caused by a configuration change that triggered a bug in Fastly’s software, taking down most of the global POP network for an hour. Fastly’s published post-incident analysis identified the specific bug and described the changes to prevent recurrence. The company’s reliability since the incident has been strong; there has not been a comparable outage in the four years since. The incident is referenced in Fastly’s enterprise sales conversations as an example of the company’s incident response transparency.
Is Compute@Edge a competitor to AWS Lambda or to Cloudflare Workers? More directly to Cloudflare Workers. Both Compute@Edge and Cloudflare Workers are edge serverless platforms focused on programmable HTTP request handling. AWS Lambda is a general-purpose serverless platform that runs in AWS regions rather than at the edge, with Lambda@Edge as the edge variant. The Compute@Edge and Cloudflare Workers comparison is the one most customers actually evaluate.
Does Fastly work with WordPress? Yes, with no special integration required. WordPress sites configure their DNS to point at Fastly, configure Fastly to use the origin server’s URL, and Fastly handles the content delivery. There are WordPress plugins (most notably the Fastly Cache Maintainer plugin) that help with cache invalidation when WordPress content changes, but the core CDN integration does not require any WordPress-specific configuration.
Can Fastly serve static sites generated by Hugo, Jekyll, or other static site generators? Yes. Static sites are the easiest case for any CDN, and Fastly handles them well. The pattern is to deploy the static output to an origin (S3, GitHub Pages, a simple web server) and point Fastly at the origin. The static content is cached aggressively at the edge.
How does Fastly’s pricing compare to Cloudflare for a small site? Cloudflare is meaningfully cheaper for small sites. Cloudflare’s free tier handles substantial traffic at no cost, and the entry-tier Pro plan is $20 per month. Fastly does not have a free tier; the minimum bill for a Fastly customer is determined by usage with a small monthly fee for the account. A small site might spend $10 per month on Fastly vs $0 on Cloudflare’s free tier. The Fastly value proposition is not for cost-sensitive small sites; it is for performance-sensitive workloads at scale.
Does Fastly support HTTP/3 and QUIC? Yes. Fastly was an early adopter of HTTP/3 and QUIC, with support across the POP network. Most modern browsers will use HTTP/3 when negotiating with Fastly POPs, and the protocol is enabled by default for customers without requiring configuration.
Is Fastly a public company? Yes. Fastly went public on the New York Stock Exchange (NYSE: FSLY) in May 2019. The company’s financial reports are public and provide useful insight into the customer mix, revenue concentration, and growth dynamics.
How does Fastly relate to the broader edge cloud trend? Fastly is one of the original edge cloud companies and has been instrumental in defining the category. The trend toward programmable edge compute, real-time configuration, and unified security-plus-delivery products is largely a story that Fastly, Cloudflare, and a few smaller players are jointly writing. The trajectory points at edge clouds doing more of the work that previously happened at origin, with origin servers becoming smaller and more focused.
