Deployment Environments

A typical deployment lifecycle for web development has the following steps:

• Local preview on the developer's computer
• Staging on a remote test server
• Production on a remote production server

Environments are the solution for this deployment lifecycle on Vercel. The production environment is usually connected to your production domain and is only deployed under certain conditions. The preview environment is similar to the staging environment so that you can test your code remotely and preview changes without affecting the production instance.

Production deployments are usually made in two different circumstances:

1. When you merge or push to the production branch (commonly main)
2. When you make a deployment using the vercel --prod command

The production domain(s) is updated with the latest deployment when you trigger a production deployment.

You can update the production domain(s) in the Domains tab of a Project on the Vercel Dashboard.

To add a production domain to a Project:

• Go to the Settings tab on the Project overview page
• Go to the Domains section and click "Add"

You can read more about this in the custom domains section.

You can configure Environment Variables for each environment directly from the Project settings. Check out the Environment variables section to learn more.

When you define Environment Variables as key-value pairs using the dashboard or Vercel CLI, they are configured outside your source code. These variables are available to your source code during the build process.

You can change the value of any environment variable at any point without changing your code. However, make sure to Redeploy your project to update the value of these variables in the deployment.

Some frameworks do not use package.json to select a specific version to install during build time. In this case, you can use an Environment Variable to define your framework's version in the following cases:

For example, to select Hugo v0.92.2, you will add an Environment Variable named HUGO_VERSION with the value 0.92.2.

The value must match an existing GitHub Release with an attached asset. For example, Hugo 0.92.2 exists but Hugo 0.92 does not exist.