Limits

To prevent abuse of our platform, we apply the following limits to all accounts.

When using Next.js or SvelteKit on Vercel, dynamic code (APIs, server-rendered pages, or dynamic fetch requests) will be bundled into the fewest number of Serverless Functions possible, to help reduce cold starts. Because of this, it's unlikely that you'll hit the limit of 12 bundled Serverless Functions per deployment.

When using other frameworks, or Serverless Functions directly without a framework, every API maps directly to one Serverless Function. For example, having five files inside api/ would create five Serverless Functions. For Hobby, this approach is limited to 12 Serverless Functions per deployment.

The limit of "Routes created per Deployment" encapsulates several options that can be configured on Vercel:

• If you are using a vercel.json configuration file, each rewrite, redirect, or header is counted as a Route
• If you are using the Build Output API, you might configure routes for your deployments

Note that most frameworks will create Routes automatically for you. For example, Next.js will create a set of Routes corresponding to your use of dynamic routes, redirects, rewrites and custom headers.

Cron jobs invoke Serverless or Edge Functions. This means the same usage and pricing limits will apply.

On the hobby plan, you are limited to two daily cron jobs. This means you can create two cron jobs, each one triggered once a day.

On the hobby plan, we cannot assure a timely cron job invocation. For example, a cron job configured as 0 1 * * * (every day at 1 am) will trigger anywhere between 1:00 am and 1:59 am. For more accurate and timely cron job executions, upgrade to our pro plan.

For Teams on the Pro plan, you can pay for additional usage as you go.

For members of our Pro plan, we offer a pay-as-you-go model for additional usage, giving you greater flexibility and control over your usage. The typical monthly usage guidelines above are still applicable, while extra usage will be automatically charged at the following rates:

Check out the Limits and Pricing section for more details about the limits of Vercel Web Analytics.

Check out the Limits and Pricing doc for more details about the limits of the Speed Insights feature on Vercel.

The maximum duration of the Build Step is 45 minutes. When the limit is reached, the Build Step will be interrupted and the Deployment will fail.

Every Build is provided with the following resources:

• 8192 MB of memory
• 4 CPUs
• 13 GB of disk space

This cannot be increased. For more information on troubleshooting these, see Build container resources.

The maximum size of the Build's cache is 1 GB. It is retained for one month and it applies at the level of each Build cache key.

Check out the limits and pricing section for more details about the limits of the Monitoring feature on Vercel.

There are two types of logs: build logs and runtime logs. Both have different behaviors when storing logs.

Build logs are stored indefinitely for each deployment.

Runtime logs are stored for 1 hour on Hobby and Pro accounts and for 3 days on Enterprise accounts. To learn more about these log limits, read here.

The maximum number of Environment Variables per environment per Project is 1000. For example, you cannot have more than 1000 Production Environment Variables.

The total size of your Environment Variables, names and values, is limited to 64KB for projects using Node.js, Python, Ruby, Go, Java, and .NET runtimes. This limit is the total allowed for each deployment, and is also the maximum size of any single Environment Variable. For more information, see the Environment Variables documentation.

If you are using System Environment Variables, the framework-specific ones (i.e. those prefixed by the framework name) are exposed only during the Build Step, but not at runtime. However, the non-framework-specific ones are exposed at runtime. Only the Environment Variables that are exposed at runtime are counted towards the size limit.

The maximum number of files that can be uploaded when creating a CLI Deployment is 15,000 for source files. Deployments that contain more files than the limit will fail at the build step.

Although there is no upper limit for output files created during a build, you can expect longer build times as a result of having many thousands of output files (100,000 or more, for example). If the build time exceeds 45 minutes then the build will fail.

We recommend using Incremental Static Regeneration (ISR) to help reduce build time. Using ISR will allow you pre-render a subset of the total number of pages at build time, giving you faster builds and the ability to generate pages on-demand.

The amount of time (in seconds) that a proxied request (rewrites or routes with an external destination) is allowed to process an HTTP request. The maximum timeout is 30 seconds. If the external server does not reply until the maximum timeout is reached, an error with the message ROUTER_EXTERNAL_TARGET_ERROR will be returned.

Edge Functions and Serverless Functions do not support acting as a WebSocket server.

We recommend third-party solutions to enable realtime communication for Deployments.

The maximum size for a Serverless Function is 50 MB and the maximum unzipped size is 250 MB including layers which are automatically used depending on Runtimes. These limits are enforced by AWS to ensure you can't deploy Serverless Functions that take a long time to boot.

