Reviews

1Password for Developers: Managing Secrets, SSH Keys, and API Tokens Securely

19 min read By HyperWebEnable Team
1Password for Developers: Managing Secrets, SSH Keys, and API Tokens Securely

The Password Manager That Became a Developer Platform

Most developers encounter 1Password the same way everyone else does — as a place to store login credentials. You install the browser extension, save a few passwords, maybe set up two-factor authentication, and move on. It works well. It is arguably the best consumer password manager available. But that is not why this review exists.

Over the past three years, 1Password has quietly built something far more ambitious: a complete secrets management platform designed specifically for software development workflows. SSH key management, CI/CD secret injection, API token rotation, environment variable management, server-side secret retrieval via Connect — these are not afterthoughts bolted onto a password manager. They are a coherent platform that addresses one of the most persistent problems in software engineering: how to keep secrets out of code, configuration files, and environment variables without creating workflow friction that developers route around.

This review evaluates 1Password from a developer’s perspective after twelve months of using it across multiple production environments, CI/CD pipelines, and development teams. The focus is on the developer-specific features — the CLI, Connect server, SSH agent, and secrets automation — rather than the consumer password management features that have been reviewed extensively elsewhere.

Why Secrets Management Matters More Than Developers Admit

Before examining what 1Password offers, it is worth understanding the problem it solves. The OWASP Top 10 security vulnerabilities consistently highlight broken authentication and sensitive data exposure as critical risks, and hardcoded secrets are one of the most common vectors for both.

Every non-trivial application depends on secrets: database credentials, API keys for third-party services, SSH keys for server access, signing certificates for deployments, OAuth client secrets, webhook tokens, encryption keys. A typical microservices application might depend on 50 to 200 distinct secrets across its infrastructure.

The traditional approach to managing these secrets is a patchwork of bad practices that accumulate over time:

  • .env files committed to repositories or shared via Slack messages
  • Hardcoded credentials in configuration files with comments like “TODO: move to env var”
  • Shared service accounts with passwords that never rotate because nobody knows what depends on them
  • SSH keys generated without passphrases, copied between machines, and never revoked when team members leave
  • CI/CD secrets stored in platform-specific secret stores with no audit trail and no rotation policy

These practices persist not because developers are careless, but because proper secrets management has traditionally required dedicated infrastructure — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — that demands its own operational expertise. For teams without a dedicated platform engineering function, the overhead of running a secrets management system often exceeds the perceived risk of the patchwork approach. Understanding the principles behind authentication and authorization helps, but without practical tooling, theory rarely translates into practice.

1Password’s developer platform occupies the middle ground: more capable than .env files and platform-specific secret stores, less complex than running a dedicated secrets management infrastructure. For teams of 5 to 100 developers, this is precisely the right trade-off.

The 1Password CLI: Secrets Without Exposure

The 1Password CLI (op) is the foundation of every developer workflow. It provides programmatic access to your vaults, enabling secret retrieval, injection, and management from the command line without ever exposing secret values in plaintext files or environment variables.

Installation is straightforward on every major platform. On macOS with Homebrew, it is a single command. On Linux, 1Password provides official packages for Debian, Ubuntu, Fedora, and CentOS. The CLI authenticates via biometric unlock on supported platforms, which means you get the security of vault-stored secrets with the convenience of a local credential cache.

The most powerful CLI feature is op run — a command that injects secrets into a process’s environment at runtime without writing them to disk. Instead of maintaining .env files with plaintext credentials, you create a reference file that points to secrets in your 1Password vault:

# .env.template — secret references, safe to commit to version control
DATABASE_URL=op://Development/PostgreSQL Production/connection-string
STRIPE_SECRET_KEY=op://Development/Stripe API/secret-key
REDIS_URL=op://Development/Redis Cluster/url
JWT_SIGNING_KEY=op://Development/JWT Config/signing-key
AWS_ACCESS_KEY_ID=op://Development/AWS IAM Deploy/access-key-id
AWS_SECRET_ACCESS_KEY=op://Development/AWS IAM Deploy/secret-access-key
SENDGRID_API_KEY=op://Development/SendGrid/api-key

# CI/CD secret injection — GitHub Actions example
# In your workflow YAML, replace hardcoded secrets with op references
# ---------------------------------------------------------------
# jobs:
#   deploy:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: 1password/load-secrets-action@v2
#         with:
#           export-env: true
#         env:
#           OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
#           DATABASE_URL: op://Infrastructure/DB-Prod/connection-string
#           DEPLOY_KEY: op://Infrastructure/Deploy-SSH/private-key
#
# Locally, run any command with secrets injected:
# op run --env-file=.env.template -- npm start
# op run --env-file=.env.template -- docker compose up
# op run --env-file=.env.template -- python manage.py runserver

