Secrets

Architect secrets can be anything ranging from log levels to production database credentials. Whatever they may be, there are a number of ways for these secret values to be provided, and this document will outline the available methods. We’ll assume you have registered the following two components:

# ./component/architect.yml
name: component
dependencies:
  dependency: latest
secrets:
  secret_key:
    required: true
services:
  api:
    environment:
      SECRET_KEY: ${{ secrets.secret_key }}

# ./dependency/architect.yml
name: dependency
secrets:
  username:
    required: true
  password:
    required: true
services:
  dependency:
    environment:
      USERNAME: ${{ secrets.username }}
      PASSWORD: ${{ secrets.password }}

From the command line, the simplest way to specify secret values for components is by doing so directly from the deploy command. The command supports a --secret or -s flag that allows you to specify the secret key and value as follows:

$ architect deploy dependency -s username=my-username -s password=my-password

​

Using a config file

Using the --secret flag is great for specifying values for individual components, but doesn’t allow you to specify values for component dependencies. In order to specify secret values for your component and it’s dependencies, something common when generating on-demand environments, you’ll need to create a secrets file. The Architect CLI supports two options: an Architect secrets file in .yml format, or a .env file.

​

Architect secrets file

# secrets.yml
component:
  secret_key: my-secret-key
dependency:
  username: my-username
  password: my-password

This file can then be specified directly in the deploy command to apply values to any components matching the keys in the file. The command below will deploy component, and since it has a dependency, that will automatically be deployed as well. Each component’s name matches a key in the file above so all the required secrets will be fulfilled.

$ architect deploy component --secret-file secrets.yml

The keys in the secrets file are simply patterns for matching components. Some examples are:

"*": # applies to all components in your account
  ...
foo-api: # applies to all versions of the foo-api component
  ...
foo-api@instance2: # applies to only the foo-api tenant named "instance2"
  ...

​

.env file

Architect also supports loading secrets from a .env file such as the one below. Secrets parsed from a .env file will be mapped to any component that expects the secret name. Rules for parsing a .env file can be found here and variables can be expanded during loading following the rules defined in dotenv-expand.

secret_key=my-secret-key
username=my-username
password=my-password

Deploying a component using secrets from a .env file is the same as with an Architect secrets file. Just specify the name of the file after the --secret-file flag.

$ architect deploy component --secret-file .env

​

Using the ARC_ prefix

Environment variables set in a shell and prefixed with ARC_ will be picked up by the dev and deploy commands. This means that if a component requires the secret secret_key, setting ARC_secret_key in the terminal from which the dev or deploy command is run will fulfill the value for that secret. For example:

export ARC_secret_key=my-super-secret-key
architect deploy my-component -e my-environment -a my-account

Settings secrets this way can be useful in cases where secrets should be set, but never directly included in a secrets file or as part of a command.

​

From the UI

Storing environment configuration in a file is handy for local development, but not ideal for production-grade credentials. In order to provide comparable, secure support for production secrets and values, Architect Cloud allows secrets to be registered with each environment. Simply navigate to the “Secrets” tab on your environment to fill out the corresponding values:

Once filled out, each deployment to the corresponding environment will be automatically enriched with matching values.

​

Order of precedence

Since there are three different methods by which you can provide secrets, you may be wondering what happens if you use more than one. Architect interprets provided secret values in the following order:

1. --secret flag (highest priority)
2. --secret-file flag
3. Environment secrets (lowest priority)