> ## Documentation Index
> Fetch the complete documentation index at: https://www.1password.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Secure your developer secrets
> Use 1Password to securely access secrets where you need them, without exposing anything in plaintext.
export const ImageButton = ({src, darkSrc, url, text, height, alt}) =>
;
export const Image = ({src, darkSrc, alt, width, border, height, round}) => {
const classNames = ["mint-mx-4"];
if (border) {
classNames.push("mint-rounded-sm");
}
if (round) {
classNames.push("mint-rounded-lg");
}
const style = {};
if (width) style.width = typeof width === "number" ? `${width}px` : width;
if (height) style.height = typeof height === "number" ? `${height}px` : height;
return darkSrc ? <>
0 ? style : undefined} />
0 ? style : undefined} onError={e => {
e.target.src = src;
}} />
: 0 ? style : undefined} />;
};
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](/environments#requirements) for a set of project secrets, then [create a local `.env` file](/environments/local-env-file#mount-your-env-file) to access them directly from 1Password where you need them.
**Not sure where to start?** Use the [configuration tables](#choose-your-configuration) to find the best tool and authentication method for your specific use case.
## Environments (beta)
[1Password Environments](/environments) (beta) 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](/environments/read-environment-variables#cli) to applications or scripts at runtime, or create a [locally mounted `.env` file](/environments/local-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](/environments/local-env-file) that your IDE can read without storing the plaintext contents on your device. Use [1Password hooks](/environments/cursor-hook-validate) to validate your setup before the agent executes shell commands.
* **Containerized apps**: Use 1Password SDKs to [retrieve Environment variables](/environments/read-environment-variables#sdks) directly in your application container's code, or use 1Password CLI to [load variables](/environments/read-environment-variables#cli) into an init container or sidecar at runtime.
* **CI/CD pipelines**: Use 1Password CLI to [load the right set of variables](/environments/read-environment-variables#cli) 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.
Create and manage Environments.
Sync an Environment to a local .env file.
Fetch variables from Environments with 1Password CLI or SDKs.
Centralize secrets management and simplify your AWS Secrets Manager workflow.
You can also replace hardcoded secrets in your code using [secret references](/cli/secret-references).
## Shell plugins
With our open source [shell plugin ecosystem](/cli/shell-plugins), 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`](/cli/shell-plugins/aws) and other cloud provider CLIs with 1Password instead of storing access keys in `~/.aws/credentials` or shell profiles.
* **Version control**: Use the [GitHub](/cli/shell-plugins/github) or [GitLab](/cli/shell-plugins/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](/cli/shell-plugins/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](/cli/shell-plugins/environments) 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](#tool-options) and [authentication method](#authentication-options).
### Tool options
* [1Password Environments](#environments-beta): Best for managing project secrets in 1Password and eliminating plaintext secrets in code.
* [1Password CLI](/cli/get-started): Best for quick testing, shell scripts, CI/CD pipelines, Infrastructure as Code, build tools and task runners. Environments require the [latest CLI beta](/environments/read-environment-variables#cli).
* [1Password SDKs](/sdks): Best for native integrations with Go, Python, or JavaScript applications. Environments require the [latest SDK beta](/environments/read-environment-variables#sdks).
* [1Password Shell Plugins](#shell-plugins): Best for securing command-line tools and adding convenient biometric authentication to any CLI.
* [1Password Connect server](/connect): Securely access secrets in your company’s apps and cloud infrastructure using a private REST API.
### Authentication options
* [1Password desktop app](https://1password.com/downloads/): 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](/service-accounts/get-started): 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](https://support.1password.com/1password-glossary#personal-vault), [Private](https://support.1password.com/1password-glossary#private-vault), or [Employee](https://support.1password.com/1password-glossary#employee-vault) vault.
* [Connect server token](/connect/get-started): Authenticate with your Connect server host and token.
### Scenarios
#### Local development
| Use case | Recommended tool | Authentication method | Why this approach |
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Local development** on your machine | [Environments](/environments) + [CLI/SDK](/environments/read-environment-variables) or [local `.env` file](/environments/local-env-file) | [Desktop app](https://1password.com/downloads/) | Use 1Password CLI or SDKs to load your project secrets from an Environment directly into your application at runtime, or use a locally mounted `.env` file if your app expects an environment file. Authenticate with the 1Password desktop app for quick setup with no token management required. |
| **AI-assisted coding** | [Environments](/environments) + [Local `.env` file](/environments/local-env-file) | [Desktop app](https://1password.com/downloads/) | Use locally mounted `.env` files to provide secrets to your IDE without storing them on disk, keeping them out of LLM context. Then use [1Password hooks](/environments/cursor-hook-validate) to validate your setup before the agent executes commands. |
| **Build tools and task runners** | [Environments](/environments) + [CLI](/environments/read-environment-variables#cli) | [Desktop app](https://1password.com/downloads/) or [Service account](/service-accounts) | 1Password CLI integrates easily with build tools like `make`, `gradle`, or `npm` scripts. Use the 1Password desktop app for interactive developer builds, or service accounts for shared builds. |
| **Replacing hardcoded secrets** in existing config files or scripts | [Environments](/environments) + [CLI](/environments/read-environment-variables#cli) | [Desktop app](https://1password.com/downloads/) or [Service account](/service-accounts) | Template your config file with environment variables instead of plaintext secrets, then use 1Password CLI to load the secrets from an Environment at runtime. Authenticate with the 1Password desktop app for personal scripts. Use service accounts for CI/CD, shared builds, or automated access. |
| Securing **third-party CLI tools** | [Shell plugins](/cli/shell-plugins) | [Desktop app](https://1password.com/downloads/) | Shell plugins bring the biometric unlock options available in the 1Password desktop app to dozens of command-line tools, so there are no tokens to manage and credentials are never stored in shell profiles or config files. |
| **Using a CLI tool with multiple accounts or environments** | [Shell plugins](/cli/shell-plugins) | [Desktop app](https://1password.com/downloads/) | Shell plugins allow you to seamlessly switch between different credentials for different accounts and development contexts. |
#### Production environments
| Use case | Recommended tool | Authentication method | Why this approach |
| ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **CI/CD pipelines** (GitHub Actions, GitLab CI, etc.) | [Environments + CLI](/environments/read-environment-variables) or [CI/CD integrations](/ci-cd) | [Service account](/service-accounts) | Use Environments to pass project variables into CI/CD pipelines that support shell commands. This allows you to organize and switch between secrets by development context. Use CI/CD integrations to load secrets into your pipeline using secret references. Service accounts provide non-interactive authentication for automated workflows and can be scoped to only the Environments or vaults your pipeline needs. |
| **Application runtime or server-side applications** | [Environments](/environments) + [SDKs](/environments/read-environment-variables#sdks) | [Service account](/service-accounts) | 1Password SDKs offer native language integration with better error handling and type safety. Service accounts enable secure, automated access without user interaction and headless server authentication. |
| **Docker containers and Kubernetes** | [Environments](/environments) + [SDK or CLI](/environments/read-environment-variables) | [Service account](/service-accounts) | Service accounts work well in containerized environments. Choose 1Password SDKs for application containers, or choose 1Password CLI for init containers or sidecars. |
| **Infrastructure as Code** | [Environments](/environments) + [CLI](/environments/read-environment-variables#cli) or [Terraform](/terraform)/[Pulumi](/pulumi) integrations | [Service account](/service-accounts) | 1Password CLI can be easily invoked from IaC tools. Service accounts enable automated infrastructure provisioning. |
#### Secrets management
| Use case | Recommended tool | Authentication method | Why this approach |
| -------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Secrets rotation** | [Environments](/environments) + [CLI/SDK](/environments/read-environment-variables) | [Service account](/service-accounts) | When you update an Environment, the change is automatically reflected in your code at runtime. Use a service account for automated or scheduled rotation workflows. |
| **Accessing secrets in company apps and cloud infrastructure** | [CLI](/connect/cli) or [Connect SDK](/connect) | [Connect server](/connect) | Connect server hosts a private REST API in your own infrastructure, enabling unlimited re-requests after the initial fetch and reducing dependency on the availability of the 1Password API. |
## Get help
To get help, join the discussion in our [Developer community](https://www.1password.community/category/discuss/discussions/developers) or join our [Developer Slack workspace](https://developer.1password.com/joinslack).
[1Password Environments](/environments) (beta) 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](/environments/read-environment-variables#cli) to applications or scripts at runtime, or create a [locally mounted `.env` file](/environments/local-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](/environments/local-env-file) that your IDE can read without storing the plaintext contents on your device. Use [1Password hooks](/environments/cursor-hook-validate) to validate your setup before the agent executes shell commands.
* **Containerized apps**: Use 1Password SDKs to [retrieve Environment variables](/environments/read-environment-variables#sdks) directly in your application container's code, or use 1Password CLI to [load variables](/environments/read-environment-variables#cli) into an init container or sidecar at runtime.
* **CI/CD pipelines**: Use 1Password CLI to [load the right set of variables](/environments/read-environment-variables#cli) 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.