Skip to main content
Hardcoded plaintext secrets in source code, config files, environment files, and shell profiles are one of the most common causes of credential leaks. 1Password developer tools make it easy to access your secrets where you need them without exposing them in plaintext. Store your credentials in 1Password, then securely load them in your terminal, IDE, app, CI/CD pipelines, or anywhere else in your code.
Want to get started quickly? Create an Environment for a set of project secrets, then create a local .env file to access them directly from 1Password where you need them. Or use the configuration tables to find the best tool and authentication method for your specific use case.

Environments

An authorization prompt is shown when you try to access a mounted `.env` file through your local terminal.
1Password Environments function like a vault for your developer secrets. You can organize your secrets in 1Password as collections of environment variables for each project or development context, then securely access them when you need them without exposing anything in plaintext. Switching between different sets of secrets for different contexts is as simple as pointing to a different Environment ID. You can use Environments to load sets of secrets into any context where you typically load secrets from the environment. For example:
  • Local development: Use 1Password CLI to pass the variables stored in an Environment to applications or scripts at runtime, or create a locally mounted .env file for tools that expect an environment file on disk.
  • AI-assisted coding: Keep plaintext secrets out of an LLM’s context using a locally mounted .env file that your IDE can read without storing the plaintext contents on your device. Use 1Password hooks to validate your setup before the agent executes shell commands.
  • Containerized apps: Use 1Password SDKs to retrieve Environment variables directly in your application container’s code, or use 1Password CLI to load variables into an init container or sidecar at runtime.
  • CI/CD pipelines: Use 1Password CLI to load the right set of variables into your pipeline for the current development stage by pointing to the Environment your pipeline needs. Authenticate with a service account for automated, least privilege access.
Environments are a great choice for securing your developer secrets when you have environment files that currently use plaintext secrets. You can import your existing .env files directly into 1Password, and you can share your Environments with your team members for quick and secure collaboration.

Get started

Create and manage Environments.

Access secrets through local .env files

Sync an Environment to a local .env file.

Programmatically read Environments

Fetch variables from Environments with 1Password CLI or SDKs.

Sync secrets to AWS Secrets Manager

Centralize secrets management and simplify your AWS Secrets Manager workflow.

Find .env files with plaintext secrets

Use Developer Watchtower to scan your local disk for .env files with plaintext secrets, then import them into Environments.
You can also replace hardcoded secrets in your code using secret references.

Shell plugins

With our open source shell plugin ecosystem, you can use 1Password to bring secure biometric authentication to all your command-line tools. When you configure a shell plugin for a CLI, you authenticate the CLI in the same way you unlock the 1Password desktop app, like with Touch ID, Apple Watch, or Linux system authentication. Shell plugins make authenticating all the CLI tools you use secure and easy, without ever needing to enter your credentials manually in your terminal. For example:
  • Cloud provider CLIs: Authenticate aws and other cloud provider CLIs with 1Password instead of storing access keys in ~/.aws/credentials or shell profiles.
  • Version control: Use the GitHub or GitLab shell plugins to authenticate gh or glab without storing plaintext tokens in your environment.
  • Local development tools: Authenticate package managers and development CLIs like Homebrew without storing credentials in config files.
Shell plugins allow you to configure different credentials in different project directories, so you can seamlessly switch between different contexts without needing to take the time to sign out and in again. Get started with one of our most popular shell plugins:

Choose your configuration

Use the tables below to find the best tools and authentication method for your specific use case. Every scenario includes a recommended tool and authentication method.

Tool options

  • 1Password Environments: Best for managing project secrets in 1Password and eliminating plaintext secrets in code.
  • 1Password CLI: Best for quick testing, shell scripts, CI/CD pipelines, Infrastructure as Code, build tools and task runners. Environments require the latest CLI beta.
  • 1Password SDKs: Best for native integrations with Go, Python, or JavaScript applications. Environments require the latest SDK beta.
  • 1Password Shell Plugins: Best for securing command-line tools and adding convenient biometric authentication to any CLI.
  • 1Password Connect server: Securely access secrets in your company’s apps and cloud infrastructure using a private REST API.

Authentication options

  • 1Password desktop app: Authenticate locally in the same way you unlock your 1Password desktop app, like with biometrics or your 1Password account password. Requires minimal setup with no token management and enables human-in-the-loop approval for sensitive workflows.
  • 1Password Service Accounts: Authenticate using a token scoped to specific vaults or Environments, with no user interaction required. Best for headless servers, automated workflows, and shared building. Service accounts can’t access your built-in Personal, Private, or Employee vault.
  • Connect server token: Authenticate with your Connect server host and token.

Scenarios

Local development

Production environments

Secrets management

Next steps

Choose what you want to do next:

Secure your deployments

Securely load secrets into CI/CD, containers, and production apps at runtime with least-privilege access.

Secure AI access

Provide credentials to AI agents and tools without exposing them in prompts, LLM context, or config files.

Get help

To get help, join the discussion in our Developer community or join our Developer Slack workspace.