Functions

Easel Functions run the server-side portions of your application, including server-rendered pages, API routes, server actions, loaders, framework endpoints, and application-defined handlers.

Functions are created automatically from supported framework builds. Easel deploys each function with the runtime and resources required by the project. Functions run in US East; see Function regions.

What runs in a function

Depending on the framework and application, Easel Functions can handle:

• Server-rendered pages
• API routes
• Route handlers
• Server Actions
• Loaders and actions
• Webhooks
• Authentication callbacks
• Cache regeneration
• Scheduled post-response work within the invocation lifecycle
• Application-defined HTTP endpoints

Static pages and build assets do not require a function. They are served through Easel’s CDN.

How requests reach functions

A dynamic request enters through Easel’s delivery network and is routed to an eligible function instance.

A function is not invoked when Easel can complete the request through:

• A firewall rule
• A redirect
• A fresh cached response
• A static deployment asset

See CDN for request delivery and response caching.

Framework integration

Supported frameworks generate the function entry points Easel deploys.

Examples include:

The exact number and structure of deployed functions depend on the framework adapter and build output.

See Framework guides for framework-specific deployment behavior.

Scaling

Easel creates additional function capacity as request volume increases.

Applications must not assume that:

• The same visitor reaches the same instance
• Requests run sequentially
• Local memory is shared across instances
• Files written by one invocation exist during another
• An instance remains active indefinitely

Use a database, object storage, or the Runtime Cache for shared or durable data.

In-function concurrency

An active Easel Function can process more than one request concurrently when the runtime and application permit it.

This can improve:

• Throughput per active instance
• Resource utilization
• Connection reuse
• Latency during traffic bursts
• Performance for applications that spend time waiting on databases or APIs

Application code must therefore be safe for overlapping requests.

Avoid storing request-specific state in module-level mutable variables.

Unsafe:

let currentUserId: string | undefined;

export async function handler(request: Request) {
  currentUserId = await getUserId(request);

  return Response.json({
    userId: currentUserId,
  });
}

Safer:

export async function handler(request: Request) {
  const userId = await getUserId(request);

  return Response.json({
    userId,
  });
}

Module-level read-only objects and reusable clients are appropriate when their libraries support concurrent use.

Streaming

Functions can return streaming HTTP responses when supported by the framework and runtime.

export async function GET() {
  const stream = new ReadableStream({
    start(controller) {
      controller.enqueue(new TextEncoder().encode("Starting\n"));
      controller.enqueue(new TextEncoder().encode("Complete\n"));
      controller.close();
    },
  });

  return new Response(stream, {
    headers: {
      "Content-Type": "text/plain; charset=utf-8",
    },
  });
}

Easel forwards response chunks as they become available.

The function invocation remains active until application execution finishes, the response closes, or the invocation reaches its duration limit.

Streaming does not automatically make a response cacheable. See Caching.

Work after the response

Supported framework APIs may register work that continues after the response is ready. That work still counts against Function duration and does not outlive the invocation.

See Background work for patterns, limits, and when to use a durable job system instead.

Environment variables

Functions receive environment variables configured for the project and deployment environment. See Environment variables for scoping, secrets, and build-time versus runtime values.

const databaseUrl = process.env.DATABASE_URL;

Production and preview deployments can use different values.

Public framework variables such as NEXT_PUBLIC_* or VITE_* may be embedded into browser bundles during the build and must not contain secrets.

See Function configuration.

Observability

Function requests can produce:

• Request logs
• Application logs
• Errors
• Duration and resource metrics
• Distributed traces
• Cache diagnostics
• Regional execution metadata

Use the request ID returned by Easel to correlate a client response with logs and traces:

X-Easel-Id: 550e8400-e29b-41d4-a716-446655440000

Avoid logging authorization tokens, session cookies, passwords, API keys, or other secrets.

See Observability and Request details.

Functions and caching

Functions can interact with two distinct cache layers.

A function can read application data from the Runtime Cache and return a response that is subsequently stored in the CDN cache.

See:

• Caching
• Revalidation and purging
• Runtime Cache

Function configuration

Project settings control function behavior such as:

• Node.js version
• CPU and memory allocation
• Environment variables
• Build and output settings

Framework adapters may also emit route-level metadata such as maxDuration. Functions run in US East. See Function regions.

See Function configuration.

Regions

Functions run in US East (iad). The CDN may still serve cacheable responses from other edge locations.

See Function regions.

Limits

Functions are subject to limits including:

• Maximum duration
• Memory
• CPU
• Request body size
• Response size
• Header size
• Deployment size
• Concurrent executions

See Function limits.

Related documentation

• Runtime behavior
• Function configuration
• Function regions
• Function limits
• Environment variables
• Background work
• Image optimization
• Runtime Cache
• Framework guides
• CDN
• Observability