Skip to main content
With 1Password CLI, you can use secret references to automatically load secrets into configuration files from your 1Password account without putting any plaintext secrets in code. This allows you to check config files into source control and keep them in sync throughout developer workstations, CI, and production servers, which is otherwise manual and error-prone work.
We recommend using 1Password Service Accounts to follow the principle of least privilege. Service accounts support restricting 1Password CLI to specific vaults, so that processes in your authorized terminal session can only access items required for a given purpose.

​
Requirements

Before you can use 1Password to secure your config files, you’ll need to:
  1. Sign up for 1Password.
  2. Install 1Password CLI.
  3. Store the secrets you want to provision in your 1Password account.

​
Step 1: Get secret references

You can get secret references in several ways:

​
Step 2: Use secret references in your config file

Replace the plaintext secrets in your config file with the appropriate secret references, following the template syntax. For example, if you start with a config file that looks like this:
config.yml
database:
    host: http://localhost
    port: 5432
    username: mysql-user
    password: piG1rX5P1QMF6J5k7u7sNb
And you saved the username and password secrets on the mysql item in the prod vault, you would end up with this templated config file:
config.yml.tpl
database:
    host: http://localhost
    port: 5432
    username: op://prod/mysql/username
    password: op://prod/mysql/password

​
Step 2: Inject the secrets

To load secrets from the config file and provision them at runtime, use op inject to inject the secrets directly into your production environment. For example: 
op inject -i config.yml.tpl -o config.yml
In the output file, config.yml, you’ll see the secret references replaced with the plaintext secrets they reference. The config file template is stored together with the code in source control, so that every developer can see the structure of the file.
Make sure to delete the resolved config file when you no longer need it.

​
Step 3: Differentiate between environments

We highly recommend you organize your 1Password items in the same way across all of your environments. For example: app/dev/db/password and app/prod/db/password. If you do this, you can use variables in your template file to switch to a different set of secrets. You can have variables for your environment, stage, region, or anything else. For example:
config.yml.tpl
database:
    host: http://localhost
    port: 5432
    username: op://$APP_ENV/mysql/username
    password: op://$APP_ENV/mysql/password
You can then set the APP_ENV variable when you inject into the template, using the Template Syntax: 
APP_ENV=prod op inject -i config.yml.tpl -o config.yml
This allows you to use the same template file, stored in source control next to your application, for all your deployments.

​
Optional: Use op inject in production

Now that the application works with the right configuration locally, you can use 1Password CLI to provision secrets in production environments. To do this, you’ll first need to:
  1. Install 1Password CLI 2 in your production environment.
  2. Set up a Secrets Automation workflow.
  3. Deploy 1Password Connect Server and make it accessible to your production environment.
To use 1Password CLI with a Connect server, set the OP_CONNECT_HOST and OP_CONNECT_TOKEN environment variables to your Connect instance’s credentials in your production environment. You can now move your secrets to config files and have them readily accessible with op inject. The following commands can be used with a Connect server:
  • op run
  • op inject
  • op read
  • op item get

​
Learn more