You can configure functions with includeFiles and excludeFiles which may affect the function size, however the limits cannot be configured.

The maximum memory size for a Serverless Function deployed on a Personal Account (Hobby plan) is 1024 MB. For Teams (Pro plan), it can be increased to up to 3008 MB.

You can use the functions property to adjust the memory size for each Serverless Function.

The amount of time (in seconds) that a Serverless Function is allowed to process an HTTP request before it must respond. The maximum execution timeout is 10 seconds when deployed on a Personal Account (Hobby plan). For Teams, the execution timeout is 60 seconds (Pro plan) or 900 seconds (Enterprise plan). Edge Functions provide an alternative that do not have a maximum execution timeout and that also allow you to continue streaming responses.

For more information, see the Execution Timeout section.

The maximum number of concurrent executions for Serverless Functions is 1000 by default. The concurrency limit is shared across all Projects deployed to a Team and can be observed with the usage of Log Drains.

Running into Rate Limiting? Check out our support guide on it here. If you require a limit above 1000, please contact our sales team to discuss custom limits available on an Enterprise plan. We recommend this ahead of high traffic events, such as marketing campaigns, product launches, or swag drops to ensure your concurrency limit is increased for handling anticipated traffic with ease. Alternatively, you can explore Edge Functions which do not have these concurrency limits.

The maximum payload size for the request body or the response body of a Serverless Function is 4.5 MB.

If a Serverless Function receives a payload in excess of the limit it will return an error → 413: FUNCTION_PAYLOAD_TOO_LARGE.

It is possible to deploy Serverless Functions to multiple regions, however this feature is limited to Enterprise plans. See also the documentation for more details.

When attempting to deploy Serverless Functions to multiple regions on a non-Enterprise plan, the Deployment will fail before entering the build step.

Serverless Functions are archived when they are not invoked:

• Within 2 weeks for Production Deployments
• Within 48 hours for Preview Deployments

Archived Functions will be unarchived when they're invoked, which can make the initial cold start time at least 1 second longer than usual.

The maximum size for an Edge Function is 1 MB (Hobby plan). For Teams, the maximum size is 2 MB (Pro plan) or 4 MB (Enterprise plan).

This is the total, compressed size of your function and its dependencies after bundling.

Edge Middleware and Edge Functions are allotted 128 MB of memory. This value cannot be adjusted.

Edge Middleware can use no more than 50ms of CPU time on average.

This limitation refers to actual net CPU time, which is the time spent performing calculations, not the total elapsed execution or "wall clock" time. For example, when you are blocked talking to the network, the time spent waiting for a response does not count toward CPU time limitations.

Edge Middleware and Edge Functions must begin sending a response within 30 seconds. You may continue streaming a response beyond that time.

If you want to perform additional work, you should return a response as soon as possible and continue with any asynchronous workloads in the background, after returning the response.

​Vercel does not support connecting your Personal Account's Projects to Git repositories owned by Git organizations. You can either switch to an existing Team or create a new one.

The same limitation applies in the Project creation flow when importing an existing Git repository or when cloning a Vercel template to a new Git repository as part of your Git organization.

See the Reserved Environment Variables docs for more information.

Rate limits are hard limits that apply to the platform when performing actions that require a response from our API.

The rate limits table consists of the following four columns:

• Description - A brief summary of the limit which, where relevant, will advise what type of plan it applies to.
• Limit - The amount of actions permitted within the amount of time (Duration) specified.
• Duration - The amount of time (seconds) in which you can perform the specified amount of actions. Once a rate limit is hit, it will be reset after the Duration has expired.
• Scope - Who the limit applies to: owner refers to the Personal Account Owner or Team Owner, user refers to a Team Member.

Below are five examples that provide further information on how rate limits work.

You are able to delete up to 60 domains every 60 seconds (1 minute). Should you hit the rate limit, you will need to wait another minute before you can delete another domain.

You are able to delete up to 20 teams every 3600 seconds (1 hour). Should you hit the rate limit, you will need to wait another hour before you can delete another team.

You are able to change your username up to 6 times every 604800 seconds (1 week). Should you hit the rate limit, you will need to wait another week before you can change your username again.

You are able to build 32 Deployments every 3600 seconds (1 hour). Should you hit the rate limit, you will need to wait another hour before you can build a deployment again.

You are able to deploy 100 times every 86400 seconds (1 day). Should you hit the rate limit, you will need to wait another day before you can deploy again.