# The actual secret values never touch disk, never appear in
# shell history, and never persist in environment after the
# process exits. The references in this file are safe to commit
# because they contain zero sensitive data — only vault paths.

This approach solves multiple problems simultaneously. The .env.template file is safe to commit to version control because it contains only vault references, not actual secrets. New team members clone the repository and run op run — if they have vault access, the secrets resolve automatically. If they do not have access, they get a clear error message indicating which vault and item they need permission for. There is no more “ask Sarah for the .env file” onboarding process.

For teams using GitHub Actions for CI/CD, 1Password provides official actions that inject secrets from a service account into your workflow environment. This eliminates the need to duplicate secrets across GitHub’s repository secrets, organization secrets, and environment secrets — a common source of configuration drift where production breaks because someone updated the secret in 1Password but forgot to update the copy in GitHub.

SSH Agent: Keys Without Key Files

1Password’s SSH agent is the feature that most fundamentally changes a developer’s daily workflow. Instead of managing SSH keys as files in ~/.ssh/, you store them in your 1Password vault and let 1Password’s built-in SSH agent serve them to any SSH client on demand.

The practical benefits are significant:

  • No key files on disk: SSH private keys never exist as files on your filesystem. They live encrypted in your 1Password vault and are served to the SSH agent only when needed, requiring biometric authentication for each use
  • Key portability: When you set up a new machine, your SSH keys are available immediately after signing into 1Password. No more copying key files between machines, no more “permission denied (publickey)” errors on a fresh laptop
  • Per-key approval: Each SSH connection triggers a biometric prompt showing which key is being used and which host is requesting it. You see exactly when and where your keys are being used
  • Git commit signing: 1Password can serve SSH keys for Git commit signing, providing cryptographic verification of commit authorship without managing separate GPG keys
  • Automatic key rotation: Generate new SSH keys directly in 1Password, add the public key to your servers and Git hosting, and revoke old keys — all without touching the filesystem

Setting up the SSH agent requires adding a few lines to your SSH config to delegate agent operations to 1Password. After that, every SSH operation — git push, ssh connections, scp transfers, rsync — uses keys from your vault with biometric approval. This integrates naturally with Docker development workflows where SSH keys are often needed for pulling private dependencies during container builds.

1Password Connect: Server-Side Secrets for Infrastructure

While the CLI and SSH agent solve developer workstation problems, 1Password Connect addresses the server-side challenge: how do your applications retrieve secrets at runtime without baking them into container images, Kubernetes manifests, or Terraform configuration?

Connect is a self-hosted REST API server that provides access to your 1Password vaults from your infrastructure. You deploy the Connect server within your network — as a Docker container, a Kubernetes pod, or a standalone service — and your applications query it for secrets over HTTPS. The Connect server authenticates to 1Password’s cloud service, caches secrets locally for performance, and serves them to authorized clients.

# 1Password Connect Server — Secret Rotation with API
# Deploy Connect server, then use the REST API for dynamic secret retrieval
# -------------------------------------------------------------------

# docker-compose.yml for Connect server deployment
# services:
#   op-connect-api:
#     image: 1password/connect-api:latest
#     ports: ["8080:8080"]
#     volumes:
#       - "./1password-credentials.json:/home/opuser/.op/1password-credentials.json"
#   op-connect-sync:
#     image: 1password/connect-sync:latest
#     volumes:
#       - "./1password-credentials.json:/home/opuser/.op/1password-credentials.json"
#       - "op-data:/home/opuser/.op/data"

# Python example: retrieve and rotate secrets via Connect API
import requests
import secrets
import string
from datetime import datetime

CONNECT_HOST = "https://op-connect.internal:8080"
CONNECT_TOKEN = "your-connect-bearer-token"  # stored securely, not hardcoded
VAULT_ID = "vault-uuid-here"

headers = {
    "Authorization": f"Bearer {CONNECT_TOKEN}",
    "Content-Type": "application/json"
}

def get_secret(item_id: str, field: str = "password") -> str:
    """Retrieve a secret value from 1Password Connect."""
    resp = requests.get(
        f"{CONNECT_HOST}/v1/vaults/{VAULT_ID}/items/{item_id}",
        headers=headers
    )
    resp.raise_for_status()
    item = resp.json()
    for f in item["fields"]:
        if f["label"] == field:
            return f["value"]
    raise KeyError(f"Field '{field}' not found in item")

