SikkerKey vs Doppler
Summary
SikkerKey and Doppler both cover the core requirements of a SaaS secrets manager, including encrypted storage, versioning, rotation, access controls, and audit logging. This comparison looks at where the two platforms overlap, where their approaches differ, and which features are native to each.
The full feature rundown covers machine authentication, secret types, access policies, temporary infrastructure, audit, team management, AI workflows, and more. It also highlights areas where the platforms take fundamentally different approaches, rather than treating every feature as a simple checkbox.
Looking for a Doppler alternative? The table below compares all 19 areas side by side.
SikkerKey and Doppler cover the same core secrets-management basics, but SikkerKey goes further in machine identity and secret types: signed requests instead of reusable bearer credentials, structured secrets with per-field rotation, leased database credentials, canary secrets, and read-blind AI identities.
| Feature | SikkerKey | Doppler | Why it matters |
|---|---|---|---|
| 01Secret Retrieval Authentication | |||
| Secret Retrieval | Asymmetric signing. Your machine signs a request with its private key, and SikkerKey verifies it with the public key. The keys are generated with Ed25519, and SikkerKey never sees your private key. | Doppler retrieves secrets over its API. A workload authenticates with a Service Token (dp.st.*) in the Authorization header, or on GitHub Actions, GitLab, AWS EC2, Kubernetes, and CircleCI it exchanges an OIDC token for a short-lived Doppler token.The workload authenticates by presenting a bearer credential. A Service Token works from wherever it is copied and stays valid until it is rotated, and the OIDC path needs a trusted external issuer and a Team plan. | As a baseline, access to your secrets is gated by your cryptographic identity. |
| Machines | A machine is any device or environment you want to be able to access secrets. Generate a bootstrap command from the dashboard and run it on your machine. It generates a keypair locally and registers the public key with SikkerKey. The machine appears as pending-approval. | A workload authenticates with a Service Token or Service Account token you issue and place on the host. Service Accounts are named principals that can span multiple projects at the workplace level.The token is a bearer credential, not a per-machine identity. Copy it to another host and Doppler cannot tell them apart. There is no locally generated keypair and no approval step before it can read. | Bootstrap a machine in seconds, and it reaches your secrets only after you approve it. |
| Enrollment Tokens | An identity token with its own lifecycle you set, letting you mint up to 10,000 ephemeral machines and scope how long each machine's identity stays valid. Optionally harden the minting requirements with hostname regex matching and/or IP or CIDR allowlists. | No enrollment-token primitive. CI runners authenticate through per-service-account OIDC identities, or share and duplicate Service Tokens.Nothing mints many bounded machine identities from one token with hostname regex matching, CIDR matching, and an automatic expiry. | Short-lived machines get short-lived identities that expire with them. This prevents identity sprawl and stops forgotten privileged identities from lingering indefinitely. |
| Temporary Machines | A machine you provision for a fixed lifetime, from 1 hour up to 12 months, that expires on its own at the deadline. Attach optional guardrails enforced at every read: a time-of-day window, an IP/CIDR allowlist, and a country allowlist. Extend it later within a rolling 12-month cap. | Service Tokens can be short-lived with --max-age, and OIDC identities cover ephemeral CI runners.Per-machine guardrails for a time-of-day window and an allowed-country list are not expressible. | Give a contractor or a short-lived environment access that expires on its own when the work is done. The guardrails narrow it to the hours, networks, and countries you allow. |
| 02Agentic Secret Ops | |||
| AI Identity | A separate identity class for AI agents that can manage your vault but is structurally read-blind. It can create and rotate secrets and manage machines, projects, policies, and canaries, but it can never read a secret's plaintext, because the read path only authenticates machines. Capabilities are scoped and granted from the dashboard, and each agent is capped at its creator's current privileges. | An AI agent authenticates with an ordinary Doppler token through the MCP server and reads whatever that token is scoped to.There is no identity class that can manage the vault while being structurally unable to read a secret's plaintext. A token that can read secrets lets the agent read them. | Hand an AI agent real management power over your vault, automating secret ops, provisioning, and policy, without ever giving it the ability to read a secret. The read-blind boundary is structural, so no scope or misconfiguration opens a path to your plaintext. |
| MCP Server | A local MCP server for Claude Code, Codex, Cursor, Continue, and other MCP-compatible clients. It runs next to the AI client over stdio and signs every request with an Ed25519 AI-agent identity. It exposes management tools across projects, secrets, rotation, policies, machines, and audit, with permissions assigned from the dashboard and bounded by the creator's access. Stored secret values stay on the application read path, so the client manages the vault without reading secrets. | Doppler ships an official MCP server for AI clients. It authenticates with a CLI token or any Doppler token and offers a read-only mode that hides write tools.It acts with the token's scope, so a token that can read secret values gives the agent that access. | Teams can let AI clients perform real secret-ops work with signed requests, clear permissions, and audit attribution. The local binary fits existing MCP workflows while SikkerKey keeps management automation separate from application secret reads. |
| 03Developer Tooling | |||
| SDKs | Read-only runtime SDKs for Python, Node.js, Go, .NET, Kotlin, and PHP. Each uses the machine's Ed25519 identity and can read single values, structured fields, list, and export. SDKs can bootstrap memory-only identities from enrollment tokens for serverless and ephemeral hosts, and every SDK except PHP can watch a secret and fire a callback when its value changes, access is revoked, or it is deleted. | Official SDKs for Node.js and Python. Other languages read secrets through the CLI or the download API.C#, Go, Java, PHP, and Ruby are listed as planned. There is no change-watch callback for rotation or revocation. | Applications can fetch secrets with the same security model in every runtime, without API keys or long-lived bearer tokens. Watch support lets services react to rotation and revocation quickly, while memory-only bootstrap covers platforms where writing an identity file is impractical. |
| CLI | A single-binary CLI for Linux, macOS, and Windows. It uses the same Ed25519 machine identity as the SDKs to read, list, and export secrets, and can run a child process with secrets injected into its environment. It also manages multiple vaults and installs managed-secret agents. | The doppler run command injects secrets as environment variables into a child process, with an encrypted fallback file for offline use. It authenticates with a Service Token on the host. | Developers and operators can use SikkerKey in terminals, scripts, deploy jobs, and local tooling with the same grants applications use in production. Environment injection makes legacy applications work without code changes, while multi-vault support keeps production, staging, and personal workflows separate. |
| 04Secret Model | |||
| Structured Secrets | A secret that holds multiple named values. The SDK and CLI fetches any value by its field name. You can rotate any value manually on its own, or schedule specific values to rotate while the rest stay static. | A secret value can be a JSON or JSON5 string, or multi-line text like a PEM key.The value is stored and rotated as one opaque string. There are no native named fields, no per-field rotation, and no fetch-by-field-name. | A real credential often has several parts that change at different times, so you rotate the volatile ones on their own schedule. |
| Managed Secret | A Sync Agent you run applies rotations to the external system that holds the secret. SikkerKey stages the new value, the agent writes it and verifies a live connection, and SikkerKey promotes it only after the agent confirms. A failed apply rolls back and logs the error. | Rotated Secrets rotate AWS and GCP MySQL and Postgres, AWS IAM, GCP SQL Server and Service Accounts, SendGrid, Twilio, Cloudflare Pages, and MongoDB Atlas with a two-secret strategy. AWS rotations run through a Lambda in your AWS account.Rotation runs through Doppler and provider APIs against supported managed services. It is not an agent on your own infrastructure that verifies a live connection before the new value is promoted. Available on Team and Enterprise. | Rotation runs on your own infrastructure and is verified against the live system before SikkerKey makes it the current value. |
| Leased Credentials | SikkerKey mints a short-lived database login on demand, one per machine, creating it directly in your database and dropping it when the lease ends. You set the provider, the credential shape, and the lease policy: lifetime, renewal, a hard cap, re-mint behavior, and revoke-on-machine-disable. | Dynamic Secrets lease AWS IAM users and Azure Service Principals with a default 30-minute TTL and a lease ID for early revocation.These are cloud IAM identities, not logins created inside your own database, and the feature is Enterprise-only. | Each machine gets its own database login, so your database logs attribute every query to a machine, and the login expires when the lease ends. |
| Temporary Secrets | A one-shot, self-destructing secret you hand to a person. Creating one returns a link and a passphrase; the value is destroyed the moment it's viewed, on a wrong passphrase, or at expiry, which you set between 1 minute and 24 hours. The passphrase is stored only as an Argon2id hash. | Doppler Share sends a one-off secret through a link. The value is encrypted in the browser, and the server stores ciphertext and a hashed passphrase. Expiry is set by view count and days.A link can allow multiple views and can be created anonymously outside your vault, so a share is not a single-view event in your audit log. | A safe way to hand a secret to a person: it opens once and then expires on its own. |
| Secret Versioning | Every secret has a current version and an encrypted version history. Any change bumps the version and stores the new encrypted payload, whether a manual replace, a manual rotation, or a promoted managed rotation. Rollback restores any prior version as a new version. | Per-config activity logs in git-log style. Rollback targets a log entry and writes a new entry that reverses the change. Historical values can be redacted.History is a per-config activity log rather than a per-secret version chain. | A bad rotation or accidental replacement is reversible without breaking the audit chain. Operators restore a known-good value in seconds, machines receive it on their next read, and the rollback itself remains visible as the newest version. |
| Trash & Restore | SikkerKey gives deleted secrets a 30-day recovery window. Deleting a secret moves it to Trash, records when it was deleted and who deleted it, removes live machine access grants, and cancels rotation schedules. The Trash page lists deleted secrets with project, deletion time, who deleted them, days remaining, search, pagination, restore, permanent delete, and bulk permanent delete. Expired trash is permanently deleted automatically after 30 days. | Deleted secrets can be restored by rolling back their deletion from the config’s version history.Doppler restores deletions through config-level rollback rather than a dedicated Trash workflow with a fixed recovery window, deleted-secret metadata, automatic expiry, and permanent-delete controls. | Accidental deletes are recoverable without turning cleanup into support work. Teams can restore the secret during the recovery window, permanently purge sensitive leftovers when required, and let expired trash clear automatically after 30 days. |
| 05Access Controls | |||
| Access Policies | A named, reusable bundle of read-time constraints you bind to any secret, evaluated on every fetch. The axes are a time-of-day window, an IP/CIDR allowlist, read-rate caps, a co-signing machine that must approve, a TTL that destroys the secret after a deadline or a number of reads, and rotate-after-N-reads. One policy can govern many secrets. | Doppler has no reusable per-secret access policy. An individual secret cannot carry a time-of-day window, read-rate caps, a co-signing machine, TTL destruction, or rotate-after-N-reads. | Define the constraints a sensitive secret needs once and reuse the policy across every secret that shares them. Tighten it in one place and every bound secret tightens with it. |
| Vault IP Allowlist | Restrict machine access to the vault by source IP or CIDR range. Add IPv4 or IPv6 addresses, label them by office, VPC, CI runner, or region, and enable enforcement across the vault. Changes apply immediately, and disabling the allowlist can require a fresh passkey check. | Trusted IPs restrict a config's API access to the CIDR ranges you specify, defaulting to open.Scoped to a single config, and available on Team and Enterprise plans. | A machine key is only useful from an approved network. That narrows the blast radius of a leaked machine credential to the egress locations your team controls, while keeping the control simple enough to manage for office networks, cloud VPCs, and CI/CD runners. |
| Canary Secrets | A decoy secret. When a machine reads it, the machine gets the decoy value and the project locks in the same transaction: every further request against the project returns 423 Locked. You can extend the freeze to other projects the machine is attached to. | No decoy-secret or read-triggered lockdown primitive. | If a compromised machine touches the decoy, the project locks itself before anything real is read. |
| 06Audit & Alerts | |||
| Audit Logs | SikkerKey records vault activity across people, machines, AI agents, and background jobs. Each entry captures what happened, when, where the request came from, the related secret or machine, and a severity level for triage. The dashboard filters by action, severity, source IP, and time range, with CSV export and live updates. | Activity Logs in git-log style per config, plus separate Access Logs. Retention is 3 days on Developer, 90 days on Team, and 1,095 days on Enterprise.Retention is plan-gated, and activity and access history live in separate views rather than one log across every identity with severity triage. | During incident response or compliance review, teams can reconstruct a timeline across every identity that touched the vault. Severity classification helps separate routine activity from events that need review, and retention keeps high-severity events longer than routine activity while critical events stay available across the normal pruning window. |
| Email Alerts & Webhooks | Subscribe to vault events by action, category, and severity. Email alerts send selected events to the account email with the action, detail, related secret or machine, and source IP. Webhooks deliver them to HTTPS endpoints as signed JSON with delivery IDs for deduplication, with test delivery and health tracking in the dashboard. | Webhooks fire on secret-change events, signed with SHA256 and retried up to five times. Limits are 5 on Developer, 50 on Team, and 1,500 on Enterprise.Webhooks trigger on secret changes rather than any audit action, and there is no per-event email subscription across the full action catalog. | Teams can send urgent vault activity to people and systems at the same time: inboxes for human review, webhooks for SIEM, ticketing, incident response, or automation. Signed payloads, retries, health tracking, and visible delivery limits make the integration operationally predictable. |
| 07Team Management | |||
| Vault Roles | Vault roles control management rights across the organization vault, covering machines, AI agents, enrollment, audit, alerts, IP allowlist, integrations, members, billing, and more. Built-in Owner, Admin, Developer, and Collaborator tiers cover common shapes, and Enterprise teams can build custom vault roles from the same capability list. Role changes take effect on the member's next request. | Workplace roles carry fine-grained management permissions across the workplace. User Groups and SCIM assign them at scale.Custom roles are standard only on Enterprise or a paid Team add-on at $9 per seat per month. | Teams can delegate operational ownership at the right level. Built-in tiers cover common organization shapes, while custom roles let teams separate billing, member management, audit visibility, machine operations, alert configuration, and support work. |
| Access Roles | Access roles define which applications and projects a member can open and what management actions are available inside each. Scope can be everything, all application or standalone projects, selected applications, or individual projects. Action toggles cover secret types, project machine attachment and grants, and access-policy controls like time windows, IP allowlists, rate caps, co-sign, and TTL. | Project roles scope a member's access per project with fine-grained permissions, combined as the highest of any role that applies.Custom project roles are Enterprise or a paid Team add-on, and there is no application grouping or per-project access-policy authoring. | Teams can reuse one project scope across many members and tune action rights per environment. A production app can be visible to an auditor, editable by its service owner, and restricted for contractors, with the same access model covering current and future projects. |
| SAML SSO | Connect a SAML 2.0 identity provider such as Okta, Microsoft Entra ID, or Google Workspace. Each sign-in domain is verified with a DNS TXT record before it can provision members, and SSO can run alongside existing sign-in methods or be enforced for verified domains. New SSO users join on the minimal Collaborator role with no project access until roles are assigned. | SAML single sign-on, with SCIM directory provisioning on Enterprise.SCIM provisioning and directory sync are Enterprise-only. | Teams can bring SikkerKey into their existing identity provider, control who can sign in by verified domain, and roll new members into the vault with a minimal starting posture. Enforcement gives teams a clean path to require company sign-in without risking an owner lockout during provider changes. |
The Doppler details in this comparison are our interpretation of publicly available information as of 9 July 2026, and are subject to change. Do your own due diligence and consult Doppler's official documentation.