CDN

Every Easel deployment is served through a global delivery network that handles security, routing, caching, compression, and HTTPS before a request reaches your application.

Static assets can be delivered without invoking compute, while cacheable dynamic responses can be reused across requests to reduce latency and function usage.

How requests are handled

Easel can complete a request through a firewall rule, redirect, cached response, or static deployment asset without invoking application code.

Security and routing

Easel first applies the rules that determine whether and where a request should continue.

These can include:

• Web Application Firewall rules
• Attack Mode challenges
• redirects and rewrites
• framework middleware
• static and dynamic route matching

Requests can be blocked, challenged, redirected, rewritten, or passed to the matching application route.

See Routing and Redirects and rewrites.

Cached responses

For eligible requests, Easel can reuse a previously generated response from the CDN cache.

A cache hit avoids invoking application code or contacting an external data source. Cache behavior is controlled through standard HTTP cache directives, with support for shared-cache expiration.

Easel exposes the result through the X-Easel-Cache response header.

X-Easel-Cache: HIT

Static and dynamic routes

When a cached response is not available, Easel serves the resource matched by the deployment.

Static files such as HTML, JavaScript, CSS, fonts, and images are served as deployment assets without invoking an Easel Function.

Server-rendered pages, API routes, server actions, and other dynamic handlers run in Easel Functions. Dynamic responses can also be cached when they include an eligible cache policy.

Response delivery

Before returning a response, Easel applies the relevant delivery behavior.

Depending on the request and response, this can include:

• CDN caching
• Brotli or gzip compression
• HTTPS and security headers
• custom response headers
• request and cache diagnostics

What you get automatically

Every Easel deployment includes:

Delivery network

Requests enter through Easel’s delivery network and are routed to the appropriate cached asset, deployment resource, or application function. Function compute regions are separate from edge delivery locations. See Regions.

Static asset delivery

Files produced during the build are deployed as versioned assets and served without application compute.

Dynamic response caching

Applications can cache server-rendered pages, API responses, and other HTTP responses using standard cache headers.

Cache revalidation

Cached content can expire automatically or be invalidated through cache tags and supported framework APIs.

Compression

Eligible responses are compressed automatically. Easel prefers Brotli when supported by the client and falls back to gzip.

HTTPS

Easel provisions and renews TLS certificates for deployment URLs and configured custom domains.

Request diagnostics

Response headers expose request IDs, cache results, and other supported delivery metadata for debugging.

Choose a guide

CDN cache and Runtime Cache

Easel provides two separate caching systems.

An application can use both. A server-rendered route might read data from the Runtime Cache and then place the completed HTTP response in the CDN cache.

See Runtime Cache for application-level caching.

Related documentation

• Functions
• Security
• Runtime Cache