Fastly and the programmable edge that reshaped content delivery

Executive Summary

• Fastly, Inc. was founded in 2011 and is headquartered in San Francisco. The company emerged from founder Artur Bergman’s experience operating Wikia, where stale content, weak visibility and inflexible CDN controls turned delivery into an application-development problem rather than a simple bandwidth purchase. Fastly later became a public company and, by 2026, reported its business through Network Services, Security and Other products that include Compute and Observability.
• Fastly’s defining infrastructure contribution is a programmable edge model built around Varnish-derived caching, versioned configuration, application-controlled invalidation, real-time log streaming and a WebAssembly execution environment. It publicly reports 578 Tbps of connected capacity and a mean global purge time below 150 milliseconds as of the dates stated by the company, but those figures do not establish uniform latency, cache residency or resilience across every access network and region.
• The platform controls Fastly’s edge servers, software-defined request handling, cache policy, security enforcement and execution environment. It does not control customer origins, application correctness, global BGP decisions, third-party data centres, transit networks or end-user access. Its value therefore comes from coordinating a programmable intermediary across dependencies it can influence but cannot command.
• Fastly’s 2021 global outage remains the clearest public test of that responsibility surface: an undiscovered software bug, introduced weeks earlier, was triggered by a valid customer configuration and caused 85% of the network to return errors. Fast recovery limited the duration, but the incident showed how rapid configuration and common software can turn developer agency into correlated failure. Any assessment of Fastly must therefore examine not only speed and feature breadth, but isolation, rollback, origin resilience, customer concentration and the practical portability of logic placed at the edge.

A company built around the problem of stale content

Fastly emerged from a practical weakness in the early CDN market. Content delivery networks were already good at placing copies of files closer to users, reducing latency and easing pressure on origin servers. They were less effective when content changed frequently. Updating or removing cached material could be slow, difficult to observe and poorly integrated with the way application teams deployed software.

That trade-off was especially visible in publishing and other fast-moving online services. Caching more content improved performance, but it also increased the risk that users would see outdated articles, prices, API responses or software assets. Caching less kept information current, but returned more traffic to the origin and reduced the economic value of the CDN.

Fastly’s founding idea grew from Artur Bergman’s experience as chief technology officer at Wikia, where pages changed frequently and traffic could shift without warning. The problem was not simply moving content closer to users. It was giving developers more direct control over what happened after it reached the edge. Fastly built its platform around rapid configuration, real-time visibility and selective cache invalidation, allowing application teams to treat delivery behaviour as part of the software system rather than as a separate operational service.

That proposition changed the unit of value. Bandwidth and server location remained essential, but the differentiator became control over distributed state. Fastly was selling the ability to make a large cache behave like part of a software system. The more an application depended on that ability, the less accurate it became to treat the CDN as a replaceable pipe. Delivery configuration moved into application architecture, and the edge began to inherit the governance obligations normally associated with production code.

The public identity is clear; the operating surface is wider

Fastly, Inc. is a Delaware corporation founded in 2011 and headquartered in San Francisco. Its Class A common stock trades under the symbol FSLY, and its public filings describe an edge cloud platform spanning Network Services, Security and an Other category containing Compute and Observability. These facts identify the company and its product reporting structure. They do not by themselves define the infrastructure surface that customers delegate to it.

The operating surface begins with reverse-proxy delivery. User requests are directed to Fastly rather than immediately to the customer’s origin. Fastly can answer from cache, transform the request, apply security policy, choose an origin, execute code, record telemetry or reject the request. Each capability is bounded, but together they place the platform in the path of application availability and policy. A customer may use only caching, or may combine delivery with a web application firewall, DDoS mitigation, bot controls, API protection, edge compute and provider-hosted data stores.

This breadth creates a distinction between product count and dependency depth. Two customers may buy the same named service while relying on it differently. One might cache public images and retain a direct origin path. Another might run authentication-adjacent logic, route requests among backends, enforce security policy and stream all observability through Fastly. Public customer totals and product descriptions cannot reveal that difference. The significant metric is not simply how many organisations have accounts, but which functions they cannot perform when the platform is unavailable.

Fastly’s responsibility is correspondingly specific. It controls the software and servers in its points of presence, the platform through which configurations are created and activated, and the execution and security functions it offers. Customers control application intent, origin behaviour, credentials, data and many configuration choices. Internet service providers, transit networks and exchange points control reachability outside Fastly’s domain. Colocation companies supply physical facilities. The user experiences one application, but operational control is divided among several parties.

Wikia made freshness and developer control the founding problem

The Wikia origin story matters because it explains why Fastly’s product language has long centred on developers. A large collaborative site does not change according to a fixed publishing schedule. Popular pages may be edited many times, and demand can shift rapidly after news, entertainment releases or community events. The platform needs the efficiency of caching without allowing the cache to become an obstacle to visible change.

Traditional operational workflows often placed the CDN behind a ticket, a separate console or a provider-managed configuration process. Application teams could deploy code in minutes while delivery changes followed a slower cycle. That mismatch created a hidden release dependency. A correct origin deployment could remain invisible because an old object persisted at the edge, or a team could avoid caching dynamic material because it lacked confidence in invalidation.

Fastly treated this mismatch as a systems-design problem. Edge rules should be expressible, testable and activated through an API. Invalidation should be addressed by key and triggered from application workflows. Logs should leave the edge quickly enough to support investigation rather than arriving as a retrospective batch. The delivery layer would still be operated by Fastly, but application teams would receive a more immediate control surface.

The idea was commercially attractive because web architecture was changing. Sites were becoming API-driven, releases were becoming more frequent and engineering organisations were adopting automation. A delivery service that could fit into those workflows offered value beyond raw throughput. The same fit also increased the consequences of mistakes. When edge behaviour can change as quickly as application code, the organisation needs review, staging, access control and rollback that match the speed of the platform.

Fastly entered a CDN market designed mainly around static distribution

The first generation of commercial CDNs was shaped by a web dominated by images, downloadable files and pages whose changing parts were often generated at a central origin. Caching static objects was valuable because the objects could remain valid for long periods. Dynamic requests were harder: they were personalised, frequently updated or dependent on transactions that only the origin could complete.

Fastly did not eliminate that distinction. It changed how much of the dynamic path could be controlled at the edge. A request could be normalised before cache lookup, routed according to headers, authenticated in limited ways, assigned a cache key that reflected application semantics or passed to a selected backend. A response could be cached for one audience and not another. The edge could make decisions that previously required origin code or a dedicated appliance.

This capability expanded the addressable workload but made the word “dynamic” easy to overstate. If a request requires a current database transaction, private user state or business logic not present at the edge, the origin remains necessary. Fastly can reduce network delay, collapse repeated work and move selected computation outward. It cannot make the source system irrelevant. The platform’s value depends on identifying which parts of a request are safe to cache, precompute, transform or execute near users.

