Platform architecture

Easel separates application builds from request delivery. A deployment is assembled once, published as immutable output, and then served through shared delivery and runtime systems.

Build plane

The build plane turns source code into deployable artifacts.

Git commit or CLI upload
  ↓
Install dependencies
  ↓
Run framework build
  ↓
Analyze build output
  ├─ static assets
  ├─ server functions
  ├─ routing metadata
  ├─ cache metadata
  └─ image configuration
  ↓
Publish immutable deployment

The exact output depends on the framework. A Vite application may contain only static assets. A Next.js application may also contain server handlers, middleware, cached route output, and image optimization configuration.

Delivery plane

The delivery plane receives every request to an Easel URL or connected domain.

Request
  ↓
Platform protections
  ↓
Deployment protection
  ↓
Project firewall rules
  ↓
Routing, redirects, and rewrites
  ↓
CDN cache or static asset
  ↓ when application execution is required
Function routing
  ↓
Function instance

The delivery plane can complete requests without application compute. This reduces latency and avoids unnecessary Function usage.

Compute plane

Dynamic routes run in Easel Functions. A Function instance can process overlapping requests when the runtime and application permit it.

Applications must not depend on instance affinity, durable local files, or mutable process-wide state. Use external data stores or Runtime Cache for shared state.

Data and cache layers

Easel exposes two distinct cache systems:

A single request can use both. A Function can read data from Runtime Cache and return a response that is then stored in the CDN cache.

Control plane

The dashboard, Git integration, CLI, and future public API operate the control plane. They create projects, configure environments, start deployments, assign domains, and expose operational data.

Control-plane actions do not change an immutable deployment. Changes to source code, build-time variables, or build settings require a new deployment. Traffic assignment can move between existing compatible Production deployments without rebuilding.

Observability plane

Easel records telemetry across request delivery and Function execution. Request IDs correlate client-visible responses with request details, logs, traces, cache decisions, security events, and Function invocations.

Because one Function invocation may process multiple requests, request and invocation records are related but not interchangeable.

Availability boundaries

A globally reachable delivery network does not imply that every service executes in every edge location. Static and cached responses may be served close to users while dynamic Functions run in documented compute regions.

See Regions and Limits for the current platform boundaries.