Function configuration

Configure Node.js version, CPU tier, duration, build settings, and environment variables for Easel Functions.

Function configuration controls the runtime, resources, environment, and duration used by dynamic application routes.

Easel derives defaults from the framework build and project settings. Override them only when the application has a specific requirement.

Configuration sources

Function behavior may be influenced by:

Easel project settings
Environment-specific project settings
Supported framework build metadata (including route maxDuration)
Platform defaults

Easel project settings remain authoritative for platform-managed resources such as CPU tier and Node.js version.

Project-level controls

Project settings that affect functions include:

Node.js version (22 or 24)
CPU tier (Standard or Performance)
Environment variables
Root directory
Build command
Install command

There is no project UI for function duration or regions. Duration comes from framework route config when present. Functions run in US East. See Function regions.

Runtime version

Select Node.js 22 or 24 in project build settings.

Easel does not resolve the runtime from package.json engines.node. Set the version in the project so builds and functions use the same Node.js line.

Before changing runtime versions:

Review framework compatibility
Rebuild native dependencies
Test preview deployments
Confirm database and SDK support
Review deprecated runtime APIs

CPU and memory

CPU and memory determine the resources available to each active function instance.

Easel currently offers two project-level tiers:

Tier	Memory	CPU
Standard	2 GB	1 vCPU
Performance	4 GB	2 vCPU

Increase resources when the function:

Performs CPU-intensive work
Uses large framework bundles
Processes large responses
Requires substantial in-memory data
Encounters memory errors
Needs lower latency for compute-bound work

Do not increase memory merely to compensate for:

Unbounded caches
Memory leaks
Loading unnecessary dependencies
Buffering large streams
Retaining request state globally

See Function limits for related constraints.

Maximum duration

Maximum duration controls how long an invocation may remain active.

Duration includes:

Application execution
Awaited network calls
Streaming
Registered post-response work (waitUntil / after())
Other work performed before the invocation ends

The default maximum duration is 30s. Frameworks that emit maxDuration in build output (for example Next.js route config) can raise it up to 800s.

Next.js example:

export const runtime = "nodejs";
export const maxDuration = 60;

Easel reads the value from .vc-config.json produced by the build. Missing or invalid values default to 30s. Values outside 1–800 are clamped.

Choose a duration that allows normal requests to complete without masking unexpectedly slow operations.

Use a durable background-job system for work that exceeds practical HTTP request duration.

Environment variables

Configure environment variables separately for supported deployment environments.

Typical environments include:

Production
Preview
Development

Example server-only variables:

DATABASE_URL
AUTH_SECRET
API_KEY

Example public variables:

NEXT_PUBLIC_API_ORIGIN
VITE_PUBLIC_API_ORIGIN

Public variables can be embedded into browser code during the build. They must not contain secrets.

See Deployment environments.

Build-time and runtime variables

Some variables are used during the build, while others are read when the function runs.

A variable may need to be available in both phases.

Framework behavior differs, so consult the relevant framework guide.

Secret changes

A runtime variable change may require a new deployment depending on how the framework packages or reads the value.

Public build-time variables require a rebuild.

Framework-generated configuration

Framework adapters can emit metadata describing:

Function entry points
Route patterns
Runtime requirements
Route-level duration
Static assets
Cache behavior

Easel consumes supported metadata from the build output.

Platform-level settings can override adapter resource hints where documented.

Root directory

For monorepos, set the project root to the directory containing the application.

Example:

repository/
├── apps/
│   ├── web/
│   │   ├── package.json
│   │   └── next.config.ts
│   └── admin/
└── packages/

For the web application:

Root directory: apps/web

The root affects:

Dependency installation
Framework detection
Build commands
Output discovery
Environment files
Application configuration

Install command

Easel normally detects the package manager and install command.

Examples:

npm install
pnpm install
yarn install
bun install

Override the command only when the repository requires custom behavior.

Use lockfiles to keep dependency resolution reproducible.

Build command

Easel normally uses the framework’s production build command.

Examples:

next build
nuxt build
vite build

The build must produce a supported deployment output.

Do not start a long-running server from the build command.

Native dependencies

Packages with native components must be compatible with the Easel runtime environment.

Potential issues include:

Operating-system compatibility
CPU architecture
C library requirements
Post-install scripts
Prebuilt binary availability
Runtime version compatibility

Test native dependencies in a preview deployment.

Configuration by environment

Production and preview deployments may need different:

Database connections
Authentication origins
API keys
Logging levels
External service environments
Resource allocations

Avoid branching on hostnames when a deployment environment variable is available.

Safe defaults

Start with platform defaults when:

The application is new
Traffic is low
Workloads are mostly I/O-bound
The framework has no special resource requirement

Adjust settings after observing:

Duration
Memory
CPU
Startup latency
Concurrent load
Downstream latency

The Node.js version is set in project build settings (not only engines)
The runtime version is supported
The setting requires a new deployment
The configuration is applied to the correct environment

A function runs out of memory

Check for:

Large in-memory buffers
Unbounded collections
Module-level caches
Large response generation
Native-library memory usage
Excessive concurrency
Memory leaks

Increasing memory may help, but inspect application behavior first.

The function times out

Use traces and logs to identify:

Slow database queries
External API delays
Retry loops
Unclosed streams
Post-response work
Long-running CPU tasks

Raise route maxDuration only when the operation is appropriate for a request-driven function, and stay within the 800s maximum.

Environment variables are missing

Confirm that:

The variable exists in the correct environment
The deployment was created after the variable changed
The framework exposes it at runtime
Public prefixes are used only for non-secret client values
The variable name matches exactly