The practical innovation was therefore not a claim that every dynamic application could be served without an origin. It was a more granular model of where work could occur. That model gave developers control over the boundary between edge and origin. It also required them to understand cache keys, variation, authentication, error behaviour and data sensitivity. Flexibility expanded the space of good designs and bad ones at the same time.

Varnish made cache semantics an application interface

Fastly’s delivery platform grew from Varnish Cache, an open-source HTTP accelerator designed around configurable request processing. Varnish Configuration Language allows operators to describe how requests and responses should be classified, cached, passed, redirected or modified. Fastly adapted that model for a multi-tenant global service and exposed a managed control plane around it.

The significance of Varnish was not only performance. It made cache behaviour programmable in a language that could express application-specific policy. Instead of treating the cache as a black box with a small set of knobs, engineers could make decisions at stages of the request lifecycle. A team could remove tracking parameters from a cache key, select a backend according to geography, protect an origin from particular methods or set different cache lifetimes for different response classes.

Programmability introduced a new form of coupling. An application’s correctness could depend on edge code that lived outside the origin repository, or on generated configuration assembled through an API. A change in a header, cookie or URL pattern could alter whether users shared a cached response. A seemingly small rule could produce data leakage, cache fragmentation or unexpected origin load. The cache had become a policy engine, so its configuration deserved the same design scrutiny as other production software.

Fastly has added higher-level interfaces, managed products and Compute, but the Varnish lineage still explains the company’s identity. The edge is not simply a place where content rests. It is a programmable request-processing environment. That distinction is the source of Fastly’s appeal to sophisticated teams and of the learning curve identified in the research briefing. Developer control is useful only when the organisation has the expertise to exercise it safely.

Service versions turn edge configuration into release engineering

Fastly configurations are organised through service versions that can be cloned, edited, validated, locked and activated. The model creates an explicit distinction between a draft and the version currently serving traffic. This sounds administrative, but it is a crucial infrastructure property: a distributed change needs an identifiable artefact, a point of activation and a path back to a known state.

Versioning makes automation possible. A pipeline can generate or update configuration, test it against expected behaviour and promote it through environments. Teams can review changes rather than editing an opaque live state. The model also supports rollback by reactivating a previous version, provided that other dependencies remain compatible. Configuration becomes part of release engineering rather than an informal support procedure.

The safety benefit depends on how customers use the feature. A version can be syntactically valid while containing a bad assumption about traffic. A staging environment can miss a production-only header or customer segment. A rollback can restore edge rules while leaving a newly deployed origin schema incompatible. Fast activation shortens the time between decision and effect, but it cannot replace representative tests or coordinated releases.

The control plane therefore creates both leverage and a common dependency. Customers need it to publish changes, and Fastly needs to distribute those changes correctly across the network. The platform must isolate one service from another, ensure that invalid state does not corrupt shared components and provide evidence about what version was active during an incident. The history of the 2021 outage shows why that separation must extend below the customer configuration layer into the software that interprets it.

Freshness is a state-management problem, not a timer setting

A cache stores a representation of a resource together with rules about when it may be reused. The simplest rule is time: keep the object for a stated interval, then ask the origin again. That model works when change is predictable and short periods of staleness are harmless. It becomes expensive when objects change irregularly or when a single update must appear quickly around the world.

Application-controlled invalidation changes the model. The origin or publishing system can tell the edge that an object is no longer current. More powerful schemes associate several objects with a shared key so that a product, article, user-facing page or API collection can be invalidated as a group. The cache lifetime can remain long for efficiency while the application retains a route to freshness.

This is distributed state coordination. An invalidation event must be accepted, authenticated, propagated and applied to the relevant cache entries. Concurrent requests may arrive while that process occurs. Some objects may not be resident in every location. A replacement request may reach an origin that is itself updating. The edge can make the operation fast, but it cannot turn it into a single atomic write across the public internet.

Fastly’s public purge metrics are therefore most useful as measurements of the provider’s propagation system under stated conditions. They do not mean that every user immediately receives a newly generated object. Application correctness still depends on cache keys, surrogate-key assignment, origin behaviour and the difference between deleting an object and marking it stale. The infrastructure enables a disciplined freshness strategy; it does not supply one automatically.

Instant Purge changed the economics of caching dynamic content

Rapid purge made it rational to cache material that teams previously considered too volatile. If invalidation takes minutes or requires a provider ticket, a publisher may choose a short lifetime and accept frequent origin requests. If the application can invalidate globally through an API in a fraction of a second on average, it can keep objects longer and purge only when the source changes.

The economic effects extend beyond latency. Higher cache hit rates reduce origin compute, database work and egress. During a traffic surge, an object already resident at the edge can absorb repeated demand without scaling the origin at the same rate. A news site, commerce platform or software distributor can prepare for peaks by separating the cost of first generation from the cost of repeated delivery.

Fastly’s use of surrogate keys is particularly important because application entities rarely map cleanly to one URL. A product can appear on detail pages, category lists, search results and recommendation feeds. Tagging those representations with a common identifier lets the application invalidate the entity rather than enumerate every location where it appears. The CDN becomes aware of logical relationships supplied by the customer without needing access to the underlying database.

This technique illustrates the company’s broader model: keep the platform general, then let developers provide domain meaning. The edge knows how to distribute and invalidate; the application knows which objects belong together. The boundary is powerful because neither side needs to own the other’s system. It is fragile when tagging is incomplete, keys are reused incorrectly or publishing workflows fail to emit the event. Operational quality depends on the integration, not on purge speed alone.

Purge speed is useful but not the same as global consistency

Marketing language around instant purge can suggest a single moment at which the old object ceases to exist everywhere. A distributed cache is more complicated. Some points of presence may not hold the object. Requests can race with invalidation. A soft purge may mark content stale and allow controlled reuse while revalidation occurs. A hard purge removes it and can create a burst of origin demand if many locations miss at once.

The choice is an application decision. Hard invalidation may be necessary for a legal removal, security issue or incorrect price. Soft invalidation can protect availability by letting the edge serve a stale object while one request retrieves a replacement. The platform offers mechanisms, but the customer defines the acceptable balance between freshness, origin pressure and continuity.

Consistency also crosses systems outside Fastly. A customer may purge the edge before a new origin version is available in every region. An API may update one database replica before another. Browser caches and downstream proxies may retain their own copies. The CDN can coordinate its managed layer while the user-visible result still depends on the full content path.

A responsible interpretation of the published mean purge time is therefore bounded. It is evidence that Fastly has engineered a rapid global invalidation system. It is not a universal guarantee about every object, client or application state. Leaders evaluating the service should ask what percentile and failure behaviour matter to their workload, how purge events are monitored and what happens when the origin cannot absorb the refill that follows.

Fewer, higher-capacity points of presence are a deliberate topology choice

Fastly describes its network as intentionally composed of fewer but more powerful points of presence than some competing CDN architectures. The rationale is that a high-capacity location can retain a larger working set, concentrate operational investment and connect deeply to internet exchanges and major networks. A cache with enough storage and throughput to keep more requested objects can avoid forwarding as much traffic to another tier or to the origin.

