Routing | Easel.sh

Routing determines which deployment and resource handle an incoming request.

Host routing

The request host first selects an Easel deployment target:

A unique deployment URL selects one immutable deployment.
A branch or pull-request URL selects the latest ready deployment for that alias.
A production domain selects the Current Production deployment.

Request evaluation

Within the selected deployment, Easel evaluates request handling in a defined order.

Host selects deployment
  ↓
Platform and project security controls
  ↓
Redirects and rewrites
  ↓
Framework middleware, when present
  ↓
Cache and static asset lookup
  ↓
Dynamic route or Function
  ↓
Not found response

Static routes

Static files produced by the build are served without invoking application code. Asset paths are derived from the deployment output and framework routing metadata.

Dynamic routes

Server-rendered pages, API routes, loaders, actions, and other handlers route to Easel Functions.

Dynamic route precedence is determined by the framework's generated route manifest and Easel's supported routing model.

Middleware

Framework middleware can inspect or modify requests before the final route executes. Middleware support, matchers, runtime behavior, and limitations are framework-specific.

Rewrites

A rewrite changes the internal destination while preserving the URL shown to the visitor. Rewrites can target another route in the deployment and, where supported, an external origin.

Redirects

A redirect returns a 3xx response and a Location header. Redirects complete before the destination application route runs.

Trailing slashes and normalization

Frameworks can define path normalization behavior. Avoid creating rules that redirect between equivalent forms indefinitely.

Use the deployment URL to distinguish deployment-output problems from production-domain assignment problems. Inspect request details, redirect headers, cache status, and Function logs for the same request ID.