Note: This documentation is for version 1 of the Vercel platform. For the latest features, please see the version 2 documentation. If you have yet to upgrade, see the upgrade guide.

Environment Variables and Secrets

This document is based around environment variables and secrets for use in run-time for your app. For build-time env and secrets, read "Build-Time Env and Secrets".

If there's information or certain behavior of your project that needs to differ depending on if it's running locally or on now, environment variables are the perfect solution.

Not only do they avoid having to hardcode these settings (which is very important for sensitive information, which can't just be version-controlled), but they also allow you to access information about the current environment your code is running in.

There are various ways to define environment variables. Now you'll learn what's the right one for you.

e Option

The first one is simply specifying them using the -e option. Assuming that you'd like to add an environment variable named "DATABASE_NAME" and give it a value of "test", this is how the command should look like:

now -e DATABASE_NAME="test"

This will deploy the project within the current directory and assign the environment variable. In the code, you can then access it like this:


And just like defined before, the content of this global variable will be "test".

Config Files

The second way of defining environment variables is made specifically for the cases in which the content of the variables you'd like to define will stay the same for every new deployment.

If that fits your project, simply add the env property to your now.json file or to the now property inside package.json:

"env": {
  "DATABASE_NAME": "test"

As you may have already noticed it, this property holds an object which can contain as many environment variables as you want it to. And again, this will assign an environment variable called "DATABASE_NAME" with a value of "test" to your deployments.

--dotenv Option

This option will allow you to use a dotenv environment config file. It will be parsed and turned into -e automatically. Here's an example .env file:


Optionally you can provide a file to read. --dotenv=.env.production will read the .env.production file instead of .env. You can configure this option using now.json too. By adding the "dotenv" key with a value of true or the file name to use. An example is provided here.

Securing Env Variables Using Secrets

Sometimes you need to store sensitive information on the deployment that should only be accessible by the code that's running in it. This can be accomplished using now secret, which allows you to store such data needed by your apps to function (such as API tokens or passwords) in a secure way.

Once you store a secret, its contents are no longer accessible directly by anyone. They can only be exposed to deployments as environment variables, which we'll show below. Let's create a secret with an API key:

now secret add acme-api-key my-value-here

Once it's created, you can rename it with now secret rename or delete it completely with now secret rm. For more examples and the full list of options and commands, run now help secret.

Note: The name of a secret cannot be longer than 100 characters.

Afterward, you can assign the secret to an environment variable. Here's an example of doing this using a command:

now -e MY_VARIABLE=@acme-api-key

And here's how it should look when using the env configuration property:

"env": {
  "MY_VARIABLE": "@acme-api-key"

Both of the solutions mentioned above will create an environment variable called "MY_VARIABLE" and assign the content of the "acme-api-key" secret to it (which is "my-value-here").

Tips & Tricks

We implemented some sweet functionality into the command line interface and the platform, which make adding environment variables and secrets to your deployment even easier.

For example, you can also include -e multiple times:

now -e API_KEY=@my-key -e APP_NAME="My App"

And we also have the capability to inherit from your shell's environment. To do so, just skip the =value part:


How about other programming languages? The same mechanism applies to any project with a Dockerfile. The variables you include will be available to your CMD instruction.

You can even prevent devDependencies from being installed using an environment variable!

Finally, our API users will find the new /now/secrets REST endpoints useful.

Default Variables

By default, all deployments expose these environment variables:

  • NOW: Is set to 1, for detecting Now.
  • NOW_URL: Contains the unique URL of your deployment. Even if your deployment was aliased, this variable will always contain the URL with the suffix.