Vercel Functions Limits
The table below outlines the limits and restrictions of using Vercel Functions with Fluid compute:
| Feature | Limits |
|---|---|
| Maximum memory | Hobby: 2 GB, Pro and Ent: 4 GB |
| Maximum duration | Hobby: 300s default and maximum. Pro and Enterprise: 300s default, 800s maximum, and 1800s extended maximum Beta . See max duration for requirements and configuration. |
| Size (uncompressed) | 250 MB, or 500 MB for Python. Large functions support up to 5 GB Beta . |
| Concurrency | Auto-scales up to 30,000 (Hobby and Pro) or 100,000+ (Enterprise) concurrency |
| Cost | Pay for active CPU time and provisioned memory time |
| Regions | Runs in a single region by default (iad1), which you can change.Pro and Enterprise teams can set multiple regions |
| API Coverage | Full Node.js coverage |
| File descriptors | 1,024 shared across concurrent executions (including runtime usage) |
The following limits apply to the function's name when using Node.js runtime:
- Maximum length of 128 characters. This includes the extension of the file (e.g.
apps/admin/api/my-function.jsis 29 characters) - No spaces are allowed. Replace them with a
-or_(e.g.api/my function.jsisn't allowed)
Vercel places restrictions on the maximum size of the deployment bundle for functions to ensure that they execute in a timely manner.
For Vercel Functions, the maximum uncompressed size is 250 MB including layers which are automatically used depending on runtimes. These limits are enforced by AWS. For Python functions, the maximum uncompressed size is 500 MB.
You can use includeFiles and excludeFiles to specify items which may affect the function size. These configurations are not supported in Next.js, instead use outputFileTracingIncludes.
Large functions let you deploy uncompressed bundles up to 5 GB. Use them for workloads that ship large dependencies, model files, or binaries. Large functions are supported on Node.js, Bun, and Python runtimes.
Large functions require fluid compute with Active CPU enabled. Fluid compute is enabled by default for new projects.
New projects are eligible for large functions by default. For existing projects, opt in by setting the VERCEL_SUPPORT_LARGE_FUNCTIONS environment variable.
The environment variable always takes precedence over the project default. Set it to 1 to enable support for large functions, or 0 to disable, for both new and existing projects.
You can set VERCEL_SUPPORT_LARGE_FUNCTIONS as a project environment variable in your project settings or with the Vercel CLI.
In eligible projects, Vercel only uses the large functions beta for Functions that exceed the standard bundle size limit. Functions that fit within the standard limit continue to use the standard path.
Large functions are supported on the following runtimes:
This refers to the longest time a function invocation can run before Vercel terminates it. For request handlers, this includes time spent processing the request and sending the response, including streamed responses.
While Vercel Functions have a default duration, this duration can be extended using the maxDuration config. If a Vercel Function doesn't complete within the duration, a 504 error code (FUNCTION_INVOCATION_TIMEOUT) is returned.
With fluid compute enabled, Vercel Functions have the following defaults and maximum limits:
| Default | Maximum | Extended maximum | |
|---|---|---|---|
| Hobby | 300s (5 minutes) | 300s (5 minutes) | - |
| Pro | 300s (5 minutes) | 800s | 1800s (30 minutes) Beta |
| Enterprise | 300s (5 minutes) | 800s | 1800s (30 minutes) Beta |
Vercel Functions using the Edge runtime must begin sending a response within 25 seconds to maintain streaming capabilities beyond this period, and can continue streaming data for up to 300 seconds.
Vercel Functions have the following defaults and maximum limits:
| Default | Maximum | |
|---|---|---|
| Hobby | 2 GB / 1 vCPU | 2 GB / 1 vCPU |
| Pro / Enterprise | 2 GB / 1 vCPU | 4 GB / 2 vCPU |
Users on Pro and Enterprise plans can configure the default memory size for all functions in the dashboard.
The maximum size for a Function includes your JavaScript code, imported libraries and files (such as fonts), and all files bundled in the function.
If you reach the limit, make sure the code you are importing in your function is used and is not too heavy. You can use a package size checker tool like bundle to check the size of a package and search for a smaller alternative.
In Vercel, the request body size is the maximum amount of data that can be included in the body of a request to a function.
The maximum payload size for the request body or the response body of a Vercel Function is 4.5 MB. If a Vercel Function receives a payload in excess of the limit it will return an error 413: FUNCTION_PAYLOAD_TOO_LARGE. See How do I bypass the 4.5MB body size limit of Vercel Functions for more information.
File descriptors are unique identifiers that the operating system uses to track and manage open resources like files, network connections, and I/O streams. Think of them as handles or references that your application uses to interact with these resources. Each time your code opens a file, establishes a network connection, or creates a socket, the system assigns a file descriptor to track that resource.
Vercel Functions have a limit of 1,024 file descriptors shared across all concurrent executions. This limit includes file descriptors used by the runtime itself, so the actual number available to your application code will be strictly less than 1,024.
File descriptors are used for:
- Open files
- Network connections (TCP sockets, HTTP requests)
- Database connections
- File system operations
If your function exceeds this limit, you might encounter errors related to "too many open files" or similar resource exhaustion issues.
To manage file descriptors effectively, consider the following:
- Close files, database connections, and HTTP connections when they're no longer needed
- Use connection pooling for database connections
- Implement proper resource cleanup in your function code
The Hobby plan offers functions for free, within limits. The Pro plan extends these limits, and charges usage based on active CPU time and provisioned memory time for Vercel Functions.
Active CPU time is based on the amount of CPU time your code actively consumes, measured in milliseconds. Waiting for I/O (e.g. calling AI models, database queries) does not count towards active CPU time. Provisioned memory time is based on the memory allocated to your function instances multiplied by the time they are running.
It is important to make sure you've set a reasonable maximum duration for your function. See "Managing usage and pricing for Vercel Functions" for more information.
If you have fluid compute enabled, the following environment variables are not accessible and you cannot log them:
AWS_EXECUTION_ENVAWS_LAMBDA_EXEC_WRAPPERAWS_LAMBDA_FUNCTION_MEMORY_SIZEAWS_LAMBDA_FUNCTION_NAMEAWS_LAMBDA_FUNCTION_VERSIONAWS_LAMBDA_INITIALIZATION_TYPEAWS_LAMBDA_LOG_GROUP_NAMEAWS_LAMBDA_LOG_STREAM_NAMEAWS_LAMBDA_RUNTIME_APIAWS_XRAY_CONTEXT_MISSINGAWS_XRAY_DAEMON_ADDRESSLAMBDA_RUNTIME_DIRLAMBDA_TASK_ROOT_AWS_XRAY_DAEMON_ADDRESS_AWS_XRAY_DAEMON_PORT_HANDLER_LAMBDA_TELEMETRY_LOG_FD
Was this helpful?