def rotate_api_key(item_id: str) -> str:
    """Generate a new API key, update it in 1Password, return new value."""
    new_key = ''.join(
        secrets.choice(string.ascii_letters + string.digits)
        for _ in range(48)
    )

    # Get current item
    resp = requests.get(
        f"{CONNECT_HOST}/v1/vaults/{VAULT_ID}/items/{item_id}",
        headers=headers
    )
    resp.raise_for_status()
    item = resp.json()

    # Update the credential field
    for field in item["fields"]:
        if field["label"] == "credential":
            field["value"] = new_key

    # Add rotation metadata
    for field in item["fields"]:
        if field["label"] == "last-rotated":
            field["value"] = datetime.utcnow().isoformat()
            break

    # Push update to 1Password
    resp = requests.put(
        f"{CONNECT_HOST}/v1/vaults/{VAULT_ID}/items/{item_id}",
        headers=headers,
        json=item
    )
    resp.raise_for_status()
    return new_key

# Usage in application startup or scheduled rotation
db_password = get_secret("database-prod-item-id", "password")
api_key = get_secret("external-api-item-id", "credential")

# Scheduled rotation (run via cron or task scheduler)
# new_key = rotate_api_key("internal-service-key-id")
# Then update the dependent service with the new key

The Connect architecture provides several advantages over cloud-native secret stores. First, it centralizes secrets in a single 1Password vault that developers already use for their personal credentials, eliminating the split between “developer secrets” and “infrastructure secrets” that plagues most organizations. Second, it provides a consistent API regardless of where your infrastructure runs — AWS, GCP, Azure, on-premises, or a hybrid of all four. Third, it maintains 1Password’s access control model, so you manage who can access which secrets through the same familiar vault sharing interface.

For teams adopting a DevOps culture, Connect bridges the gap between development and operations by giving both teams a shared, audited, access-controlled secret store that does not require dedicated infrastructure expertise to maintain.

Service Accounts: Machine Identity Without Shared Credentials

Service accounts are 1Password’s answer to the “how does CI/CD authenticate?” question. A service account is a non-human identity with scoped access to specific vaults, designed for automated workflows that cannot perform biometric authentication.

Each service account gets a token that grants read access to designated vaults. The token itself is the only secret you need to store in your CI/CD platform’s native secret store — everything else comes from 1Password at runtime. This dramatically reduces the attack surface of your CI/CD secrets. Instead of 15 individual secrets stored in GitHub Actions (database URL, API keys, deployment credentials, signing keys), you store one service account token. If that token is compromised, you revoke it in 1Password and issue a new one. All 15 secrets remain secure because they were never exposed.

Service accounts support fine-grained access control. A deployment service account might have read access to the “Production Infrastructure” vault but no access to the “Development API Keys” vault. A testing service account might access only the “Test Environment” vault. This granularity means a compromised CI/CD pipeline cannot access secrets beyond its designated scope — a significant improvement over the common pattern of giving CI/CD systems access to all secrets across all environments.

Secrets Automation in Practice: The Full Workflow

The individual features — CLI, SSH agent, Connect, service accounts — are useful independently, but their real power emerges when combined into a cohesive workflow. Here is how a mature 1Password developer setup works across the full development lifecycle:

Local development: Developers run op run --env-file=.env.template to start their application with secrets injected from their personal vault. No .env files exist on disk. SSH keys for Git operations are served by the 1Password SSH agent with biometric approval. Git commits are signed using SSH keys from the vault.

Code review and CI: When a pull request is opened, GitHub Actions workflows use a service account token to retrieve test environment secrets from 1Password. Tests run against real configuration without exposing secrets in workflow logs. The .env.template file in the repository serves as living documentation of which secrets the application requires.

Staging deployment: The deployment pipeline uses a separate service account with access to the staging vault. Secrets are injected into the deployment environment at runtime — never baked into container images or stored in Kubernetes secrets as base64-encoded plaintext (which is not encryption, despite what many teams assume).

Production deployment: A production-specific service account with the most restricted access scope retrieves production secrets. Connect server instances running within the production network provide runtime secret access to application pods. Secret rotation happens through the Connect API without redeploying applications.

Offboarding: When a developer leaves the team, removing their 1Password access revokes all their credentials simultaneously — SSH keys, API tokens, database passwords, service credentials. There are no orphaned key files on old laptops, no shared passwords that need changing across a dozen services.

What 1Password Gets Right

