Environment Variables

Environment Variables

There are several easy ways to configure environment variables with Jets.

Env Files Variables

Environment variables can be set with optional .env files. If there is an .env file at the root of your project. Jets will apply the env key value pairs in the file to all of your Lambda functions. Example:

.env:

global_env_key1=global_env_value1
global_env_key2=global_env_value2

Your app will have the environment variables global_env_key1 and global_env_key2 set in every single one of their lambda functions.

Env files conventions for specific JETS_ENV environments

Jets detects and uses env files based on a JETS_ENV convention to make it easier to apply different .env files to environments.

• If JETS_ENV=production and there's an .env.production file then Jets will use that file instead of the .env file.
• If JETS_ENV=staging and there's an .env.staging file then Jets will use that file instead of the .env file.
• If JETS_ENV is not set and there's an .env.development file then Jets will use that file instead of the .env file.

The .env file is the fallback when the JETS_ENV specific file do not exist.

Global Application Variables: config/application.rb

Environment variables can be set in the config/application.rb. This sets environment variables for all functions in your application.

config/application.rb

Jets.application.configure do
  config.environment(
    global_app_key1: "global_app_value1",
    global_app_key2: "global_app_value2"
  )
end

Your app will have the environment variables global_app_key1 and global_app_key2 set in every single one of their lambda functions. These settings can be overridden within each class as described in the next section.

Code Variables

Environment variables can be set in the app code with class_environment, environment or properties. Examples:

class HardJob < ApplicationJob
  # class_environment sets environment variables to all functions in the class
  class_environment(
    class_wide_key: "class_wide_value"
  )

  rate "10 hours" # every 10 hours
  def dig
    {done: "digging"}
  end

  rate "8 hours" # every 8 hours
  # environment sets environment variables to the specific function
  environment(
    function_specfic_key: "function_specific_value"
  )
  def drive
    puts("event data: #{event.inspect}")
    {done: "driving"}
  end

  # properties allow you to directly set the lambda function properties.
  properties(environment: {variables: {
    key_from_properties: "value_from_properties"
  }})
  cron "0 */12 * * ? *" # every 12 hours
  def lift
    {done: "lifting"}
  end
end

So in the case above:

• all methods dig, drive, and lift will have the environment variable class_wide_value.
• drive will have both environment variables class_wide_key and function_specific_key.
• lift will have both environment variables class_wide_key and key_from_properties.

Precedence

The precedence order from highest to lowest.

1. Code Variables: function specific. What the environment method sets.
2. Code Variables: class level. What the class_environment method sets.
3. Global Application Variables. What the config/application.rb sets.
4. Env Files Variables. What the .env file set.

Recommendation

The general recomendation is to use the env files for simplicity.

Special JETS_ENV env variable

The JETS_ENV variable will always be set on all lambda functions. You do not need to worry about seting it. It defaults to 'development'. You can override it in the CLI. Example:

JETS_ENV=staging jets deploy