The design resists a simplistic equation between node count and performance. A small server embedded in many access networks may be physically close to users but limited in the content it holds or the traffic it can absorb. A larger regional site may sit slightly farther away yet answer more requests locally, maintain more capable compute and security functions and connect to a wider set of networks. The useful comparison is not how many dots appear on a map, but the combination of capacity, network adjacency, cache residency and route quality.

Concentration introduces trade-offs. A high-capacity POP carries more traffic and therefore represents a larger local failure domain. Users in regions without nearby Fastly capacity may depend on longer paths or expensive international connectivity. Capacity added in one metro does not automatically improve access from every network in the surrounding country. The company’s public network map identifies locations and aggregate connected capacity, but it does not reveal the independent power, fibre and upstream diversity behind each site.

The architecture should therefore be evaluated as a portfolio of regional systems rather than a single global number. Fastly can choose where to invest, how much equipment to install and which peers to establish. It cannot choose where every user’s access provider sends traffic or guarantee that a nominally nearby route is the best path. The network strategy creates a particular balance between efficiency and proximity; it does not abolish the geography and economics of the internet.

Peering and colocation connect software control to physical dependency

Every programmable edge decision ultimately runs on hardware in a facility and sends packets through another organisation’s network. Fastly leases colocation space, purchases bandwidth, installs servers and establishes peering or transit relationships. Its autonomous system exchanges traffic with internet service providers and content networks using both IPv4 and IPv6. These arrangements are the physical substrate beneath the control plane that developers see.

Peering can improve performance and cost by allowing Fastly and another network to exchange traffic directly rather than through a paid intermediary. It can also place content closer in topology even when the server is not inside the access network. The result depends on traffic volumes, port capacity, routing policy and the location of the interconnection. A peering relationship is not a promise that every path will remain uncongested or that both sides will expand capacity at the same pace.

Colocation adds another layer of divided responsibility. Fastly operates its equipment, while the facility supplies power, cooling, physical security and access to connectivity. A failure in electrical distribution, an equipment fault or a maintenance error can affect the site without originating in Fastly’s software. The company can design redundancy and move traffic, but not every component has an identical substitute in the same moment or metro.

These dependencies matter commercially because network service provider fees, colocation charges, hardware depreciation and operational labour enter the cost of revenue. Expanding capacity before customer demand arrives can depress margins; expanding too late can reduce performance or limit the ability to absorb an attack. The software-defined edge is therefore also a forecasting business. Fastly has to place physical capacity under uncertainty while presenting customers with an apparently elastic service.

Fastly can select paths inside its system but cannot command BGP

Fastly’s software can use health checks, backend selection and routing features to choose among origins or paths available to the platform. It can withdraw an unhealthy edge route, steer requests toward another POP or use internal logic to avoid a failing backend. This is meaningful operational control, but it exists within the constraints of global routing.

BGP decisions are made by independent autonomous systems according to their own policies and learned routes. An access provider may prefer a path that is commercially attractive rather than geographically shortest. A route leak, filtering error or congested interconnection can alter reachability before Fastly receives a request. The company can announce prefixes, peer widely and engineer its network, but it cannot issue instructions to every upstream and last-mile operator.

This boundary explains why “global network” must not be translated into “global path control.” Fastly controls how its own infrastructure responds once traffic reaches it and how it sends traffic toward configured origins. It influences the surrounding network through placement and interconnection. The complete user-to-edge-to-origin path remains a collective product of routing policy, physical capacity and endpoint behaviour.

Operational diagnosis must preserve that distinction. A high latency report can originate in the access network, the route to the POP, Fastly’s processing, the path to the origin or the origin itself. Real-time logs can show timing at the edge, while traceroutes, provider telemetry and origin metrics reveal other segments. A useful incident process assembles those views instead of treating the CDN as either responsible for everything or responsible only for its own servers.

The origin remains the source of truth and the dependency of last resort

A CDN can answer a large share of requests without contacting the origin, but it cannot invent authoritative content that the application has never supplied. The origin remains the source of truth for cache misses, expired objects, private transactions and any logic that has not been moved to the edge. The stronger the cache strategy, the easier it can be to forget how much the application still depends on that system during a miss storm or configuration change.

Origin design affects edge performance. If the source responds slowly, the first request for an uncached object remains slow. If it applies strict connection limits, simultaneous misses from several POPs can overload it. If it returns inconsistent cache headers, the platform may store too little or too much. If authentication rules depend on headers altered at the edge, subtle mismatches can appear only in production.

Fastly provides mechanisms to route among several backends and monitor their health. Customers can place origins in multiple regions or clouds, define failover and select a backend according to request attributes. Those capabilities do not create diversity when all backends share one database, identity provider or deployment pipeline. A diagram with several origin addresses can conceal a common dependency deeper in the application.

The correct responsibility split is therefore collaborative. Fastly must deliver configured requests, expose useful timing and protect the platform from shared failures. The customer must understand origin capacity, cacheability, data correctness and failover semantics. Cloud and network providers must operate their systems. Availability is produced by the combined path. Contracting with an edge provider transfers work, but it does not transfer the need to model the whole service.

Origin Shield and request collapsing trade repeated work for concentration

When the same uncached object is requested in many edge locations, a naive CDN can send a burst of near-simultaneous requests to the origin. Fastly’s shielding model designates an intermediate POP that fetches the object and supplies it to other edge locations. Request collapsing can allow one in-flight fetch to satisfy several waiting requests. These techniques reduce duplicate origin work and can improve cache efficiency.

The benefit is substantial during a release or sudden traffic event. Instead of every edge location independently retrieving a large object, the shield becomes a shared upstream cache. The origin sees fewer connections and can serve more stable demand. The customer may also simplify access controls by allowing traffic from a smaller set of Fastly locations.

The trade-off is concentration. The shield carries more responsibility for the protected origin and introduces another cache and network segment. If the selected shield is poorly placed relative to the origin, it can add latency. If it fails or becomes overloaded, many downstream locations may be affected at once. A configuration that assumes the shield always holds an object can behave differently after eviction or restart.

Shielding is therefore an architectural choice, not a free optimisation. It should be selected according to origin location, traffic pattern and failure tolerance. Customers need to observe shield hit rates, fetch latency and origin load, then test what happens when the shield path changes. The mechanism demonstrates a recurring property of distributed systems: efficiency is often gained by creating a new aggregation point, and that aggregation point must then be treated as a dependency.

Grace modes improve continuity by making staleness an explicit policy

A strict cache might refuse to serve an expired object and wait for the origin. That behaviour maximises freshness under normal conditions but can turn an origin failure into a visible outage even when a slightly old response would remain useful. Fastly’s grace and stale-serving mechanisms allow customers to retain expired content for controlled use during revalidation or backend failure.

