Function limits

Easel Functions are subject to resource and request limits that protect platform reliability and define the supported execution model.

Current limits

In-function concurrency, response size, header size, URL length, temporary filesystem capacity, and outbound connection counts are enforced by the platform and can change with runtime configuration. Design applications so they remain safe under concurrent requests on a shared instance.

Duration

Maximum duration is the total time an invocation can remain active.

It includes:

• Application execution
• Database and API requests
• Streaming response bodies
• Post-response work such as waitUntil / after()
• Framework rendering
• Cache regeneration

Returning response headers does not end the invocation. Duration continues until the handler finishes, the stream closes, and registered post-response work completes, or the limit is reached.

When the duration limit is reached, Easel terminates the invocation.

Stalled invokes are aborted earlier, without waiting for the full maxDuration:

• Response headers must arrive within 60 seconds of invoke start (or sooner when remaining maxDuration plus a small transport slack is smaller).
• After headers, each body chunk and completion signal must arrive within 30 seconds of the previous progress (again capped by the remaining duration budget).

Set route-level duration through your framework when supported (for example Next.js export const maxDuration = 60). Easel reads the value from build output. The default is 30s when unset. Values outside 1–800s are clamped.

Use a queue or durable worker system for work that cannot reliably complete within the limit.

Memory

Memory includes application and runtime usage such as:

• JavaScript heap
• Native allocations
• Framework code
• Buffers
• Loaded files
• Database clients
• Concurrent request state

An invocation or instance that exceeds its memory allowance may terminate.

Common causes include:

• Unbounded arrays or maps
• Large body buffering
• Image processing
• Loading large datasets
• Retaining request state globally
• Memory leaks
• Excessive concurrency

Stream large data where possible rather than loading it entirely into memory.

CPU

CPU allocation affects compute-bound work.

Examples include:

• Rendering
• Compression
• Cryptography
• Serialization
• Image processing
• Large data transformations

I/O-bound applications may benefit more from concurrency and connection reuse than from increased CPU.

CPU and memory are configured together through the Standard and Performance tiers. See Function configuration.

In-function concurrency

Concurrency limits the number of simultaneous requests one active instance can process.

Higher concurrency can improve efficiency for I/O-heavy workloads but increases aggregate pressure on:

• Memory
• CPU
• Database pools
• External API limits
• Shared application clients

Applications must remain concurrency-safe even below the platform maximum.

The platform may use fewer concurrent requests depending on traffic and instance conditions.

Request body size

Requests larger than the supported body limit may be rejected before or during function execution.

For large uploads, prefer direct browser-to-object-storage uploads using signed URLs.

This avoids sending the complete file through the function.

Response size

Buffered and streaming responses may have different practical limits.

Large buffered responses consume memory and delay the first byte.

Prefer streaming when:

• Generating large exports
• Forwarding large upstream responses
• Producing incremental output

For static or generated files that are reused, store the file in object storage or deploy it as a static asset instead of regenerating it on each request.

Headers

Requests with oversized headers can be rejected before application code runs.

Common causes include:

• Large cookies
• Excessive authentication claims
• Many tracing headers
• Repeated proxy headers
• Large custom metadata

Keep cookies small and avoid storing complete application state in them.

Responses can also fail when custom headers exceed platform limits.

URL length

Long URLs commonly result from:

• Large query payloads
• Encoded state
• Complex filters
• Tracking data
• Redirect chains

Use a request body for large structured input rather than encoding it into the URL.

Remember that GET request bodies are not a reliable alternative.

Temporary filesystem

Temporary storage is ephemeral and capacity-limited.

Use it only for bounded intermediate work.

Do not use it for:

• Persistent uploads
• Durable databases
• Shared application state
• Long-term caches

Files can disappear when the invocation or instance ends.

Bundle size

Function bundles include:

• Application code
• Framework runtime
• Dependencies
• Generated server code
• Packaged files

Large bundles can increase:

• Build time
• Deployment size
• Startup latency
• Memory usage

Reduce bundle size by:

• Removing unused dependencies
• Avoiding large optional packages
• Using framework output tracing
• Loading assets from object storage
• Separating unrelated workloads
• Reviewing duplicated dependencies

Environment variable limits

Environment variables have limits on count, name size, value size, and aggregate size. The combined size of environment variable names and values must stay within 4 KB.

Do not store large files, certificates, or datasets directly in environment variables.

Use a secret manager or secure storage for larger configuration objects where supported.

Logs

Large or excessively frequent logs can be truncated, sampled, or rejected.

Avoid logging:

• Complete request bodies
• Large response payloads
• Binary data
• Secrets
• Session cookies
• Authorization headers

Prefer structured, concise events.

Database connections

Function concurrency and autoscaling can create many database connections.

For example:

instances × concurrent requests × connections per request

can exceed the database limit quickly.

Use:

• Connection pools designed for serverless workloads
• Database proxies
• Shared clients within an instance
• Bounded pool sizes
• Query timeouts
• Runtime Cache
• CDN caching

Do not create a new unbounded pool for every request.

External service limits

Easel’s function limits do not replace limits imposed by:

• Databases
• APIs
• Authentication providers
• Email services
• Object storage
• Payment services

Autoscaling can increase downstream request volume rapidly.

Use rate limits, bounded concurrency, retries with backoff, and circuit breakers where appropriate.

Cacheable response limits

CDN caching may impose separate constraints on:

• Response size
• Status codes
• Headers
• Streaming
• TTL
• Tags

See Caching for CDN-specific behavior.

Limits and framework behavior

Frameworks can introduce their own limits and defaults.

Examples include:

• Body parser limits
• Image optimization limits
• Route-level duration
• Static generation limits
• Middleware restrictions
• Adapter bundle constraints

The effective limit is the strictest applicable framework or platform constraint.

Limit errors

When a limit is exceeded, the request may fail with:

• An HTTP error status
• A platform error page
• A function termination
• A truncated log or response
• A build failure

Use logs, traces, and the request ID (X-Easel-Id) to identify which limit was exceeded, then adjust configuration or application behavior.

Related documentation

• Functions
• Function runtime
• Function configuration
• Function regions
• Caching
• Runtime Cache