SikkerKey vs OVHcloud Secret Manager
Manage one EU secrets vault across OVHcloud, AWS, Hetzner, on-prem hosts, and developer laptops, with one cryptographic identity per machine. Your secrets stay in the EU, and the auth doesn't depend on an OVHcloud account.
Summary
OVHcloud Secret Manager is part of OVHcloud's Identity, Security, and Operations range. Access is governed by OVHcloud IAM, secrets are encrypted with OVHcloud KMS, audit events stream to OVHcloud Logs Data Platform, and it exposes a HashiCorp Vault KV2-compatible API. It is a credible sovereign option: secrets stay in the OVHcloud region you choose, with EU compliance certifications behind them. Pricing is per secret version per month, set by region.
SikkerKey is built around a different primitive. Every request is signed by the machine making it, using an Ed25519 private key that lives on the host and never travels. The signature commits to the exact method, path, body, and timestamp, so it doesn't double as a credential anyone can replay, and there is no token sitting in the environment that reads your vault if it leaks.
Both keep your secrets in the EU, so EU jurisdiction alone doesn't separate them. If you are choosing an EU secrets manager and weighing OVHcloud Secret Manager, the real question is the model around the secret. SikkerKey is an independent EU secrets layer, not tied to any one cloud: the same bootstrap registers a machine on OVHcloud, AWS, a Hetzner box, an on-prem rack, or a laptop, and you can run SikkerKey while your workloads stay on OVHcloud.
Around that primitive, SikkerKey ships what a key-value store doesn't: 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, contractor machines with IP, geo, and time guardrails, one-view share links, and HMAC-signed webhooks for every audit action.
A workload on OVHcloud and a workload on a Hetzner box authenticate to the same SikkerKey vault, with the same bootstrap and the same signed-request protocol.
The result:teams that want an EU secrets manager without binding their secrets layer to a single cloud keep one identity model everywhere, instead of adopting one provider's IAM as their secrets platform.
| SikkerKey | OVHcloud Secret Manager | 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. | OVHcloud IAM governs who can access a secret, and the HashiCorp Vault KV2-compatible API is reached with a token your client holds and presents on each request. The token keeps reading until it expires or is revoked. | The signature is bound to one specific request and stops being valid the moment the request is sent. There is no token sitting in the environment that keeps reading your vault if it leaks; the next call needs a fresh signature, computed on the host from a private key that never leaves it. |
| Workloads beyond OVHcloud | The same bootstrap script. A developer laptop, an on-prem box, a Hetzner machine, an AWS instance, and an OVHcloud instance run identical commands. | Reachable over its REST and Vault KV2 APIs from anywhere, but access runs through an OVHcloud account and OVHcloud IAM, with keys in OVHcloud KMS and audit in OVHcloud Logs Data Platform. The credential and the whole control plane live in OVHcloud. | SikkerKey's auth doesn't route through one provider's account or IAM. The bootstrap that runs on an OVHcloud instance is the same one that runs on AWS, on-prem, or a laptop, so adding a second cloud doesn't mean standing up a second secrets model. |
| 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 ephemeral-fleet primitive. CI runners authenticate with OVHcloud IAM credentials provisioned through the account's IAM model, and are cleaned up the same way. | 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, with no per-runner IAM wiring. |
| Sovereignty and independence | |||
| EU jurisdiction | A Danish company. Your secrets, audit log, and machine identities sit on EU infrastructure under GDPR. No US-owned cloud in the path of the stored data. | A French cloud with strong sovereignty credentials: ISO 27001, HDS, PCI-DSS, with CSPN in progress. Secrets stay in the OVHcloud region you choose. | Both keep your secrets in the EU, so EU jurisdiction alone doesn't separate them. If you are choosing an EU secrets manager and weighing OVHcloud Secret Manager, the decision comes down to the model around the secret, not the flag on the datacenter. |
| Independence from the cloud | An independent secrets layer. One identity model across OVHcloud, AWS, Hetzner, on-prem, and laptops. You can run SikkerKey while your workloads stay on OVHcloud. | Tied to an OVHcloud account and to OVHcloud IAM, KMS, and Logs Data Platform. Adopting it makes OVHcloud your secrets layer as well as your cloud. | Your secrets layer outlives any single provider decision. Adding a second cloud, going hybrid, or moving a workload off OVHcloud doesn't force a migration of the secrets platform too. |
| 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. An application or AI service authenticates as an OVHcloud IAM identity; if that identity can read the secret, it reads the plaintext. | 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. IAM policy conditions can express some limits, but per-identity country allowlists and time-of-day windows baked into the identity aren't part of the model. | 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 | |||
| 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. | The KV2 engine stores key-value pairs inside a secret. Access is granted at the secret level through IAM, not per field, and the application reads the value and parses it. | The whole credential rotates and audits as a single object, and a grant can target one field. SDKs expose each field directly, so application code reads secret.password rather than parsing a document returned by the API. |
| 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. | No native equivalent. | Hand a credential to a contractor or a teammate without putting it in chat. The link self-destroys after one view or one wrong passphrase, and every share is logged with creator, viewer IP, and timestamp. |
| Access controls | |||
| 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. | OVHcloud IAM policies control who can manage or access each secret. Read-rate caps, co-signing, TTL-based 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. |
| 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. |
| Rotation | |||
| Database credential rotation | The agent runs on the host you choose: a Kubernetes pod, an OVHcloud 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. | Not a documented native rotation feature. Versioning lets you store a new value, but generating it, applying it to the database, and verifying it are left to you. | 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. |
| Observability | |||
| 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. | Audit events stream to OVHcloud Logs Data Platform. Native per-event webhooks with HMAC signing, retry, and SSRF protection aren't part of the service. | 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. |
| Operational | |||
| CLI workflow | A single Go binary. sikkerkey run --secret <id> -- <command> injects the secret as an environment variable and runs the command. Optional --watch polls every 15 seconds and restarts the child process when a secret rotates. | A REST API, the Vault KV2 API, and OVHcloud CLI and Vault clients read values. Injecting a value into a process environment and restarting it on rotation are the caller's job. | Drop a SikkerKey-aware command into a Procfile or a Dockerfile entrypoint and the secret arrives in the child's environment without writing it to disk. Rotation triggers a clean process restart with the new value. |
| 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. | Around $0.03 per secret version per month, priced by region. The bill scales with stored secret versions and the regions you keep them in. | The SikkerKey bill doesn't move with stored-secret count or the regions you store in. Pricing is public and flat per plan with no per-secret line item; the one thing that scales is machine count beyond your plan's allotment, billed at a flat published per-machine rate. |