This changes staleness from an accidental defect into an availability policy. A news home page may tolerate a short period of old content if the alternative is an error. A financial transaction, access decision or rapidly changing safety notice may not. The edge cannot determine the acceptable trade-off without application context. It can expose controls through which the customer expresses that context.

Grace also affects recovery. Serving stale content can reduce pressure on an unhealthy origin and prevent every request from becoming a retry. It can give operators time to restore the source without a thundering herd. Once the origin returns, the cache must revalidate and replace the stale object without creating another spike. Good configuration considers the entire incident cycle rather than only the moment of failure.

The feature is a useful example of programmable infrastructure at its best. The platform offers a general resilience primitive, while the application owner decides where it is safe. It is also an example of why developer-first does not mean effortless. Teams need a content classification, explicit stale limits, monitoring and a way to explain to the business why some users may see old data during an outage.

Dynamic site acceleration does not make dynamic work disappear

Not every request can be cached, but an edge platform can still improve a dynamic path. Persistent connections can reduce repeated setup. Route selection can avoid poor public paths between the edge and origin. TLS termination and request normalisation can occur close to users. The edge can compress responses, prioritise protocols or route requests to a suitable backend.

These functions reduce avoidable overhead. They do not remove the time required for origin compute, database access or third-party calls. An application whose critical path includes a slow inventory service will remain slow after network optimisation. A global CDN can make the transport portion more predictable while exposing how much delay remains inside the application.

The distinction matters because broad claims about edge acceleration can lead organisations to buy infrastructure instead of fixing software. A useful deployment begins with measurement: edge connection time, Fastly processing time, origin first-byte time, cache status and downstream transfer. The provider can improve the segments it controls and give evidence about the others. The customer still has to redesign a query, remove a synchronous dependency or change data placement when that is the real bottleneck.

Dynamic acceleration is therefore complementary to application engineering. It can deliver meaningful gains, especially across long or unstable paths, but the benefit varies by geography and workload. Fastly’s platform provides a place to apply transport and routing techniques at scale. It cannot guarantee a universal improvement independent of origin architecture and access-network conditions.

Streaming turns delivery into capacity planning, cache residency and event operations

Video and live events place a different load on edge infrastructure from ordinary web objects. Individual responses are larger, audience demand can rise sharply and sustained throughput matters as much as initial latency. A popular event may attract many viewers at once, creating pressure on ingest, origin storage, shield capacity, edge egress and peering links.

Caching can transform the economics when many viewers request the same segments. Once a segment is present at the edge, subsequent viewers can be served without another origin transfer. The benefit depends on audience concentration and object lifetime. A very fragmented catalogue may evict content quickly, while a live event creates intense demand for a small moving window.

Fastly’s media products include mechanisms for shielding, cache reservation, delivery and monitoring. Those components help customers manage the path, but successful operation still requires forecasts and coordination. The customer needs adequate ingest and origin capacity; Fastly needs enough regional egress; access networks need ports and last-mile bandwidth; player software needs retry and adaptive-bitrate logic.

Large events reveal the difference between aggregate network capacity and useful local capacity. Hundreds of terabits per second across the platform do not mean every city can deliver any fraction of that amount. The limiting link may be one regional interconnection. Operational preparation therefore includes demand models, pre-positioning where possible, live telemetry and clear escalation among the parties who control each segment.

Real-time logs make edge behaviour part of the application feedback loop

Fastly has long emphasised real-time log streaming. Rather than requiring customers to wait for a provider-generated report, the platform can send request records to external logging and analytics systems. A team can inspect cache status, response codes, timing, backend selection and security outcomes close to the time they occur.

This visibility supports rapid development. Engineers can deploy a rule, observe how production traffic passes through it and detect unexpected cache misses or errors. Security teams can investigate blocked requests. Product teams can connect delivery behaviour to user experience. Operations teams can separate edge processing from origin delay. The delivery layer becomes part of the same evidence loop as application services.

Real-time does not mean costless or complete. High-volume request logs are expensive to transport, store and query. Sampling or filtering can hide rare events. A failed logging endpoint can create gaps even when delivery continues. Logs can contain personal data, tokens, URLs or other sensitive fields that require minimisation and access control. A customer that exports every event without a retention strategy may replace a visibility problem with a governance problem.

The most valuable property is not the quantity of data but the ability to relate a change to its effect. Service version, request identifier, cache decision, origin timing and security action should be available in a form that supports reconstruction. Fastly supplies much of that platform telemetry. Customers need to integrate it with deploy records, origin logs and user monitoring so that the request path can be understood across administrative boundaries.

Developer-first infrastructure transfers both agency and obligation

Fastly’s developer-first position is often described as a usability advantage. It is more accurately a control model. APIs, configuration languages, code runtimes and real-time telemetry allow software teams to change infrastructure behaviour directly. They do not need every decision mediated by a provider’s operations staff.

Agency improves speed and fit. A team can encode domain-specific caching, deploy edge logic with an application release and automate configuration across services. It can build a solution that a fixed menu of CDN features would not permit. This is particularly attractive to companies whose delivery behaviour is part of their product rather than a generic requirement.

Obligation follows the same path. The customer becomes responsible for testing edge code, limiting credentials, reviewing changes, understanding cache privacy and maintaining compatibility with the origin. A provider can supply safe primitives and validation, but it cannot know every business invariant. The flexibility that enables a sophisticated design also lets a small error affect a large audience quickly.

The research briefing identifies this flexibility-versus-simplicity trade-off as Fastly’s structural limitation. A more opinionated platform may serve a broader audience with less custom work. Fastly’s model is strongest where engineering teams value control and can govern it. Growth therefore depends not only on product capability but on lowering the expertise required without reducing the predictability that advanced customers expect.

Configuration became application code before many customers governed it like code

Edge configuration often begins as an operational setting: a hostname, origin address or cache lifetime. As rules accumulate, it becomes a program. It has branching, data inputs, side effects and failure modes. It can expose private content, route users to the wrong backend or create an origin storm. Yet organisations may still manage it outside normal software controls because the file lives in a vendor platform rather than an application repository.

A mature Fastly deployment treats configuration as a release artefact. Changes are reviewed, tested against representative requests and associated with an owner. High-risk functions such as authentication, cache-key construction and backend routing receive additional scrutiny. Access to activate a service version is separated from the ability to edit a draft. Emergency changes are logged and followed by retrospective review.

Testing needs more than syntax. It should include properties: private responses are never shared, invalidation affects every expected representation, a backend failure produces the intended fallback, and malformed input cannot create unbounded work. Staging can cover common cases, while canary traffic or controlled activation reduces the blast radius of assumptions that only production reveals.

Fastly can improve safety through tooling, isolation and rollback, but customer governance remains part of platform reliability. The edge is a shared operational layer in which provider software interprets customer programs. Both sides need controls. The 2021 outage demonstrated what happens when a valid configuration reaches a latent defect beneath that boundary.

The June 2021 outage exposed a shared control-plane failure domain

