FastEdge overview

FastEdge runs WebAssembly applications on Gcore’s global edge network. Apps execute at the edge node closest to the request — no infrastructure to configure or maintain. Common use cases include A/B testing, personalization, authentication, and image processing.

Application types

FastEdge supports three application types. The application type determines how the application integrates with FastEdge and which setup guide to follow.

Modern HTTP applications receive and respond to HTTP requests directly. They implement the WASI P2 wasi:http/proxy interface — the current recommended standard for WebAssembly HTTP applications. Supported in Rust (via the wstd crate) and JavaScript. Use this type for new edge services: APIs, redirects, authentication proxies, and similar workloads.

Legacy HTTP applications also handle HTTP requests directly, but use Gcore’s own fastedge crate rather than the WASI standard. They target WASI P1, the original WebAssembly system interface. Most existing FastEdge HTTP applications written in Rust use this approach. Use it when maintaining existing applications built on the fastedge crate.

CDN applications run inside a CDN resource’s request pipeline. They implement the Proxy-Wasm specification — an open standard for WebAssembly-based proxy extensions — and can intercept traffic at four stages: on request headers, on request body, on response headers, and on response body. Supported in Rust only. Use this type when extending an existing CDN-served site with edge logic.

To get started, choose the setup guide that matches the application type and language:

App type	Language	Setup guide
Modern HTTP	Rust	Rust (Modern HTTP)
Modern HTTP	JavaScript	JavaScript
Legacy HTTP	Rust	Rust (Legacy HTTP)
CDN	Rust	Rust (CDN / Proxy-Wasm)

All three types share the same deployment workflow:

1. Compile the application to WebAssembly and upload the binary to FastEdge.
2. Gcore deploys it across edge nodes worldwide. Traffic is automatically routed and load-balanced.
3. When a request arrives, the runtime executes the application and returns the result to the client.

Key benefits

• Run code close to users. FastEdge executes on the edge node closest to each request, reducing round-trip latency without relocating the origin.
• Deploy without managing servers. Gcore handles deployment, scaling, and routing across the global network. The application binary is the only artifact to maintain.
• Isolated execution per application. Each application runs in a WebAssembly sandbox, isolated from other applications on the same node.
• Write in Rust or JavaScript. Both languages have first-class SDK support. Rust covers all three application types; JavaScript supports Modern HTTP applications.

Use cases

A/B testing

Split traffic between application versions at the edge — by percentage, geolocation, subnet, or a combination. Teams test changes on a limited audience before a full rollout, with no changes to the origin required.

Personalization

Serve region-specific content based on geolocation, IP address, or request headers — different language, currency, or product catalog per market — without modifying the origin application.

Authentication

Validate JWT tokens at the edge before a request reaches the origin. The origin processes only validated requests, reducing its load and eliminating a network round-trip for invalid ones.

Image manipulation

Convert images at the edge node closest to the request — bulk WebP conversion, low-resolution resizing, watermarking — rather than at a central origin, reducing bandwidth and processing load.

URL rewriting and header control

Rewrite non-human-readable CMS URLs to a user-friendly format in the response, and add or remove HTTP headers — without touching the origin application.