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.
Making Deployments
There are multiple ways to make deployments with Vercel; these include via a Vercel for Git, Deploy Hooks, Vercel CLI, and the Vercel API.
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.
Git
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
Deploy Hooks allow you to create URLs that accept HTTP POST requests to trigger deployments, re-running the Build Step, from outside of Vercel.
There are many use cases for Deploy Hooks, for example, rebuilding your site to reflect changes in a Headless CMS or 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.
You can find more information about Deploy Hooks in the documentation.
Vercel CLI
By using Vercel CLI, you can deploy Projects with a single command from your terminal.
To make a preview deployment, use the vercel
command:
vercel
To make a production deployment, use the vercel --prod
command:
vercel --prod
Vercel API
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.
Deployment Types
There are two types of deployment on the Vercel platform: preview and production.
Preview
Preview deployments are the default for all deployments. Each time you push to a branch or make a deployment using the vercel
command, this is a preview deployment.
By making a preview deployment, the preview URL will be updated to reflect that of the latest deployment made.
The preview URL is provided on a pull or merge request when using Git and contains the name of the user or team to which the Project belongs.
If you request a preview URL, the X-Robots-Tag
HTTP header will be set as noindex
. This ensures that preview URLs will not be indexed by search engines such as Google. The only exception to this behavior exists when a custom domain is assigned to a preview branch. A custom domain assigned to a preview deployment will not set the the X-Robots-Tag
header with the value noindex
. Learn more about X-Robots-Tag
by visiting Google Search Reference.
Production
Production deployments are made in two different circumstances. Each time you merge to the Production Branch (commonly main
) or make a deployment using the vercel --prod
command, this is a production deployment.
By making a production deployment, the production domain(s) will be updated to reflect that of the latest deployment.
The production domain(s) are defined from the Domains tab of a Project on the Vercel Dashboard.
To add a production domain to a Project, visit Domains from the Project Overview page, you can read more about this in the custom domains documentation.
Managing Deployments
You can manage your deployments either via the Vercel Dashboard or, in advanced use cases, Vercel CLI.
Vercel Dashboard
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.
Vercel CLI and API
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.
Logs
There are three types of logs available, Build Time, Runtime, and Edge Network.
Build Time
Build Time logs are generated during the build step. These logs contain information about the build process and are stored indefinitely.
Edge Network
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
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.
There is a maximum size limit of 4kb for each log. If the size of the log exceeds this, only the last 4kb of data to arrive will be shown.
Special Paths
All deployment URLs have two special pathnames:
/_src
/_logs
Source View
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.
Logs View
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.
Security Considerations
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.
Technical Details
Deduplication
The URL structure of each preview deployment contains the name of the application and a random UID.
Vercel generates a new UID (and therefore a new deployment), by combining the following information into an internal digest that is looked up within the deployment database:
- The entire deployment configuration from
vercel.json
. - The owner ID (either the user ID or team ID, if deploying within a team).
- The description of the filesystem. This includes symlinks, modes, pathnames, and the checksum of each file's contents.
Vercel ensures that the digest is computed deterministically by sorting and ordering all the inputs involved in the algorithm.
Our lookup excludes deployments that are in an ERROR
state – if a previous deployment matches the digest but failed to build correctly.
Deduplication for Git Deployments
Learn more about how deduplication works when creating Deployments through a Git repository and how to customize the behavior here.
Skipping Deduplication
There are two ways to force a new deployment to be created when our system would otherwise deduplicate.
- Make any change to any of the parameters considered by the algorithm, listed above. For example, even changing one character in a comment of a source file yields a new deployment.
- Force a new deployment by instructing your client to do so.
- For Vercel CLI you can run
vercel --force
- If using our API, include the
forceNew
query parameter
- For Vercel CLI you can run