On 8 June 2021, a large portion of Fastly’s network began returning errors. The company’s post-incident account stated that a software deployment introduced an undiscovered bug on 12 May. Weeks later, a customer made a valid configuration change containing the specific circumstances needed to trigger it. The interaction caused 85% of the network to return errors.

The incident matters because the customer action was not itself invalid. The failure existed in shared platform software that processed permitted configuration. This is a classic multi-tenant risk: one tenant’s ordinary input reaches a common component whose defect produces effects beyond that tenant. The platform must assume that every valid combination will eventually occur, even when the state space is too large for exhaustive testing.

Fastly’s monitoring identified the disruption within one minute. Engineers isolated the triggering configuration, disabled it and restored 95% of the network to normal operation within 49 minutes; the incident was fully mitigated later that day and a permanent fix began deployment. The response demonstrates strong detection and remediation capability. It does not reduce the architectural lesson: a common software layer had enough correlated reach to affect a large share of customer traffic simultaneously.

The company said it would examine why quality assurance had not detected the bug and pointed to WebAssembly isolation as part of longer-term resilience work. That response connects the incident to Fastly’s platform direction. Isolation should not apply only to customer compute code. The wider system needs boundaries that prevent one configuration, service or software defect from becoming a network-wide condition. The outage became running-code evidence about where those boundaries were insufficient at the time.

Recovery speed mitigated impact but did not erase concentration

A platform should be judged by both failure prevention and recovery. Fastly detected the 2021 disruption quickly and restored most service in less than an hour. That performance matters because no complex system can prove that it has eliminated every defect. Monitoring, incident authority, rollback and communication are part of the product.

Recovery metrics should not be used to minimise blast radius. For customers whose sites or services were unavailable, the event demonstrated that a single provider could become a common point of failure across otherwise independent organisations. A media outlet, commerce site and public service could be affected by the same underlying defect even though their origins and application teams shared nothing else.

The customer lesson is not necessarily to abandon integrated edge services. Multi-provider delivery can reduce one dependency while introducing DNS, configuration, cache and testing complexity. A nominal secondary CDN that is not continuously exercised may fail when needed. Some applications may obtain better overall resilience from one well-operated provider plus a tested direct-origin path; others justify active-active diversity.

The leadership question is which failure modes are acceptable and what recovery path has actually been tested. Fastly’s outage provides evidence for that exercise. Customers should know whether they can bypass the edge, how quickly DNS or routing changes take effect, which security controls disappear during bypass and whether the origin can absorb uncached traffic. Resilience is an architecture and operating practice, not a supplier count.

Compute extended the edge from request policy to general code

Fastly’s Compute product expands the platform beyond Varnish configuration. Customers can compile application logic to WebAssembly and run it in the edge environment, allowing more substantial processing than a conventional cache rule. The same user-to-edge-to-origin path remains, but the edge can now generate responses, transform data, call backends, perform selected authentication work or compose services before the request reaches a central cloud.

This changes the design conversation. Varnish logic is closely tied to HTTP delivery; a general runtime invites applications that treat the edge as a compute tier. Developers can place latency-sensitive or highly repeated work near demand, reduce data sent to origins and implement behaviour consistently across many regions. The platform handles machine provisioning and distribution while the customer supplies code.

The opportunity is bounded by workload. Edge locations are optimised for short-lived request processing, not for every form of computation. Long-running jobs, large databases, specialised accelerators and tightly coupled transactions may remain better suited to regional or central infrastructure. An application also needs to consider how often code calls a remote origin, because a function running near the user gains little if every decision waits for data stored on another continent.

Compute is best understood as another placement option. It can remove a network round trip or protect an origin, but it does not abolish cloud architecture. Its strategic significance lies in bringing application code into the same distributed control surface as caching and security. That convergence can simplify a request path while increasing the amount of application behaviour dependent on Fastly’s runtime and deployment model.

WebAssembly changes isolation and startup assumptions, not the laws of distributed systems

Fastly chose WebAssembly as the foundation for its edge runtime. WebAssembly provides a compact, portable execution format and can run code compiled from several languages within a constrained environment. Fastly presents the runtime as a way to achieve fast startup and strong isolation between customer workloads without assigning a full virtual machine to every request.

Isolation is essential in a multi-tenant edge. One customer’s code must not read another customer’s memory, monopolise a server or escape into the host. The runtime needs deterministic limits on execution, memory and access to platform capabilities. WebAssembly’s sandbox model supports those goals, while Fastly’s implementation, host functions and operational controls determine how the model behaves in production.

The word “secure” remains conditional. A sandbox can restrict what code may do, but customer logic can still contain authentication errors, leak data through responses or call an unsafe backend. The platform itself can have vulnerabilities. Dependencies compiled into the WebAssembly module need maintenance. Resource limits can prevent one class of abuse while creating failure when legitimate work exceeds them.

WebAssembly also does not remove distributed-systems problems. Code deployed globally can observe different data, fail on one network path or depend on a remote API. A fast cold start does not create consistent state. The runtime improves portability and isolation at the execution layer; application designers still need to reason about time, identity, retries, partial failure and data location.

Edge compute complements rather than replaces central cloud

Fastly competes for parts of workloads that might otherwise run in a hyperscale cloud, but the relationship is often complementary. The edge can terminate a request, enforce policy, personalise a response or select an origin. Central clouds can hold durable state, perform batch processing and host services that need a dense ecosystem of managed databases and specialised compute.

A well-designed split reduces unnecessary travel. A token can be checked near the user before a request reaches a costly origin. An image can be transformed once at the edge and cached. A routing function can select the region containing the relevant data. These uses are valuable because they make a narrow decision before committing to a longer path.

A poorly designed split adds hops and operational boundaries. An edge function may call several remote APIs, each with its own timeout and retry behaviour. Debugging then crosses Fastly logs, cloud traces and application metrics. The customer must deploy compatible versions in several places and understand which environment owns the final response. Moving code outward can reduce latency for one step while increasing system complexity.

The claim that edge computing replaces the cloud is therefore unhelpful. Fastly’s own dependencies include third-party clouds and data-centre services, and customers commonly use the platform in front of AWS, Azure, Google Cloud or private origins. The more important question is whether a particular function benefits from edge placement enough to justify another runtime, control plane and failure domain.

Storage at the edge creates new state and consistency questions

Fastly has added data services such as key-value, configuration, secret and object storage to support applications running on Compute. These products reduce the need for every function to call a distant origin. They can hold routing tables, feature settings, credentials, small application data or objects needed across requests.

Once data enters the edge platform, the architecture changes. The application is no longer using Fastly only as a stateless intermediary. It depends on how the provider replicates, updates, protects and exposes state. Different stores may have different consistency, size and update characteristics. A configuration store intended for read-heavy settings should not be assumed to behave like a transactional database.

Developers need to match data semantics to the service. A stale feature flag may be acceptable; an incorrect account balance is not. Secret distribution requires strict access and rotation. Object storage may improve locality while creating lifecycle and deletion obligations. The platform can provide documented behaviour, but the customer remains responsible for deciding which data is appropriate to place there.

