Edge Runtime

To convert your Vercel Function to use the Edge runtime, add the following code to your function:

export const runtime = 'edge'; // 'nodejs' is the default
 
export function GET(request: Request) {
  return new Response(`I am an Vercel Function!`, {
    status: 200,
  });
}

By default Edge Functions execute in the region closest to the incoming request. You can set one or more preferred regions using the route segment config preferredRegion or specify a regions key within a config object to set one or more regions for you functions to execute in

If your function depends on a data source, you may want it to be close to that source for fast responses.

To configure which region (or multiple regions) you want your function to execute in, pass the ID of your preferred region(s) in the following way:

export const runtime = 'edge'; // 'nodejs' is the default
// execute this function on iad1 or hnd1, based on the connecting client location
export const preferredRegion = ['iad1', 'hnd1'];
export const dynamic = 'force-dynamic'; // no caching
 
export function GET(request: Request) {
  return new Response(
    `I am an Vercel Function! (executed on ${process.env.VERCEL_REGION})`,
    {
      status: 200,
    },
  );
}

During regional outage, Vercel has automatic failover to the next closest region to maintain uptime. This is applicable for both global and regionally specified Edge Functions. See the outage resiliency docs for more information.

In the event of regional downtime, Vercel will automatically reroute traffic to the next closest Edge Network region on all plans. For more information on which regions Vercel routes traffic to, see Outage Resiliency.

You can't configure a maximum duration for functions using the Edge runtime. They can run indefinitely provided they send an initial response within 25 seconds.

You can only configure concurrency for functions using the Node.js runtime. Edge Functions cannot be configured.

The Edge runtime is built on top of the V8 engine, allowing it to run in isolated execution environments that don't require a container or virtual machine.

The Edge runtime provides a subset of Web APIs such as fetch, Request, and Response.

The following tables list the APIs that are available in the Edge runtime.

You can check if your function is running on the Edge runtime by checking the global globalThis.EdgeRuntime property. This can be helpful if you need to validate that your function is running on the Edge runtime in tests, or if you need to use a different API depending on the runtime.

if (typeof EdgeRuntime !== 'string') {
  // dead-code elimination is enabled for the code inside this block
}

The following modules can be imported with and without the node: prefix when using the import statement:

Also, Buffer is globally exposed to maximize compatibility with existing Node.js modules.

The Edge runtime has some restrictions including:

• Some Node.js APIs other than the ones listed above are not supported. For example, you can't read or write to the filesystem
• node_modules can be used, as long as they implement ES Modules and do not use native Node.js APIs
• Calling require directly is not allowed. Use import instead

The following JavaScript language features are disabled, and will not work:

You can use process.env to access Environment Variables.

Middleware with the edge runtime configured is neither a Node.js nor browser application, which means it doesn't have access to all browser and Node.js APIs. Currently, our runtime offers a subset of browser APIs and some Node.js APIs and we plan to implement more functionality in the future.

In summary:

• Use ES modules
• Most libraries that use Node.js APIs as dependencies can't be used in Middleware with the edge runtime configured.
• Dynamic code execution (such as eval) is not allowed (see the next section for more details)

Dynamic code execution is not available in Middleware with the edge runtime configured for security reasons. For example, the following APIs cannot be used:

You need to make sure libraries used in your Middleware with the edge runtime configured don't rely on dynamic code execution because it leads to a runtime error.

Middleware with the edge runtime configured must begin sending a response within 25 seconds.

You may continue streaming a response beyond that time and you can continue with asynchronous workloads in the background, after returning the response.

The maximum size for an Vercel Function using the Edge runtime 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.

Environment Variables can be accessed through the process.env object. Since JavaScript objects have methods to allow some operations on them, there are limitations on the names of Environment Variables to avoid having ambiguous code.

The following names will be ignored as Environment Variables to avoid overriding the process.env object prototype:

• constructor
• __defineGetter__
• __defineSetter__
• hasOwnProperty
• __lookupGetter__
• __lookupSetter__
• isPrototypeOf
• propertyIsEnumerable
• toString
• valueOf
• __proto__
• toLocaleString

Therefore, your code will always be able to use them with their expected behavior:

// returns `true`, if `process.env.MY_VALUE` is used anywhere & defined in the Vercel dashboard
process.env.hasOwnProperty('MY_VALUE');