If there's information or certain behaviour 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 the code, you can then access it like this:
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 or to the now property inside package.json:
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.
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.
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.
Afterwards, 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:
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").