Portability also becomes harder as state accumulates. Edge code can often be rewritten for another runtime, but data models, replication assumptions and deployment APIs may be provider-specific. A customer should know how information can be exported, how long deletion takes and what fallback exists if the storage service is unavailable. Compute adoption should be measured not only by function count, but by the depth of state and control delegated to the provider.

Security followed naturally from mediation of traffic

A reverse proxy sees requests before they reach the customer’s application. That position is useful for caching and acceleration, and it is also useful for security. The platform can absorb volumetric traffic, inspect HTTP requests, enforce rate limits, block known attack patterns and conceal origin addresses. Security is therefore an operational adjacency to delivery rather than an unrelated product category.

The same distribution that improves performance can help absorb attacks. Traffic is received across multiple high-capacity locations rather than concentrated on one origin link. Fastly can apply policy close to where requests enter its network and use shared observations to update defences. The customer avoids sending every malicious request through its own infrastructure.

Mediation creates responsibility. A false positive can deny legitimate users before the application sees them. A false negative can allow an attack through. Rules need context, tuning and evidence. During an incident, the customer must know whether an error originated from security policy, delivery configuration, application code or the origin. Combining functions can improve response time while making clear telemetry more important.

Fastly can provide DDoS protection, a web application firewall, bot management, API security and related controls. It cannot eliminate every vulnerability or attack. Its public filings state that no security product provides absolute protection. Application teams still need secure code, identity controls, dependency management and incident response. The edge reduces and manages risk; it does not transfer the entire security obligation.

Signal Sciences changed both the product portfolio and the operating model

Fastly completed its acquisition of Signal Sciences in 2020, adding a modern web application firewall and application-security organisation to a company previously identified mainly with delivery. The acquisition expanded the product surface from traffic handling into a security layer with its own detection logic, management workflow and customer relationships.

Signal Sciences had emphasised deployability and operational visibility rather than a purely appliance-centred model. Integrating that approach with Fastly’s edge created a path to apply security policy before requests reached customer infrastructure. It also allowed Fastly to sell security independently of, or alongside, network delivery, broadening the account relationship.

Acquisitions do not create technical convergence automatically. Product interfaces, data models, support teams and commercial packaging need integration. Customers may run the WAF at Fastly’s edge, in a cloud environment or closer to an application, and the evidence available in each mode differs. The provider has to preserve the security product’s effectiveness while aligning it with a broader platform.

The acquisition also changed Fastly’s economics. Security revenue is generally more subscription-oriented than usage-driven delivery and has grown faster in recent reporting periods. That can make revenue more predictable and deepen customer relationships. It can also create correlated dependency when delivery and application defence share a vendor and control plane. The value of integration must be weighed against the failure and exit implications of consolidation.

A web application firewall can enforce configured policy but cannot make an application secure

A WAF examines requests and applies rules intended to detect or block malicious behaviour. It can stop known attack patterns, limit automated abuse and provide time for application teams to fix vulnerabilities. It is especially useful when a customer cannot immediately change every service behind the edge.

The control is probabilistic. Attack techniques evolve, normal application traffic varies and an encrypted or encoded payload may be difficult to interpret. Aggressive rules can block customers; permissive rules can miss attacks. An API with broken authorisation remains vulnerable if the WAF cannot understand who is entitled to perform an operation. The platform sees requests, not the complete business state.

Fastly controls rule execution in its environment and can update shared detection logic. Customers control which policies are enabled, how exceptions are handled and whether alerts lead to application changes. Security teams need to test blocking behaviour and connect edge events to application logs. A managed rule set is a starting point, not a substitute for ownership.

This boundary is important for editorial accuracy. Fastly can directly be credited with building and operating security products at the edge. It cannot be credited with securing every customer application or with reducing global cyber risk by a measurable amount absent evidence. Its contribution is an enforcement and observation layer whose effectiveness depends on configuration, traffic and the systems behind it.

Delivery, security, compute and observability converge on one request path

Fastly’s platform strategy is based on applying several functions at the same edge location. A request can be accepted, checked against security policy, transformed by code, answered from cache or sent to an origin, then logged through one platform. This convergence reduces the number of separate appliances and services in the path.

The operational benefit is shared context. Security can act on delivery information; compute can use request attributes already present at the edge; logs can include decisions from several layers. A team may diagnose an application event without stitching together as many independent systems. Deployment can be coordinated through one provider and set of APIs.

The risk is common-mode failure. A control-plane problem can affect several functions at once. A mistaken service version may change cache, routing and security behaviour together. Provider access or billing failure can reach more of the application. A customer that uses the platform for both performance and protection may discover that bypassing it restores reachability but removes critical defence.

Convergence should therefore be governed by failure boundaries, not by product convenience alone. Organisations can use one platform while maintaining separate emergency paths, exportable logs and explicit ownership. The more functions converge, the more the relationship resembles infrastructure outsourcing rather than a single SaaS purchase. Procurement, architecture and incident management need to reflect that depth.

The revenue mix still shows a delivery company building adjacent businesses

Fastly reported $624.0 million in revenue for 2025, an increase of 15% from 2024. Network Services generated $477.8 million, or roughly three quarters of the total. Security produced $125.1 million, while Other products, including Compute and Observability, generated $21.1 million. Security and Other grew faster than Network Services, but delivery remained the economic base.

The first quarter of 2026 continued that pattern. Total revenue was $173.0 million, 20% higher than a year earlier. Network Services grew 11% to $126.2 million, Security grew 47% to $38.8 million, and Other grew 67% to $8.0 million. Fastly attributed the Other increase primarily to further adoption of Compute. These figures show movement, not completion of a platform transition.

A company can have strategically important products before they become large revenue contributors. Compute may influence developer adoption or help sell delivery even while appearing in a small reporting category. Security can improve margin and account depth. Network Services still funds the physical edge on which the other products rely. The categories are commercially separate but architecturally interdependent.

The correct interpretation is therefore neither that Fastly remains only a CDN nor that it has already become a general cloud. It is a delivery company using its installed edge, control plane and developer relationships to build adjacent businesses. Monitoring the mix over time can show whether those adjacencies become durable workloads or remain complementary features around the core network.

Usage-based economics align revenue with traffic and expose volatility

Fastly earns most of its revenue from customer use of the platform, measured through traffic, requests and enabled services. Larger customers often have minimum commitments and negotiated rates, while actual usage can exceed those amounts. Security and some other products add subscription or fixed-fee elements.

Usage alignment has intuitive appeal. Customers pay more when their applications generate more demand, and Fastly earns more when it carries more work. It avoids charging every customer for theoretical peak capacity. It can also produce sharp movement when a large customer changes traffic, shifts to another provider or experiences a decline in its own business.

