SikkerKey vs Doppler
Dive into how SikkerKey compares with Doppler. Both are SaaS-oriented secrets management platforms, but they operate from different architectural philosophies.
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 Authorization header 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.
Machine identity is the primitive every secret read goes through.
The result: a more secure model where the correct behavior is the default.
| 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. | Bearer token. Sent in the Authorization header on every API call (Authorization: Bearer dp.<type>.<value>). | A signature only validates for the exact request it was made for: method, path, body, and timestamp are all signed in. The private key that produces the signature stays on the machine for its entire lifetime. |
| MCP Integration | |||
| 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. | The official Doppler MCP server is experimental and 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. |
| 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 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. |
| 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. | Granting four of five fields to a new service silently breaks in production on the missing field. Structured secrets keep the credential as one access grant with one rotation surface that can target specific fields, and the SDK reads fields directly so application code doesn't parse JSON. | |
| Managed secrets | The agent runs on any host you control: Kubernetes pod, EC2 instance, on-prem box, anywhere a binary can run. SikkerKey generates the new value, the agent applies it via the database's own admin protocol, verifies it works, then confirms back so SikkerKey promotes it as the new live version. Supports PostgreSQL, MySQL, Redis, MongoDB. | Doppler invokes an AWS Lambda function in your AWS account, which holds the database admin credentials and applies the rotation. Uses a two-secret strategy that alternates between active and inactive credential instances. The Lambda must run in AWS even when the database is elsewhere. | Run the rotation agent wherever your application already lives, on any cloud or on-prem. The two-phase confirm means the new credential is verified working in your database before it becomes live, so a broken rotation never enters production. |
| 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. | A compromised machine in your vault triggers a complete project lockdown the first time it reads a canary, before more of your secrets can be fetched. 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; a secret with no policy uses the standard access model. | Doppler's Scoped Secrets allow environment-based and IP-based restrictions on individual secrets. | 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. Application code doesn't have to enforce any of it. |
| 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 history, git-log style. Each change in a config (secret edit, trusted-IP change, etc.) becomes 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 for the lifetime of the secret. |
| Audit log | One append-only log for every vault action by any actor (machine, AI agent, team member, or you). Each entry carries action, actor, source IP, and a severity tag from info to critical. | Three separate surfaces: workspace activity, per-secret access logs, and per-config commit history. Per-plan retention windows. | 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 60+ audit actions, opt-in per action. Webhook deliveries are HMAC-SHA256 signed, retried with backoff, and auto-disabled after consecutive failures. | Email alerts cover per-secret rotation reminders. Webhooks fire on a single event type (config.secrets.update). | Wire any audit action to email or HMAC-signed webhook delivery, opt-in per event. Retries with backoff, SSRF protection, and auto-disable on persistent failures keep your monitoring intact when an endpoint flakes out. |
| 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. | Anonymous browser share at share.doppler.com. AES-GCM encryption in the sender's browser; the server stores ciphertext and a hashed passphrase. 1 to 50 views (or unlimited) for up to 90 days. | Track every share in the vault audit log: who created it, when it was viewed, and what IP viewed it. The link cannot be viewed again after one view or one wrong attempt. |
| Official SDKs | Five SDKs: Kotlin, Go, Python, Node.js, .NET. 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, or .NET 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. |