Jets loads environment variables from
.env files. The naming convention for these files is
Let’s say you have a Jets project that has the following dotenv files:
.env .env.development .env.test .env.production
.env file will always get loaded.
Environment Specific Variables
.env files will be loaded based on value of the
JETS_ENV environment variable in the machine you’re deploying from. So:
JETS_ENV=development jets deploywill use
JETS_ENV=test jets deploywill use
JETS_ENV=production jets deploywill use
You can set
JETS_ENV to any value, depending on whatever you want to name your environment.
Remote Only Variables
If you add “.remote” to the end of the filename, Jets will only load the values to the deployed Lambda environment. This can be useful if you need a local and remote version of the same environment. For example, you may want both a local and remote dev environment, and have the remote version using AWS RDS.
To use the remote version within the
jets console, you can use the
JETS_ENV_REMOTE=1 env variable. Example:
JETS_ENV_REMOTE=1 jets console
Jets Env Extra
The JETS_ENV_EXTRA concept supports its own dotenv file. Example:
JETS_ENV_EXTRA=2 jets console
.env.development.2. This takes the highest precedence and will override values in other dotenv files.
Dotenv File Precedence
Here’s an example with
JETS_ENV=development to explain the dotenv files precedence, from highest to lowest.
- .env.development.2 (highest) - Loaded when
- .env.development.remote - Loaded when
JETS_ENV_REMOTE=1is set locally or when on running on Lambda
- .env.local - Loaded for all environments except
- .env - (lowest) - Always loaded
SSM Parameter Store Support
AWS Systems Manager Parameter Store is supported. Storing secrets as SSM Parameters and referencing them your
.env files allows you to commit your
.env into source control. When you reference a parameter name with it will prefix the conventional
/<app-name>/<jets-env>/. If you reference the parameter name with a leading / then the conventional prefix is not added. For example:
RELATIVE_DATABASE_URL=ssm:database-url # references /<app-name>/<jets-env>/database-url ABSOLUTE_DATABASE_URL=ssm:/path/to/database-url # references /path/to/database-url
The SSM parameters are fetched and interpolated into your environment at build time so make sure to re-deploy your app after making changes to your SSM parameters to ensure they are picked up correctly.
Pro tip: Use the <- and -> arrow keys to move back and forward.