The cost base does not move at the same speed. Servers, colocation contracts and some bandwidth commitments are arranged in advance. Fastly needs spare capacity before a traffic event or DDoS attack arrives. If usage falls, the company cannot remove every cost immediately. If usage grows unexpectedly in the wrong region, aggregate spare capacity elsewhere may not help.

Pricing therefore becomes part of infrastructure strategy. Volume discounts can retain large customers but reduce revenue per unit. Better caching and efficiency can lower a customer’s consumption even when the platform creates value. Fastly must balance competitive rates, network investment and a product mix that is not entirely tied to bytes delivered. The transition into security and compute is partly an attempt to monetise more of the request path without depending solely on traffic growth.

Customer concentration matters because traffic can move faster than infrastructure

Fastly’s largest customers generate a substantial portion of revenue. The company reported that its ten largest customers accounted for 32% of revenue over the twelve months ended 31 December 2025, while a quarterly metric showed 34% in the fourth quarter. In March 2026 it counted 634 large customers, defined through annualised quarterly revenue above $100,000; those customers generated 94% of annualised current-quarter revenue.

Concentration is not the same as dependence on one customer. Fastly reported that no single customer exceeded 10% of revenue in the first quarter of 2026. The risk comes from a group of high-volume accounts whose decisions can alter usage more quickly than the network can be resized. Media and entertainment customers can be particularly variable because audience demand and distribution rights change.

Large accounts also shape product development. Their scale can justify new features and provide meaningful operational evidence. It can give them bargaining power over rates and contractual terms. A platform designed around sophisticated customers may become harder to simplify for smaller organisations, reinforcing the developer-expertise trade-off.

For infrastructure analysis, customer count is less informative than dependency and traffic concentration. Public filings show revenue exposure but not which sites rely on Fastly for a single feature or their entire request path. They do not reveal how many customers have tested alternatives. The commercial concentration data is therefore a warning indicator, not a complete map of systemic reliance.

Capacity growth is a capital, supplier and forecasting problem

Fastly publicly reported 578 Tbps of connected global capacity as of 31 March 2026. The figure shows a large network, but connected capacity is not identical to average utilisation, delivered traffic or available headroom in every market. Capacity exists in specific servers, ports and facilities connected by contracts and physical links.

Building that capacity requires hardware, colocation space, power and bandwidth. Fastly depends on suppliers for server components and on network providers for connectivity. Delays or price increases can slow expansion. Some international markets carry higher bandwidth costs. Equipment placed ahead of demand produces depreciation and facility expense before corresponding revenue appears.

The company must forecast not only ordinary growth but irregular peaks. A customer event can concentrate demand in one geography. A DDoS attack can consume large amounts of ingress and processing capacity without producing ordinary delivery revenue. New security or compute workloads can change the mix of CPU, memory, storage and network required at a POP.

This is where the physical and software strategies meet. A more efficient cache can reduce origin traffic. Better routing can use existing ports more effectively. WebAssembly isolation can increase workload density. None of those techniques removes the need to install equipment and contract connectivity. The edge appears elastic to a developer because Fastly carries the capital-planning problem behind the API.

Competitive differentiation rests on the control model, not a universal speed claim

Fastly competes with Akamai, Cloudflare, hyperscale clouds and other delivery and security providers. Each company reports large networks, low latency and broad product capabilities. Universal performance comparisons are difficult because results vary by user location, origin, protocol, object, peering and test method.

Fastly’s more defensible differentiation is the way customers control the edge. Varnish-derived programmability, rapid purge, real-time logs, service versioning and Compute are intended to fit engineering workflows. The fewer, larger POP design reflects an operational choice rather than a claim to have the most locations. The platform is attractive when a customer wants detailed request behaviour and is prepared to manage it.

Competitors can reproduce individual features, and cloud providers can integrate edge functions with their own origins. Fastly therefore needs the complete workflow to remain coherent: onboarding, configuration, observability, support, security and pricing. Developer preference can influence a purchase, but enterprise adoption also requires procurement, compliance and executive confidence in resilience.

The research briefing correctly warns against asserting comparative latency across all regions. A provider may be faster for one network and slower for another. A credible evaluation uses the customer’s traffic, tests failure as well as median response and includes operational effort. The strategic question is whether Fastly’s control model produces enough value to offset its learning curve and dependency.

AI positioning reuses the same cache-and-control logic under a new label

Fastly now markets products for AI-related workloads, including semantic caching, API protection, bot management and edge data services. The terminology is new, but much of the infrastructure logic is familiar. Model-backed applications make repeated expensive requests, distribute results to users, expose APIs to abuse and need observability. Caching and edge enforcement can reduce cost and latency when requests or responses are safely reusable.

Semantic caching is more complicated than object caching because similarity is probabilistic. Two prompts may look related but require different answers because of user context, model version or policy. Reusing a response can create privacy, correctness and freshness risks. The edge can implement the mechanism, but the application owner must define the conditions under which reuse is acceptable.

AI traffic also creates security and data-governance questions. Bots may scrape content or invoke costly endpoints. Prompts can contain sensitive data. Provider logs may capture payloads that require minimisation. An edge platform can rate-limit, authenticate and route requests, but it cannot determine every model-specific safety rule.

The appropriate editorial stance is to treat AI as a potential workload category, not proof of a new business at scale. Public product pages demonstrate capability and positioning. Revenue reports do not isolate AI adoption. Fastly’s relevance will depend on whether customers use the edge to solve measurable AI delivery problems and whether that use becomes material beyond marketing language.

“Real-time edge” means compressed operational delay, not instantaneous control

Fastly uses “real-time” across configuration, purge, logging and observability. In each case the term should be translated technically. A configuration can propagate much faster than a traditional provider workflow. A purge can clear managed cache state in a measured fraction of a second on average. Logs can stream as requests occur instead of arriving in a daily file.

None of these operations is literally simultaneous across a distributed network. They involve queues, propagation, processing and external destinations. A mean hides the tail. A log endpoint can be unavailable. A customer can receive confirmation that a change was accepted before every effect is visible to every user. The value lies in reducing delay enough to change operating practice, not in eliminating time.

Compressed delay has organisational consequences. Teams can respond to incidents faster and release more frequently. They can also create harmful change faster. A slow provider workflow imposes friction that may be frustrating but occasionally prevents impulsive action. A programmable platform removes that friction, so governance has to replace it with deliberate review, automated tests and least-privilege activation.

This is the reality-versus-rhetoric translation that best captures Fastly. “Real-time” is a meaningful engineering direction and a central part of the company’s contribution. It should be assessed through distributions, failure cases and workflow outcomes rather than treated as a promise that distributed state has become instantaneous.

“Programmable edge” means customer logic inside a provider-controlled system

The word programmable can imply that customers control the infrastructure. They control important behaviour, but the execution environment remains Fastly’s. The provider defines APIs, resource limits, supported language toolchains, deployment mechanics and the network on which code runs. Customers choose logic within those boundaries.

