If there are aspects of your project that need to differ depending on whether it is a local or cloud deployment, 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 in development, let's explore these options.
Using a .env
File
By using a .env
file, you will define a set of key value pairs accessible from within your Lambda functions.
Each line in a .env
file is written as a string and follows the format KEY=VALUE
as seen in the example below:
MYSQL_PASSWORD=lambda
An example .env
file specifying an environment variable.
The syntax required to use an environment variable inside a Lambda function differs for each language, in Node.js this would be:
process.env.MYSQL_PASSWORD
Accessing the environment variable with Node.js.
This would return the value "lambda".
Using a .env.build
File
By using a .env.build
file, you will define a set of key value pairs accessible from within the build object.
Each line in a .env.build
file is written as a string and follows the format KEY=VALUE as seen in the example below:
MYSQL_DATABASE=build
An example .env.build
file specifying an environment build variable.
Using now.json
The last way of defining environment variables during development is made specifically for when 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" } }
An example now.json
configuration file specifying an environment variable.
As you may have already noticed, this property holds an object which can contain as many environment variables as you need. Once again, this will assign an environment variable called "DATABASE_NAME" with a value of "test" to your deployments.
You can also pass environment variables to Build processes on a deployment via the build.env
configuration property:
{ "build": { "env": { "MY_KEY": "this is the value" } } }
An example now.json
configuration file specifying a build environment variable.
The configuration above will pass the static env key MY_KEY
to all builds.
Further Tips
We implemented some sweet functionality into the command line interface and the platform, which makes adding environment variables and secrets to your deployment even easier.
For example, you can also include -e
multiple times:
Assigning multiple environment variables in one command using the terminal.
Additionally, there is also the capability to inherit from your shell environment. To do so, just skip the =value
portion of the argument:
Inheriting an environment variable from the shell environment.
Users of the API can access the environment variables feature through the secrets
endpoint.
Built-In Variables
By default, all deployments expose the NOW_REGION
environment variable to lambdas which provides the region that the lambda was deployed to.
Reserved Variables
There are a few variable names reserved and are therefore unavailable for use.
Using either, or any, of these environment variables, will result in the deployment failing.
Read Next
Read more on how development with Now works and get answers to frequently asked questions: