Serverless Functions Overview

Serverless Functions enable developers to write functions in JavaScript and other languages to handle user authentication, form submissions, database queries, custom Slack commands, and more.

These Functions are co-located with your code and part of your Git workflow. As traffic increases, they automatically scale up and down to meet your needs, helping you to avoid paying for always-on compute with no downtime.

Serverless Functions location within Vercel infrastructure.

Serverless Functions should always execute close to where your data source is to reduce latency. By default, Serverless Functions execute in Washington, D.C., USA (iad1) as many external data sources are hosted on the East Coast of the USA. You can set a new default region through your project's settings on Vercel.

Enterprise teams can set multiple regions.

Sometimes, you need to place extra code files, such as utils.js or my-types.d.ts, inside the /api folder. To avoid turning these files into Serverless Functions, Vercel ignores files when prefixed with the following characters:

• Files that start with an underscore, _, are ignored
• Files that start with . are ignored
• Files that end with .d.ts are ignored

If your file is prefixed with any of the above, it will not be turned into an Serverless Function.

With Vercel, for each incoming request to a serverless function, a new invocation happens.

If a request is received shortly after a function is executed, Vercel optimizes performance by reusing that function for the subsequent invocation. Over time, only as many functions as necessary are kept active to accommodate incoming traffic.

In the absence of additional incoming traffic, Serverless Functions on Vercel will scale down to zero.

Runtime logs for Serverless Functions can be found in the Logs tab. These logs are held for an amount of time based on your plan.

next dev

You can use runtime logs to view all the logs related to your serverless functions.

You can filter to see Serverless Functions by selecting Serverless under Type. You can also use the Functions section to search by and view the logs for specific functions.

When a Serverless Function on a specific path receives a user request, you may see more than one log when the application renders or regenerates the page.

This can occur in the following situations:

1. When a new page is rendered
2. When you are using Incremental Static Regeneration (ISR)

In the case of ISR, multiple logs are the result of:

• A stale page having to be regenerated
• On-demand ISR happening with fallback set as blocking

For a stale page, it happens because there are two things that need to be rendered:

1. The HTML, which is used when you navigate to the page URL in your browser
2. The JSON, which is used when you navigate to the page through a link as a Single Page App (SPA) transition

Both the HTML and JSON need to be in sync and rendered at the same time. Otherwise, you will see different behavior between browser navigation and a SPA transition.

For on-demand ISR, the following happens:

• Synchronous rendering to load the page (HTML, for example) on-demand when it was requested
• Revalidate the 2 versions (HTML, JSON) in the background

In Next.js projects, the functions listed are those API Routes defined by the files placed in pages/api/**/*.ts with the pages directory, and app/**/route.ts with the app directory.

However, pages that use SSR, such as those that call getServerSideProps or export revalidate, will also be available both in the filter dropdown and the real time logs.

In order to optimize resources, there is an internal process that bundles as many Serverless Functions as possible into a single Lambda. Such a feature is currently only enabled for Next.js, but it will be enabled in other scenarios in the future.

This internal process shouldn't affect the developer in any case. However, if a configuration on the functions property is present in current versions of Next.js (>= v10.0.9), then the internal process will bundle functions based on the configuration first. The remaining functions will be bundled together optimizing for how many functions are created.

{
  "functions": {
    "app/api/hello/route.ts": {
      "memory": 3008,
      "maxDuration": 60
    },
    "app/api/another/route.ts": {
      "memory": 1024,
      "maxDuration": 30
    }
  }
}

For an advanced configuration, you can create a vercel.json file to use Runtimes and other customizations. To view more about the properties you can customize, review the advanced usage section of Runtimes and Project config with vercel.json.

If your use case requires that you work asynchronously with the results of a function invocation, you may need to consider a queuing, pooling, or streaming approach because of how serverless functions are created on Vercel. See the lifecycle of a serverless function section for more information.

For information on improving the performance of your Serverless Functions and understanding how to determine if the latency increase is from a cold start, see How can I improve serverless function cold start performance on Vercel?

Serverless Functions using the Node.js runtime support all Node.js APIs, including standard Web APIs.

The following Serverless Function uses the URL API to check a request URL for a search parameter:

import { NextResponse } from 'next/server';
 
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const hasTitle = searchParams.has('title');
  const title = hasTitle
    ? searchParams.get('title')?.slice(0, 100)
    : 'My default title';
 
  return NextResponse.json(
    { title },
    {
      status: 200,
    },
  );
}

Serverless Functions are allocated CPU power according to the amount of memory configured for them.

For example, with 1,769MB memory configured, a Serverless Function will have the equivalent of one vCPU.

To learn more about all limits for Serverless Functions, see the Runtimes reference. This highlights common limits such as size, memory, concurrency, payload size limit, duration, and pricing.

For more information on what to do next, we recommend the following articles: