Runtimes

Vercel supports multiple runtimes for your functions. Each runtime has its own set of libraries, APIs, and functionality that provides different trade-offs and benefits.

Runtimes transform your source code into Functions, which are served by our Edge Network.

Vercel Functions support the following official runtimes:

If you would like to use a language that Vercel does not support by default, you can use a community runtime by setting the functions property in vercel.json. For more information on configuring other runtimes, see Configuring your function runtime.

The following community runtimes are recommended by Vercel:

You can create a community runtime by using the Runtime API. Alternatively, you can use the Build Output API.

• Location: Deployed as region-first, can customize location. Pro and Enterprise teams can set multiple regions
• Failover: Automatic failover to defined regions
• Automatic concurrency scaling: Auto-scales up to 30,000 (Hobby and Pro) or 100,000+ (Enterprise) concurrency
• Isolation boundary: microVM
• File system support: Read-only filesystem with writable /tmp scratch space up to 500 MB
• Archiving: Functions are archived when not invoked
• Functions created per deployment: Hobby: Framework-dependent, Pro and Enterprise: No limit

Location refers to where your functions are executed. Vercel Functions are region-first, and can be deployed to up to 3 regions on Pro or 18 on Enterprise. Deploying to more regions than your plan allows for will cause your deployment to fail before entering the build step.

Vercel's failover mode refers to the system's behavior when a function fails to execute because of data center downtime.

Vercel provides redundancy and automatic failover for Edge Functions to ensure high availability. For Serverless Functions, you can use the functionFailoverRegions configuration in your vercel.json file to specify which regions the function should automatically failover to.

In Vercel, the isolation boundary refers to the separation of individual instances of a function to ensure they don't interfere with each other. This provides a secure execution environment for each function.

With traditional serverless infrastructure, each function uses a microVM for isolation, which provides strong security but also makes them slower to start and more resource intensive.

Filesystem support refers to a function's ability to read and write to the filesystem. Serverless Functions have a read-only filesystem with writable /tmp scratch space up to 500 MB.

Vercel 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.

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 Vercel Functions possible, to help reduce cold starts. Because of this, it's unlikely that you'll hit the limit of 12 bundled Vercel Functions per deployment.

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

A runtime can retain an archive of up to 100 MB of the filesystem at build time. The cache key is generated as a combination of:

• Project name
• Team ID or User ID
• Entrypoint path (e.g., api/users/index.go)
• Runtime identifier including version (e.g.: @vercel/go@0.0.1)

The cache will be invalidated if any of those items changes. You can bypass the cache by running vercel -f.

You can use environment variables to manage dynamic values and sensitive information affecting the operation of your functions. Vercel allows developers to define these variables either at deployment or during runtime.

You can use a total of 64 KB in environments variables per-deployment on Vercel. This limit is for all variables combined, and so no single variable can be larger than 64 KB.

The following features are supported by Vercel Functions:

Vercel's Secure Compute feature offers enhanced security for your Vercel Functions, including dedicated IP addresses and VPN options. This can be particularly important for functions that handle sensitive data.

Streaming refers to the ability to send or receive data in a continuous flow.

The Node.js runtime supports streaming by default. Streaming is also supported when using the Python runtime.

Vercel Functions have a maximum duration, meaning that it isn't possible to stream indefinitely.

All streaming functions support the waitUntil method, which allows for an asynchronous task to be performed during the lifecycle of the request. This means that while your function will likely run for the same amount of time, your end-users can have a better, more interactive experience.

Cron jobs are time-based scheduling tools used to automate repetitive tasks. When a cron job is triggered through the cron expression, it calls a Vercel Function.

From your function, you can communicate with a choice of data stores. To ensure low-latency responses, it's crucial to have compute close to your databases. Always deploy your databases in regions closest to your functions to avoid long network roundtrips. For more information, see our best practices documentation.

An Edge Config is a global data store that enables experimentation with feature flags, A/B testing, critical redirects, and IP blocking. It enables you to read data at the edge without querying an external database or hitting upstream servers.

Vercel has an OpenTelemetry (OTEL) collector that allows you to send OTEL traces from your Vercel Functions to application performance monitoring (APM) vendors such as New Relic.