SikkerKey vs Doppler
Both are SaaS secrets management platforms, but they authenticate workloads differently. SikkerKey signs every request from a private key on the machine; Doppler authenticates with a bearer token the workload carries on every API call.
Summary
Both Doppler and SikkerKey are SaaS-oriented secrets management platforms. They overlap on the basics: encryption at rest, rotation, and audit logging. Where they differ is what authenticates a request to fetch a secret.
Doppler authenticates with bearer tokens. A DOPPLER_TOKEN in an Authorizationheader proves identity by possession. The token has to live on the workload's filesystem or in its environment to be readable.
SikkerKey authenticates every request with an Ed25519 signature computed from a machine's private key that never leaves the machine. The request itself proves which machine made it. The signature only validates for the exact method, path, body, and timestamp it was made for.
Around that primitive, SikkerKey ships features Doppler doesn't have natively: structured secrets with per-field grants, canary secrets that lock a project on first read, an AI agent identity class that's structurally read-blind on stored values, temporary machines with IP / country / time guardrails, and CI fleet enrollment tokens with hostname and CIDR matching.
The result:a more secure model where the correct behaviour is the default, and a flat plan that doesn't add per-seat or per-feature add-on charges as the team grows.
| SikkerKey | Doppler | Why it matters | |
|---|---|---|---|
| Machine authentication | |||
| Secret request | Ed25519 signed request. The signature is computed on the machine from a private key that never leaves it, and SikkerKey verifies it against the public key on file. | Service Token bearer credential ( dp.st.*) sent in the Authorizationheader on every API call. The same token authenticates every request until it's rotated. | The signature is bound to one specific request and stops being valid the moment the request is sent. The next call needs a new signature, computed on the machine from the same private key, which stays on the host across the machine's lifetime. |
| CI fleet enrollment | One enrollment token registers up to N ephemeral machines, each with a hostname regex match, source CIDR check, and an automatic expiry. Auto-expired machines are soft-disabled and hard-deleted 30 days later. | No native fleet-enrollment primitive. Service Tokens are manually issued and scoped to a single config; CI runners share or duplicate tokens manually. | An enrollment token issued from the dashboard provisions identities for new CI runners as they come online and revokes them when their machines disappear. Setting up a new runner means dropping a curl command into the runner's startup script; per-runner token management isn't something an operator has to track separately. |
| Identity primitives | |||
| AI agent identity | AI agents are a separate identity class with their own table, scope set, and Ed25519 signed-request authentication. The agent surface is structurally plaintext-blind: write actions accept plaintext input but never return stored values, and the read paths physically don't accept an agent identity as a caller. | Not a separate identity class. The official Doppler MCP server uses a standard Doppler bearer token; the MCP inherits whatever scopes the token holds, including secret-read if granted. | Give an AI agent broad management permissions on your vault without any risk of it reading your secrets. The agent identity is structurally plaintext-blind, so even an agent granted every management scope cannot fetch a stored value. |
| Temporary machines | Single-use bootstrap tokens that mint time-bounded machines with optional per-machine IP allowlist, ISO-3166 country allowlist, and IANA time-of-day window. Bounded between 1 hour and 12 months at issuance; extensions are audited inline with full revert history. | No native primitive. Service Tokens can be ephemeral via --max-age, but the per-machine country and time-of-day guardrails aren't expressible. | The bootstrap token bakes in the time window, source IP range, country allowlist, and lifetime at the moment of issuance. Those constraints attach to the machine identity itself, so they apply at every fetch without anyone having to remember to enforce them later. |
| Secret model | |||
| Single-value secrets | A named string value, encrypted at rest with its own per-secret data key. Any UTF-8 name, values up to 12 KB. | A named string value with optional masking and visibility settings. Names are restricted to uppercase letters, numbers, and underscores. | API keys, tokens, signing secrets, and connection strings are single string values. The baseline primitive every application needs, with no naming restrictions to work around. |
| Structured secrets | A secret can hold multiple named fields as one logical unit. A database credential is one secret with host, port, username, password fields, encrypted and versioned together. SDKs read fields directly. | Not a native primitive. Doppler secrets are strings; structured data is the application's responsibility to encode and parse. | The whole credential rotates and audits as a single object. SDKs expose each field directly, so application code reads secret.password rather than parsing a serialized blob to find the field. |
| Managed secrets | The agent runs on the host you choose: a Kubernetes pod, an EC2 instance, a Hetzner machine, an on-prem box. SikkerKey generates the new value, the agent applies it via the database's admin protocol, verifies it works, then confirms back so SikkerKey promotes it as the new live version. Supports PostgreSQL, MySQL, Redis, MongoDB. | Built-in rotation handlers for AWS, Azure, GCP, MongoDB, Sendgrid, and Twilio. The AWS database rotation handler invokes a Lambda in your AWS account that uses a two-secret strategy alternating between active and inactive credential instances. The Lambda runs in AWS even when the database is elsewhere. | Run the rotation agent on the host where your application already lives. The agent applies the new credential and tests a connection against the database before reporting back; SikkerKey only promotes the new value after that test passes. |
| Access controls | |||
| Canary secrets | A decoy secret you plant in a project alongside the real ones. Looks identical to any other secret to whatever reads it. | Not a native primitive. | A compromised machine in your vault triggers a complete project lockdown the first time it reads a canary, in the same database transaction as the fetch, before more of your secrets can be returned. An optional second layer extends the lockdown to every other project the same machine has access to. |
| Per-secret access policies | Named policies you bind to specific secrets. Each policy can require a time window, an IP allowlist, a read-rate cap, a co-signing machine, TTL-based destruction, or rotate-after-N reads, in any combination. One policy binds to many secrets. | Doppler's Scoped Secrets allow environment-based and IP-based restrictions on individual secrets. Read-rate caps, co-signing machines, TTL destruction, and rotate-after-N-reads aren't expressible. | Lock down a high-value secret with constraints SikkerKey enforces at every fetch: time windows, IP allowlists, read-rate caps, co-signing, TTL destruction, or rotation triggers. The enforcement runs server-side, so the application receives either the secret value or a denial. |
| History & observability | |||
| Secret versioning | Each secret carries its own version history. Every write inserts a row with its own encrypted data key, and rollback restores any prior version as a new version, leaving the original history intact. | Per-config Activity Logs in git-log style. Each change (secret edit, trusted-IP change, etc.) is a log entry; rollback targets a log_id and writes a new entry that reverses the change. | Roll back any secret to a specific prior version without searching a global event log. Each version's encrypted data key lives on its own row, so old values stay decryptable across the secret's lifetime. |
| Audit log | One append-only log for every vault action by any actor (machine, AI agent, organization member, or you). Each entry carries action, actor, source IP, and a severity tag from info to critical. | Activity Logs (git-log style per config) and separate Access Logs. Retention is 3 days on Developer and 90 days on Team; longer history requires Enterprise. | Critical events (canary trips, 2FA disabled, vault destruction) stay in the log forever, regardless of your plan's retention window. Every entry streams live to your dashboard and exports to CSV for SIEM ingestion. |
| Alerts and webhooks | Email and webhooks for any of 160+ audit actions, opt-in per action. Webhook deliveries are HMAC-SHA256 signed, retried with exponential backoff, SSRF-protected by DNS pinning, and auto-disabled after 10 consecutive failures. | Webhooks fire on Doppler events. Webhook limits: 5 on Developer, 50 on Team. | Wire any audit action to email or to an HMAC-signed webhook, opt-in per event. The delivery layer retries with exponential backoff, refuses to call internal or private-range addresses, and auto-disables an endpoint that fails 10 deliveries in a row. |
| Sharing & SDKs | |||
| Temporary share links | Server-generated diceware passphrase, hashed with Argon2id. One view total; the secret is destroyed on the first wrong passphrase. Expiry between 60 seconds and 24 hours, audit-tracked from creation to view. | Anonymous browser share at share.doppler.com. AES-GCM encryption in the sender's browser; the server stores ciphertext and a hashed passphrase. Up to 50 views (or unlimited) over up to 3 months, with the passphrase optional and anonymous creation possible. | Track every share in the vault audit log: who created it, when it was viewed, and what IP viewed it. The link can't be viewed again after one view or one wrong passphrase attempt. |
| Official SDKs | Six SDKs: Kotlin, Go, Python, Node.js, .NET, and PHP. Each handles the Ed25519 signature, timestamp, and nonce locally; application code calls one method and receives the secret value. | Two SDKs: Node.js and Python. Other languages (C#, Go, Java, PHP, Ruby) are listed as planned. | Drop SikkerKey into a Kotlin, Go, Python, Node.js, .NET, or PHP service without implementing the signing protocol yourself. The SDK auto-loads the machine's identity at startup, signs each request locally, and returns the value. |
| Operational | |||
| Pricing model | Flat monthly plans with a free tier and public pricing. Unlimited projects and secrets, no metering on stored secrets or API calls, and team size doesn't change the price. Each plan includes a set number of machines; additional machines are a flat per-machine monthly add-on. | Per-user pricing. Developer is free for 3 users, then $8 per additional user per month up to 25. Team is $21 per user per month up to 500. Enterprise is custom. Custom roles, user groups, and integration syncs are $9 per seat per month each as Team-tier add-ons. | The SikkerKey bill doesn't move with team size or secret count. Pricing is public and flat per plan with no per-seat charges; the one usage-based element is machine count beyond your plan's allotment, billed at a flat published per-machine rate. |