Vercel Primitives

The following directories, code files, and configuration files represent all Vercel platform primitives. These primitives are the "building blocks" that make up a Vercel Deployment.

Files outside of these directories are ignored and will not be served to visitors.

Static files that are publicly accessible from the Deployment URL should be placed in the .vercel/output/static directory. These files are served via the Vercel Edge Network.

Files placed within this directory will be made available at the root (/) of the Deployment URL and neither their contents, nor their file name or extension will be modified in any way. Sub directories within static are also retained in the URL, and are appended before the file name.

There is no standalone configuration file that relates to static files.

However, certain properties of static files (such as the Content-Type response header) can be modified by utilizing the overrides property of the config.json file.

The following example shows static files placed into the .vercel/output/static directory:

A Serverless Function is represented on the file system as a directory with a .func suffix on the name, contained within the .vercel/output/functions directory.

Conceptually, you can think of this .func directory as a filesystem mount for a Serverless Function: the files below the .func directory are included (recursively) and files above the .func directory are not included. Private files may safely be placed within this directory because they will not be directly accessible to end-users. However, they can be referenced by code that will be executed by the Serverless Function.

A .func directory may be a symlink to another .func directory in cases where you want to have more than one path point to the same underlying Serverless Function.

A configuration file named .vc-config.json must be included within the .func directory, which contains information about how Vercel should construct the Serverless Function.

The .func suffix on the directory name is not included as part of the URL path of Serverless Function on the Deployment. For example, a directory located at .vercel/output/functions/api/posts.func will be accessible at the URL path /api/posts of the Deployment.

The .vc-config.json configuration file contains information related to how the Serverless Function will be created by Vercel.

type ServerlessFunctionConfig = {
  handler: string;
  runtime: string;
  memory?: number;
  maxDuration?: number;
  environment: Record<string, string>[];
  regions?: string[];
  supportsWrapper?: boolean;
  supportsResponseStreaming?: boolean;
};

This extends the Base Config for Node.js Serverless Functions.

type NodejsServerlessFunctionConfig = ServerlessFunctionConfig & {
  launcherType: 'Nodejs';
  shouldAddHelpers?: boolean; // default: false
  shouldAddSourceMapSupport?: boolean; // default: false
};

This is what the .vc-config.json configuration file could look like in a real scenario:

{
  "runtime": "nodejs16.x",
  "handler": "serve.js",
  "maxDuration": 3,
  "launcherType": "Nodejs",
  "shouldAddHelpers": true,
  "shouldAddSourcemapSupport": true
}

The following example shows a directory structure where the Serverless Function will be accessible at the /serverless URL path of the Deployment:

An Edge Function is represented on the file system as a directory with a .func suffix on the name, contained within the .vercel/output/functions directory.

The .func directory requires at least one JavaScript or TypeScript source file which will serve as the entrypoint of the function. Additional source files may also be included in the .func directory. All imported source files will be bundled at build time.

WebAssembly (Wasm) files may also be placed in this directory for an Edge Function to import. See Using a WebAssembly file for more information.

A configuration file named .vc-config.json must be included within the .func directory, which contains information about how Vercel should configure the Edge Function.

The .func suffix is not included in the URL path. For example, a directory located at .vercel/output/functions/api/edge.func will be accessible at the URL path /api/edge of the Deployment.

Edge Functions will bundle an entrypoint and all supported source files that are imported by that entrypoint. The following list includes all supported content types by their common file extensions.

• .js
• .json
• .wasm

The .vc-config.json configuration file contains information related to how the Edge Function will be created by Vercel.

type EdgeFunctionConfig = {
  runtime: 'edge';
  entrypoint: string;
  envVarsInUse?: string[];
  regions?: 'all' | string | string[];
};

This is what the .vc-config.json configuration file could look like in a real scenario:

{
  "runtime": "edge",
  "entrypoint": "index.js",
  "envVarsInUse": ["DATABASE_API_KEY"]
}

The following example shows a directory structure where the Edge Function will be accessible at the /edge URL path of the Deployment:

A Prerender asset is a Serverless Function that will be cached by the Vercel Edge Network in the same way as a static file. This concept is also known as Incremental Static Regeneration.

On the file system, a Prerender is represented in the same way as a Serverless Function, with an additional configuration file that describes the cache invalidation rules for the Prerender asset.

An optional "fallback" static file can also be specified, which will be served when there is no cached version available.

The <name>.prerender-config.json configuration file contains information related to how the Edge Function will be created by Vercel.

type PrerenderFunctionConfig = {
  expiration: number | false;
  group?: number;
  bypassToken?: string;
  fallback?: string;
  allowQuery?: string[];
};

A Prerender asset may also include a static "fallback" version that is generated at build-time. The fallback file will be served by Vercel while there is not yet a cached version that was generated during runtime.

When the fallback file is served, the Serverless Function will also be invoked "out-of-band" to re-generate a new version of the asset that will be cached and served for future HTTP requests.

This is what an example.prerender-config.json file could look like in a real scenario:

{
  "expiration": 60,
  "group": 1,
  "bypassToken": "03326da8bea31b919fa3a31c85747ddc",
  "fallback": "example.prerender-fallback.html",
  "allowQuery": ["id"]
}

The following example shows a directory structure where the Prerender will be accessible at the /blog URL path of the Deployment: