A deployment is the result of building your Project and making it available through a live URL.

This section contains information about making, managing, and understanding the behavior of deployments.

Deployments can be made with Vercel via the following:

When making deployments, the Project will be uploaded and transformed into a production-ready output through the use of a Build Step.

Once the build step has completed successfully, a new, immutable deployment will be made available at the preview URL. Deployments are retained indefinitely unless deleted manually.

You can make deployments with Git by using either the Vercel for GitHub, Vercel for GitLab, or Vercel for Bitbucket.

When using these integrations, every push to a branch will provide you with a preview deployment to view your changes.

When merging to the Production Branch (commonly main), a production deployment will be made.

Deploy Hooks allow you to create URLs that accept HTTP POST requests to trigger deployments, re-running the Build Step, from outside of Vercel.

Use cases for Deploy Hooks include:

  • Rebuilding your site to reflect changes in a Headless CMS
  • Scheduling deployments with Cron Jobs

To create a Deploy Hook, visit the settings page of your Project where you can choose the branch to deploy when the HTTP endpoint receives a POST request.

Note: Deploy Hooks require a connected Git Repository.

You can find more information about Deploy Hooks in the documentation.

By using Vercel CLI, you can deploy Projects with a single command from your terminal.

To make a preview deployment, use the vercel command:


Making a preview deployment with the vercel command.

Note: The first deployment for a Project is always both a preview and production deployment.

To make a production deployment, use the vercel --prod command:

vercel --prod

Making a production deployment with the vercel command.

The Vercel API can be used to make deployments by making an HTTP POST request to the relevant endpoint, including the files you wish to deploy as the body.

You can find more information about the Vercel API in the API Reference.

You can manage your deployments either via the Vercel Dashboard or, in advanced use cases, Vercel CLI.

The Vercel Dashboard is the easiest way for you to manage your deployments.

Through the Vercel Dashboard, you can find a variety of settings; including a Domains tab where you can add custom domains to your Project.

The Vercel CLI and Vercel API provide alternative ways to manage your deployments.

You can find a full list of the commands available in the Vercel CLI Reference, along with the deployments section of the Vercel API Reference.

You can filter and sort your deployments based on branch and status. Go to the Deployments tab inside your Project dashboard. A drop-down for Status sorts the deployments according to the desired status code.

Filter and sort Deployments for a Vercel project.

These are the following Status values:

  • Ready: A successful deployment
  • Error: An unsuccessful or failed deployment
  • Building: A deployment currently being built
  • Queued: A deployment waiting to be built
  • Canceled: A deployment that was canceled

You will also find a drop-down search menu with a placeholder text for "All Branches". This helps you select any deployed branch from the drop-down or filter by typing in the search box.

The three types of logs available are, Build Time, Runtime, and Edge Network.

Build Time logs are generated during the build step. These logs contain information about the build process and are stored indefinitely.

Edge Network logs are generated when requesting a path from the Edge. These logs contain information about a request to a specific path with details such as the path name, request method, and status code. These logs are not persisted.

Runtime logs are generated by Serverless Functions while they're being invoked. Runtime logs are stored in memory only as they arrive from the Serverless Function and are not persisted.

The only exception to this are failed requests. If a request leads to the Serverless Function throwing an error, the log for this will be stored indefinitely whereas all other Runtime logs will be lost when navigating away from the page.

Note: If you wish to persist Runtime or Edge Network logs, you can use a logging integration available from the Vercel Integrations Marketplace. Alternatively, you may build your own service by making use of the Log Drains API.

The maximum size limit of each log is 4kb. If the size of the log exceeds this, only the last 4kb of data to arrive will be shown.

All deployment URLs have two special pathnames:

  • /_src
  • /_logs

By appending /_src to a deployment URL or custom domain, the deployment inspector will be open and you'll be able to browse your deployment sources and build outputs.

By appending /_logs to a deployment URL or custom domain, you will be able to see a realtime stream of logs from your deployment build processes and serverless invocations.

These pathnames redirect to https://vercel.com and require logging in to access any sensitive information. By default, a 3rd-party can never access your source or logs by crafting a deployment URL with one of these paths.

However, you can configure project settings to make these paths public. Learn more here.