Environment Variables 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.

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 your code, you can then access it through the language's default environment variable accessor. For example, with Node.js:


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

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:

  "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.

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").

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="ZEIT, Inc"

Additionally, we also have the capability to inherit from your shell environment. To do so, just skip the =value portion of the argument:


Users of the API can access the environment variables feature through the secrets endpoint.

By default, all deployments expose the NOW_REGION environment variable to lambdas which provides the region that the lambda was deployed to.

The following environment variables are reserved and therefore unavailable for use:

  • TZ

Using either, or any, of these environment variables will result in the deployment failing.