The Compute@Edge platform helps you compile your custom code to WebAssembly and runs it at the Fastly edge using the WebAssembly System Interface for each compute request. Per-request isolation and lightweight sandboxing create an environment focused on performance and security.

Serverless isolation technology

Compute@Edge runs WebAssembly (Wasm) and leverages the Lucet compiler and runtime, which ahead-of-time compiles customer code to Wasm. When a compute request is received by Fastly, an instance is created and the serverless function is run, allowing developers to apply custom business logic on demand.

Global deployment

Deploying to a Compute@Edge service leverages Fastly’s software-defined network and globally distributed points of presence. A single deploy action makes customer logic available across the Fastly network.

Available programming languages

By running Wasm on the Fastly network, Compute@Edge creates a serverless environment suitable for multiple programming languages. Fastly collaborates with the ByteCode Alliance and other open source communities to actively grow the number of supported languages. Resources per language are available on

Logging endpoint compatibility

Compute@Edge supports sending user-specified logs to a variety of logging endpoints. These connections can be created and managed via and by using the log_fastly crate.

Continuous integration and deployment

Deployment to the Compute@Edge platform can be accomplished via the Fastly web interface, the Fastly API, and via Fastly’s Terraform provider plugin. The Fastly CLI also provides a local toolchain with features for creating, debugging, and deploying to Wasm services, including Log Tailing and Local Testing.

Log Tailing allows you to stream custom log messages from your Compute@Edge application so you can respond quickly when debugging the application without setting up a third-party logging tool. This feature is disabled by default.

Local Testing allows you to run your work-in-progress applications locally on your laptop, server, or CI system, so you can test your Compute@Edge applications without hosting them on public staging or production environments. When using Local Testing, GeoIP and Dictionaries are unsupported. Additionally, caching directives are ignored (no caching is ever performed) and information about the TLS connection from the client is not available.

Back to Top