This arrangement resembles other cloud services, but its location in the request path increases immediacy. Edge code can decide whether a user reaches an origin, which response is cached and what security policy applies. A runtime change by the provider can therefore affect application behaviour even when the customer has not changed code. Conversely, a customer program can stress a shared service despite isolation controls.

Clear responsibility requires both sides to retain evidence. Fastly needs versioned runtime releases, compatibility commitments, incident records and resource telemetry. Customers need source control, dependency inventories, tests and a map of provider-specific functions. The interface between those records is where support and incident response occur.

Programmability is not the absence of platform power. It is a negotiated delegation. Fastly offers a broad space in which customers can act, while retaining authority over the environment. The customer gains speed and avoids owning a global fleet; the provider gains a deeper role in application architecture. Both benefits and lock-in arise from the same design.

Fastly’s infrastructure impact comes from changing where application decisions are made

Fastly does not own the public internet and does not control global application availability. Its infrastructure impact is more specific. It has helped normalise the idea that cache freshness, routing rules, security policy, observability and selected computation can be managed at a distributed edge through developer-facing interfaces.

That shift affects origin design. Applications can rely on longer cache lifetimes when invalidation is fast. They can reduce central load through shielding and request collapsing. They can reject abusive traffic before it reaches private infrastructure. They can execute lightweight decisions near users. These changes can alter cloud cost, latency and failure behaviour even though Fastly does not own the origin.

The influence is also organisational. Delivery engineers, application developers and security teams work on the same request path. Infrastructure configuration enters CI/CD. Logs from the provider become part of product analytics and incident response. Procurement decisions about a CDN become architecture decisions about runtime and enforcement.

The company’s contribution should be attributed at that level. Fastly advanced a programmable CDN model and built a commercial platform around rapid control. It did not invent every underlying technique, and outcomes depend on Varnish, WebAssembly, internet standards, data-centre operators, ISPs, cloud providers, employees, customers and open-source communities. The system is collective even when the service has one corporate operator.

Running-code evidence matters more than the platform label

Henglu’s running-code principle provides a useful way to evaluate Fastly. A product name, architectural diagram or analyst category does not establish operational reality. What matters is whether code is deployed, whether requests are served, whether failures are observable and whether the parties running the system can accept, reject, change or exit its rules.

Fastly’s strongest evidence is operational: rapid invalidation used in production, a global network carrying trillions of daily requests according to the company, real-time logs integrated into customer systems, revenue generated by delivery and security, and an outage whose mechanism and recovery were publicly described. These facts reveal both capability and limitation more clearly than the phrase “edge cloud.”

The principle also asks where future decisions live. Fastly customers can version and activate their own configurations, write Compute code and choose origins. They cannot alter Fastly’s shared runtime or network policy. They can move traffic elsewhere, but only if their architecture and organisation preserve that option. Voluntary adoption exists at the customer boundary; dependency can make later refusal expensive.

A responsible profile therefore treats the platform as running infrastructure rather than a marketing abstraction. It asks which rules are locally controlled, which are common, how invalid state is contained and what evidence is available during failure. Fastly is important because it puts more decisions at the edge. Its long-term legitimacy depends on keeping those decisions observable, bounded and practically portable.

Collective attribution prevents the edge from becoming a corporate myth

Fastly can be credited directly with building and operating its network, commercialising a developer-controlled delivery model, advancing rapid purge and real-time edge workflows, developing its Compute runtime and integrating Signal Sciences into a broader security offering. These are identifiable corporate actions supported by product records and filings.

The company cannot be credited solely with the evolution of content delivery, Varnish, WebAssembly, internet peering or application security. Those fields were created by wider technical communities. Its performance depends on colocation providers, hardware suppliers and network operators. Customer engineers write the logic that often determines whether a deployment succeeds. Origins and access networks remain outside its authority.

Individual attribution needs the same care. Artur Bergman’s Wikia experience and founding role explain Fastly’s initial thesis. Thousands of later product, network, security and operations decisions belong to teams, partners and customers. Leadership changes do not transfer authorship of the entire platform to one executive.

This boundary is not a reason to make the company invisible. It is a way to describe infrastructure accurately. Fastly’s role is that of a powerful intermediary and platform operator within a larger system. Its choices shape how applications are delivered, but they become outcomes only through adoption and operation by independent actors.

Why BTW tracks Fastly

BTW tracks Fastly because the company sits at a revealing boundary in digital infrastructure. It is large enough to mediate important applications, technically distinctive enough to influence how developers think about the edge and bounded enough to show why platform control is never the same as internet control.

The company’s history connects several structural changes. The web moved from static publishing to continuously updated applications. Infrastructure configuration moved into software pipelines. Security shifted toward enforcement in front of origins. WebAssembly created another execution model for shared platforms. Observability became a real-time data stream. Each change expanded what could be delegated to an edge provider.

Fastly also exposes the costs of that delegation. Programmability demands expertise. Rapid propagation increases blast radius. Shared software can create correlated failure. Usage-based revenue and concentrated customers shape investment. An integrated platform can simplify operations while making exit harder. These are not side issues; they are the operating logic of contemporary cloud dependence.

The company should therefore be followed neither as a smaller version of a broad edge competitor nor as a simple high-performance CDN. Its distinctive question is how much application control can move into a provider-operated delivery path without making that path opaque, brittle or irreversible. The answer will influence not only Fastly’s commercial future but the design of distributed applications more generally.

Principal evidence and unresolved questions

The principal evidence for this profile consists of the supplied Fastly deep-research briefing; Fastly’s annual report for the year ended 31 December 2025; its quarterly report for the three months ended 31 March 2026; official network, product and developer documentation; the company’s account of the 8 June 2021 outage; its original public-offering filing; and official material concerning the Signal Sciences acquisition. Together these sources establish the legal identity, founding problem, product architecture, reported scale, revenue mix, major dependencies and disclosed failure history.

The evidence has limits. Company documentation is authoritative for what Fastly states and offers, but it is not independent proof of comparative performance. Aggregate capacity does not reveal utilisation or physical diversity. Mean purge time does not disclose the complete tail distribution. Revenue categories show commercial adoption but do not identify the number or criticality of production Compute deployments. Customer concentration by revenue does not reveal concentration of socially important services.

Important information remains unavailable. The public record does not provide a complete internal network topology, capacity by POP, global traffic share, universal latency comparison, configuration-failure rate, edge-compute workload mix, customer-level exit readiness or a full map of shared control-plane dependencies. It is not possible to determine from public evidence how many customers could bypass Fastly during a severe incident or how much origin capacity would survive a mass cache miss.

The unresolved questions define the next phase. Can Fastly simplify the platform enough to expand adoption without weakening the precise control valued by existing customers? Will Security and Compute become material businesses while preserving the economics of the delivery network? Can common services be isolated so that rapid configuration does not produce global blast radius? Will customers retain portable logic and independent observability as the edge accumulates state? Those questions, rather than headline capacity alone, will determine whether Fastly’s programmable model becomes a durable infrastructure layer.