Several aspects of the developer platform deserve specific praise:

  • Zero-knowledge architecture: 1Password cannot access your secrets. The encryption model means that even a complete compromise of 1Password’s servers does not expose your vault contents. For security-conscious teams, this matters more than any feature
  • Biometric integration: Touch ID and Windows Hello integration for CLI operations eliminates the friction of entering master passwords. When unlocking a secret is as fast as touching a sensor, developers actually use the secure workflow instead of routing around it
  • Cross-platform consistency: The CLI, SSH agent, and desktop application work identically on macOS, Windows, and Linux. Teams with mixed operating systems do not need platform-specific secret management workflows
  • Audit logging: Every secret access, modification, and sharing event is logged with timestamps and user identity. For compliance requirements (SOC 2, ISO 27001, HIPAA), this audit trail is often the difference between passing and failing an assessment
  • Developer experience: The CLI is well-designed, documentation is comprehensive, and error messages are genuinely helpful. When a secret reference fails to resolve, the error tells you exactly which vault, item, and field it could not find — not a cryptic status code

What 1Password Gets Wrong

Honest evaluation requires acknowledging limitations:

  • Pricing complexity: The developer features require a 1Password Business plan ($7.99/user/month) or Teams plan. Individual plans do not include service accounts, Connect server access, or advanced audit logging. For small teams, this cost adds up alongside other SaaS subscriptions
  • Connect server operational overhead: While simpler than running HashiCorp Vault, the Connect server still requires deployment, monitoring, and maintenance. It is another service to keep running, another container to update, another potential point of failure in your infrastructure
  • Limited secret rotation automation: While the Connect API enables programmatic rotation, 1Password does not provide built-in automatic rotation the way AWS Secrets Manager does for RDS credentials. You build the rotation logic yourself, which means writing and maintaining rotation scripts
  • Vendor lock-in risk: Moving from 1Password’s secret references (op:// URIs) to another solution requires updating every .env.template, every CI/CD workflow, and every Connect API integration. The deeper you integrate, the harder it becomes to switch
  • CLI version management: The CLI and desktop app versions must be compatible, and updates occasionally break the biometric bridge between them. When this happens, you fall back to manual password entry until both components are updated — a minor but frustrating issue during critical work

1Password vs. Alternatives

Understanding where 1Password fits relative to other options helps teams make the right choice:

HashiCorp Vault: The industry standard for secrets management at scale. Vault offers capabilities 1Password cannot match — dynamic secrets, fine-grained policy engines, secrets engines for databases and cloud providers. But Vault requires dedicated operational expertise. If you have a platform engineering team, Vault is likely the better choice. If you do not, 1Password provides 80% of the value at 20% of the operational cost.

AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: Cloud-native solutions that integrate deeply with their respective platforms. If your infrastructure is entirely within a single cloud provider, these services offer tighter integration with managed services. 1Password’s advantage is cloud-agnosticism and the unified developer-and-infrastructure experience.

Doppler: A developer-focused secrets management platform that shares 1Password’s philosophy of making secrets easy to manage. Doppler excels at environment-specific secret management and has excellent CI/CD integrations. However, it lacks 1Password’s consumer password management, SSH agent, and the benefit of consolidating personal and professional credentials in one tool.

.env files and dotenv: Still the default for many projects and still a security risk. If your team currently manages secrets through .env files shared via Slack or committed to private repositories, 1Password represents a massive security improvement with minimal workflow disruption. The op run command is a direct drop-in replacement.

For agencies and development teams managing multiple client projects, tools like Toimi for project planning and Taskee for task management complement 1Password well — Toimi and Taskee handle the project coordination while 1Password ensures that credentials for each client environment remain properly isolated and audited.

Pricing Breakdown

The developer features require specific plan tiers:

  • Individual ($2.99/month): Password management, SSH key storage, basic CLI access. No service accounts, no Connect, no advanced audit logging. Sufficient for solo developers managing personal credentials
  • Teams ($3.99/user/month): Shared vaults, basic admin controls, guest accounts. Adds team-level secret sharing but still lacks service accounts and Connect server access
  • Business ($7.99/user/month): Full developer platform — service accounts, Connect server, advanced audit logging, custom groups, Duo integration, SCIM provisioning. This is the minimum tier for serious developer workflow integration
  • Enterprise (custom pricing): Everything in Business plus custom onboarding, dedicated support, and advanced compliance features. Necessary for organizations with more than 100 users or specific compliance requirements

The Business plan at $7.99/user/month is competitive. For a team of 10, that is $79.90/month — significantly less than running and maintaining a HashiCorp Vault cluster, and less than many cloud-native secret management solutions when you account for API call pricing. The value proposition strengthens when you consider that developers were likely going to use a password manager anyway — 1Password simply extends that tool to cover professional secrets management.

Implementation Recommendations

For teams considering 1Password’s developer features, here is a practical adoption path:

Week 1-2: Install the CLI and SSH agent for all developers. Migrate SSH keys from filesystem to 1Password vault. Configure Git commit signing with SSH keys. This provides immediate security improvement with minimal disruption.

Week 3-4: Create .env.template files for each project with op:// references. Train the team on op run for local development. Delete existing .env files from developer machines (after confirming all secrets are in the vault). Audit repositories for accidentally committed secrets using tools like TruffleHog or Gitleaks.

Month 2: Create service accounts for CI/CD pipelines. Migrate secrets from GitHub Actions secrets, GitLab CI variables, or other platform-specific stores to 1Password. Update workflow files to use 1Password’s official actions or CLI for secret injection.

Month 3: Deploy Connect server in staging and production environments. Migrate application runtime secrets from environment variables to Connect API calls. Implement secret rotation scripts for critical credentials.

This phased approach minimizes risk — each stage provides standalone value, and you can pause the adoption at any point without losing the benefits of completed stages.

The Verdict

1Password has successfully transformed from a consumer password manager into a legitimate developer secrets platform. The CLI, SSH agent, Connect server, and service accounts form a coherent system that addresses real security problems without imposing the operational complexity of enterprise secrets management tools.

The sweet spot is teams of 5 to 100 developers who need better secrets management than .env files and platform-specific secret stores but cannot justify the overhead of running HashiCorp Vault or building custom secrets infrastructure. For these teams, 1Password provides a genuinely practical path from insecure secret handling to audited, access-controlled, rotatable secrets management — and it does so by extending a tool developers already know and use daily.

The limitations — pricing that requires the Business tier for full features, Connect server operational overhead, and limited built-in rotation automation — are real but proportional. No tool eliminates all trade-offs, and 1Password’s trade-offs are reasonable for its target audience.

Rating: 4.6/5 — An excellent developer secrets platform that makes secure credential management practical for teams that previously could not justify the infrastructure investment. The integration of personal password management with professional secrets automation in a single tool is 1Password’s unique and genuine advantage.

Frequently Asked Questions

Is 1Password secure enough for production secrets?

Yes. 1Password uses a zero-knowledge architecture where your data is encrypted with keys derived from your master password and Secret Key. Even 1Password’s own servers cannot decrypt your vault contents. The platform has completed multiple independent security audits by firms including Cure53, SOC 2 Type II compliance, and has a public bug bounty program. For most teams, 1Password’s security model exceeds what they achieve with self-managed alternatives like manually distributed .env files or unencrypted Kubernetes secrets.

Can 1Password replace HashiCorp Vault?

For small to mid-size teams, yes — for most use cases. 1Password covers static secrets storage, access control, audit logging, and programmatic secret retrieval through the CLI and Connect API. However, Vault offers capabilities 1Password does not: dynamic secrets generation, database credential leasing, advanced policy engines with Sentinel, and secrets engines for dozens of platforms. If your infrastructure requires dynamic secrets or complex policy-based access, Vault remains the better choice. If you need reliable secrets storage with good developer experience, 1Password is simpler and cheaper to operate.

How does the 1Password SSH agent work with Git?

The 1Password SSH agent acts as a drop-in replacement for the system SSH agent (ssh-agent). You configure your SSH client to use 1Password’s agent socket, store your SSH keys in your 1Password vault, and every SSH operation — including git push, git pull, and git clone over SSH — uses keys served from the vault. Each key use triggers a biometric prompt (Touch ID or Windows Hello), so you always know when your keys are being accessed. You can also configure Git to use these SSH keys for commit signing, replacing GPG-based signing with a simpler workflow that does not require managing separate GPG keyrings.

What happens to secrets if 1Password goes down?

The Connect server maintains a local encrypted cache of secrets, so your applications continue to operate even if 1Password’s cloud service is temporarily unavailable. The CLI also caches session tokens locally. However, new secret retrievals and updates require connectivity to 1Password’s servers. For critical production environments, the Connect server’s local cache provides resilience, but you should design your applications to handle transient secret retrieval failures gracefully. 1Password’s historical uptime exceeds 99.9%, and their status page provides real-time service monitoring.

Can I use 1Password developer features with a personal plan?

Partially. The Individual plan ($2.99/month) includes the CLI for personal secret retrieval and SSH key storage in your vault. You can use op run for local development and the SSH agent for key management. However, service accounts, Connect server access, advanced audit logging, and team vault sharing require the Business plan ($7.99/user/month). If you are a solo developer, the Individual plan covers local workflow needs. If you work on a team and need CI/CD integration or server-side secret retrieval, the Business plan is necessary.