Edge Functions
Run minimal code at the network edge.Edge Functions are Vercel Functions that run on the Edge Runtime, a minimal JavaScript runtime that exposes a set of Web Standard APIs.
- Lightweight runtime: With a smaller API surface area and using V8 isolates, Edge runtime-powered functions have a slim runtime with only a subset of Node.js APIs are exposed
- Globally distributed by default: Vercel deploys all Edge Functions globally across its Edge Network, which means your site's visitors will get API responses from data centers geographically near them
We recommend migrating from edge to Fluid compute for improved performance and reliability.
Edge Functions execute in the region closest to the user, which could result in longer response times when the function relies on a database located far away. For example, if a visitor triggers an Edge Function in Japan, but it depends on a database in San Francisco, the Function will have to send requests to and wait for a response from San Francisco for each call.
To avoid these long roundtrips, you can limit your Edge Functions to regions near your database, or you could use a globally-distributed database. Vercel's storage options allow you to determine the best location for your database.
Feature | Support Status |
---|---|
Secure Compute | Not Supported |
Streaming | Supported |
Cron jobs | Supported |
Vercel Storage | Supported |
Edge Config | Supported |
OTEL | Not supported |
Streaming refers to the ability to send or receive data in a continuous flow.
The Edge runtime supports streaming by default.
Edge Functions do not have a maximum duration, but you must send an initial response within 25 seconds. You can continue streaming a response beyond that time.
All streaming functions support the waitUntil
method, which allows for an asynchronous task to be performed during the lifecycle of the request.
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.
Edge Functions are executed close to the end-users across Vercel's global network.
When you deploy Edge Functions, there are considerations you need to make about where it's deployed and executes. Edge Functions are executed globally and in a region close to the user's request. However, if your data source is geographically far from this request, any response will be slow. Because of this you can opt to execute your function closer to your data source.
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.
Edge Functions do not have filesystem access due to their ephemeral nature.
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.
As the Edge runtime is built on the V8 engine, it uses V8 isolates to separate just the runtime context, allowing for quick startup times and high performance.
Vercel places restrictions on the maximum size of the deployment bundle for functions to ensure that they execute in a timely manner. Edge Functions have plan-dependent size limits. This is the total, compressed size of your function and its dependencies after bundling.
Edge Functions have a fixed memory limit. When you exceeds this limit, the execution will be aborted and we will return a 502
error.
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.
Edge Functions have the following limits applied to the request size:
Name | Limit |
---|---|
Maximum URL length | 14 KB |
Maximum request body length | 4 MB |
Maximum number of request headers | 64 |
Maximum request headers length | 16 KB |
Edge Functions are neither Node.js nor browser applications, which means they don't have access to all browser and Node.js APIs. Currently, the Edge runtime offers a subset of browser APIs and some Node.js APIs.
There are some restrictions when writing Edge Functions:
- Use ES modules
- Most libraries which use Node.js APIs as dependencies can't be used in Edge Functions yet. See available APIs for a full list
- Dynamic code execution (such as
eval
) is not allowed for security reasons. You must ensure libraries used in your Edge Functions don't rely on dynamic code execution because it leads to a runtime error. For example, the following APIs cannot be used:API Description eval
Evaluates JavaScript code represented as a string new Function(evalString)
Creates a new function with the code provided as an argument WebAssembly.instantiate
Compiles and instantiates a WebAssembly module from a buffer source
See the Edge Runtime supported APIs for more information.
- You cannot set non-standard port numbers in the fetch URL (e.g.,
https://example.com:8080
). Only80
and443
are allowed. If you set a non-standard port number, the port number is ignored, and the request is sent to port80
forhttp://
URL, or port443
forhttps://
URL. - The maximum number of requests from
fetch
API is 950 per Edge Function invocation. - The maximum number of open connections is 6.
- Each function invocation can have up to 6 open connections. For example, if you try to send 10 simultaneous fetch requests, only 6 of them can be processed at a time. The remaining requests are put into a waiting queue and will be processed accordingly as those in-flight requests are completed.
- If in-flight requests have been waiting for a response for more than 15 seconds with no active reads/writes, the runtime may cancel them based on its LRU (Least Recently Used) logic.
- If you attempt to use a canceled connection, the
Network connection lost.
exception will be thrown. - You can
catch
on thefetch
promise to handle this exception gracefully (e.g. with retries). Additionally, you can use theAbortController
API to set timeouts forfetch
requests.
- If you attempt to use a canceled connection, the
To avoid CPU timing attacks, like Spectre, date and time functionality is not generally available. In particular, the time returned from Date.now()
only advances after I/O operations, like fetch
. For example:
export const runtime = 'edge';
export async function GET(request: Request) {
const currentDate = () => new Date().toISOString();
for (let i = 0; i < 500; i++) {
console.log(`Current Date before fetch: ${currentDate()}`); // Prints the same value 1000 times.
}
await fetch('https://worldtimeapi.org/api/timezone/Etc/UTC');
console.log(`Current Date after fetch: ${currentDate()}`); // Prints the new time
return Response.json({ date: currentDate() });
}
The table below outlines the limits and restrictions of using Edge Functions on Vercel:
Feature | Edge Runtime |
---|---|
Maximum memory | 128 MB |
Maximum duration | 25s (to begin returning a response, but can continue streaming data.) |
Size (after gzip compression) | Hobby: 1 MB, Pro: 2 MB, Ent: 4 MB |
Concurrency | Unlimited concurrency |
Cost | Pay for CPU time |
Regions | Executes global-first, can specify a region |
API Coverage | Limited API support |
Edge Middleware can use no more than 50 ms 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.
See the Vercel Functions Logs documentation for more information on how to debug and monitor your Edge Functions.
The Hobby plan offers functions for free, within limits. The Pro plan extends these limits, and charges CPU Time for Edge Functions.
Edge runtime-powered functions usage is based on CPU Time. CPU time is the time spent actually processing your code. This doesn't measure time spent waiting for data fetches to return. See "Managing usage and pricing for Edge Functions" for more information.
Functions using the Edge Runtime are measured in the number of execution units, which are the amount of CPU time — or time spent performing calculations — used when a function is invoked. CPU time does not include idle time spent waiting for data fetching.
A function can use up to 50 ms of CPU time per execution unit. If a function uses more than 50 ms, it will be divided into multiple 50 ms units for billing purposes.
See viewing function usage for more information on how to track your usage.
The following table outlines the price for each resource according to the plan you are on.
Edge Functions are available for free with the included usage limits. If you exceed the included usage and are on the Pro plan, you will be charged for the additional usage according to the on-demand costs:
Resource | Hobby Included | Pro Included | Pro Additional |
---|---|---|---|
Edge Function Execution Units | First 500,000 | First 1,000,000 | $2.00 per 1,000,000 Execution Units |
Function Invocations | First 100,000 | First 1,000,000 | $0.60 per 1,000,000 Invocations |
Vercel will send you emails as you are nearing your usage limits. On the Hobby plan you will not pay for any additional usage. However, your account may be paused if you do exceed the limits.
When your Hobby team is set to paused, it remains in this state indefinitely unless you take action. This means all new and existing deployments will be paused.
If you have reached this state, your application is likely a good candidate for a Pro account.
To unpause your account, you have two main options:
- Contact Support: You can reach out to our support team to discuss the reason for the pause and potential resolutions
- Transfer to a Pro team:
If your Hobby team is paused, you won't have the option to initiate a Pro trial. Instead, you can set up a Pro team:
- Create a Pro team account
- Add a valid credit card to this account. Select the Settings tab, then select Billing and Payment Method
Once set up, a transfer modal will appear, prompting you to transfer your previous Hobby projects to this new team. After transferring, you can continue with your projects as usual.
For teams on a Pro trial, the trial will end when your team reaches the trial limits.
Once your team exceeds the included usage, you will continue to be charged the on-demand costs going forward.
Pro teams can set up Spend Management to get notified or to automatically take action, such as using a webhook or pausing your projects when your usage hits a set spend amount.
Enterprise agreements provide custom usage and pricing for Edge Functions, including:
- Custom execution units
- Multi-region deployments
See Vercel Enterprise plans for more information.
Usage metrics can be found in the Usage tab on your dashboard. Functions are invoked for every request that is served.
You can see the usage for functions using the Edge Runtime on the Edge Functions section of the Usage tab. The dashboard tracks the usage values:
Was this helpful?