Skip to content


Registry loads settings into its config object the first time the common.Context() function is called.

Registry loads settings from the .env file whose name matched the APT_ENV environment variable. For example, if APT_ENV=dev, Registry will load settings from the file in the top level directory of the Registry project. If APT_ENV=test, it will load .env.test.

After loading settings from the file, the config object loads them from the environment using Viper's AutomaticEnv() function. Values loaded from the environment override values defined in the .env file.

This is handy in Fargate/ECS because we can store sensitive settings, such as database credentials, in Amazon's Parameter Store. Before ECS starts the Registry's Docker container, it runs a sidecar process to load environment variables from Parameter Store. Those variables are then available in the environment when Registry starts, and the config object can read them.


Store sensitive credentials in your local environment for dev and test, or in parameter store for live environments. Otherwise, you risk accidentally leaking credentials, most likely in a GitHub commit.

Sentive credentials include:


Setting Definitions

Name Description
AWS_ACCESS_KEY_ID AWS access key for connecting to SES and SNS services.
AWS_REGION The AWS region to connect to for SES and SNS services. This should be the same region Registry runs in, which is us-east-1a.
AWS_SECRET_ACCESS_KEY The AWS secret key for connecting to SES and SNS services.
COOKIE BLOCK_KEY Used along with COOKIE_HASH_KEY to encrypt cookies stored in the user's browser.
COOKIE_DOMAIN The name of the domain that can set and read cookies. For development and test, this should be localhost. For live environments, it should match the fully qualified domain name, e.g.
COOKIE_HASH_KEY Used along with COOKIE_BLOCK_KEY to encrypt cookies stored in the user's browser.
DB_DRIVER The name of the dabase driver. This should always be postgres.
DB_HOST The name of the databse host. For dev and test, this should be localhost. For live environments, it should be the fully qualified domain name or internal private hostname of the RDS instance that hosts our postgres database.
DB_NAME The name of the database. E.g. apt_registry_test or pharos_demo.
DB_PASSWORD The password to connect to the postgres database.
DB_PORT The postgres database port. Usually 5432.
DB_USER The username to connect to the postgres database.
DB_USE_SSL Should we use SSL when connecting to the database? For localhost connections, this is usually false. For RDS connections, it should be true.
EMAIL_ENABLED Set this to true on all live systems and to false for dev and test systems. When set to false, Registry will print the contents of emails to STDOUT. This is helpful for testing "forgot password" emails and deletion confirmation emails.
EMAIL_FROM_ADDRESS The from address to attach to all system-generated emails. Typically, this is
ENABLE_TWO_FACTOR_AUTHY Set this to true in live systems and false in dev and test systems.
ENABLE_TWO_FACTOR_SMS Set this to true in live systems and false in dev and test systems. When set to false, Registry will print two-factor SMS codes to STDOUT so developers can complete the login process.
FLASH_COOKIE_NAME The name of the cookie used to display transient notifications in the web UI.
HTTPS_COOKIES Set this to true on live systems that use HTTPS connections, and to false for dev and test setups that run on localhost.
LOG_CALLER When true, this logs additional information about the calling function in certain log messages. For live systems, this should be false, unless we're debugging difficult issues.
LOG_FILE The path to the file where Registry should write its log statements. Setting this STDOUT causes Registry to log to STDOUT. On live systems, set this to STDOUT so the logs go into CloudWatch.
LOG_LEVEL This describes how detailed the logs should be. For production systems, we generally want 1 (info). For dev and test systems, 0 (debug) will provide additional information. Allowed values are: -1: Trace, 0: Debug, 1: Info, 2: Warn, 3: Error, 4: Fatal, 5: Panic, 6: None, 7: Disabled
LOG_SQL If true, Registry will log all SQL statements. We almost always want this set to false because it produces massive logs. Use this only to debug tricky SQL issues.
LOG_TO_CONSOLE If true, Registry will log to the console as well as to the log file. On live systems (prod, demo, staging), this should be false because we log to STDOUT anyway. On dev and test systems, you can set this to true to watch the logs in your console as you interact with Registry.
NSQ_URL The URL of the NSQ service. Note that NSQ usually runs three processes (nsqd, nsqlookupd, and nsqadmin) on three different ports. The one you want here is nsqd, which runs on port 4151. On a local dev machine, this will be http://localhost:4151
OTP_EXPIRATION The time before a two-factor OTP token expires. These tokens are sent via SMS. This setting uses Go's time notation, so 90s is 90 seconds, 15m is 15 minutes, 1h is one hour.
PREFS_COOKIE_NAME The name of Registry's preferences cookie. This is not yet in use, but may be in future.
REDIS_DEFAULT_DB The default Redis database we want to connect to. This is a numeric value between 0-15, and is almost always 0 (zero).
REDIS_PASSWORD The password used to connect to the Redis database.
REDIS_URL The URL of the Redis server to connect to. This should include a hostname and port, but not a protocol. E.g. localhost:6379.
SESSION_COOKIE_NAME The name of the Registry's session cookie.
SESSION_MAX_AGE The maximum time, in seconds, that the session cookie can live. This is usually set between 86400 (one day) and 604800 (seven days). Note that this setting actually applies to all cookies.