EU Alternatives to AWS Secrets Manager and Google Cloud Secret Manager

Choosing an EU alternative to AWS Secrets Manager or Google Cloud Secret Manager is not simply a question of finding another encrypted key-value store in a European region.

It is a choice between two different product categories:

• A cloud-native secret vault attached to one provider's IAM, logging, key management, and deployment tooling.
• A purpose-built secrets-management platform that supplies its own workload identity, secret lifecycles, access controls, connectivity, and incident response across infrastructure providers.

OVHcloud Secret Manager and Scaleway Secret Manager are credible European cloud services in the first category. SikkerKey is built for the second. AWS and Google Cloud remain relevant benchmarks, but the products should not be treated as though they expose the same capabilities under different logos.

Research note: Provider features and documentation were checked on 17 August 2026. Cloud services change, so follow the linked primary documentation when evaluating a production deployment.

The short answer

• Choose SikkerKey when you want the strongest dedicated secrets-management feature set in this comparison: signed machine identities, native Structured Secrets, selected-field rotation, managed and per-machine leased database credentials, private tunnels, reusable access policies, canary containment, certificate issuance, detailed audit export, native alerts, a first-party CLI, and six official SDKs.
• Choose OVHcloud Secret Manager when your security and infrastructure boundary is already OVHcloud and a Vault KV2-compatible API would reduce application migration work.
• Choose Scaleway Secret Manager when your workloads already use Scaleway IAM and its Kubernetes, Terraform, or Ansible ecosystem, especially if its single-access or TTL policy on stored secret versions fits your use case.
• Choose AWS Secrets Manager when your workloads and databases are firmly inside AWS and native IAM, VPC, CloudTrail, RDS, and Lambda integration is the priority.
• Choose Google Cloud Secret Manager when Google Cloud IAM, regional or automatic replication, CMEK, Pub/Sub, and the wider GCP control plane are already your operating model.

The crucial distinction is that OVHcloud, Scaleway, AWS, and Google Cloud primarily manage stored secret values and versions inside their cloud boundaries. SikkerKey also models the machines retrieving secrets, the structure and lifecycle of the credentials, the private network route used to manage them, and the response when a secret is accessed unexpectedly.

Comparison at a glance

This table deliberately distinguishes a native capability from something an operator can assemble with general-purpose cloud services. Every platform can be extended with code. The more useful question is what the secrets manager itself understands and operates.

What the hyperscaler products do well

AWS Secrets Manager and Google Cloud Secret Manager are capable services. Their real advantage is not that they can store a value; it is that they sit inside large cloud control planes.

AWS Secrets Manager uses AWS IAM for access, AWS KMS for encryption, CloudTrail for auditing, and VPC infrastructure for private access. It supports managed rotation for supported secrets and Lambda-based rotation for custom systems. AWS also publishes database rotation templates, including single-user and alternating-user patterns. For an application already built around RDS, Aurora, IAM roles, CloudWatch, and Lambda, this integration can be operationally convenient. AWS documents managed and Lambda rotation here.

Google Cloud Secret Manager similarly benefits from Google Cloud IAM, Cloud Audit Logs, replication choices, CMEK, and Pub/Sub. Its scheduled rotation mechanism sends a Pub/Sub notification; an external subscriber normally performs the actual credential change and creates the new version. In July 2026, Google also introduced automatic rotation for regional Cloud SQL PostgreSQL and SQL Server credentials in Preview. Google documents rotation schedules and records the Cloud SQL feature in its Secret Manager release notes.

Those are real strengths when the surrounding infrastructure already belongs to the same provider. They are less decisive when applications span several clouds, private networks, CI vendors, developer machines, or acquired infrastructure. At that point, one cloud's IAM becomes a foreign credential that must be distributed to workloads running everywhere else.

OVHcloud Secret Manager: a regional OVHcloud vault with a KV2-compatible surface

OVHcloud Secret Manager is built on the regional OKMS platform and integrates with OVHcloud IAM, KMS, and Logs Data Platform. It exposes both an OVHcloud REST API and an API compatible with the HashiCorp Vault KV2 data model.

Its KV2 API can store nested JSON, create a new version when a secret changes, use check-and-set to prevent conflicting writes, deactivate versions after a configured duration, and cap the number of retained versions. Authentication uses an OVHcloud personal access token, service account, or access certificate. OVHcloud's KV2 guide describes the data model and authentication methods.

That makes OVHcloud attractive when:

• OVHcloud IAM is already the organization's identity boundary.
• Secrets should remain on the same regional platform as other OVHcloud services.
• Logs Data Platform is already the audit destination.
• Existing applications speak the Vault KV2 API and changing that API would be costly.

The important qualification is that Vault KV2 compatibility is an API surface, not HashiCorp Vault functionality. It can reduce changes to read and write paths. It does not give OVHcloud Secret Manager Vault's broader engines, dynamic credentials, PKI workflows, leases, agents, or policies merely because a KV2 client can connect.

OVHcloud's publicly documented secret model is a versioned collection of key-value data. Nested JSON is useful, but it is not equivalent to SikkerKey Structured Secrets: OVHcloud does not document native selected-field generation and rotation, field-oriented retrieval, or the other field-aware lifecycle behavior described below.

Scaleway Secret Manager: a clean native service for Scaleway workloads

Scaleway Secret Manager is a regional service integrated with Scaleway IAM and Key Manager. It stores immutable secret versions, supports Scaleway-managed or customer-selected encryption keys, and integrates with Kubernetes External Secrets, Terraform, and Ansible. Scaleway lists those native integrations and its current pricing.

Its most distinctive lifecycle feature is an ephemeral policy applied when a secret is created:

• Single access disables or deletes a stored secret version after one read.
• Time to Live keeps versions accessible for a configured period of up to one year.

Those controls are useful for bootstrap data and time-bounded handoffs. They operate on stored versions; they do not mint a new database identity for each requesting machine. The policy also cannot be removed after it has been applied. Scaleway documents those semantics in its Secret Manager quickstart.

Scaleway also assigns types such as opaque data, credentials, and certificates. The API still accepts the payload as encoded data—for example, the official API quickstart serializes a username and password into JSON and stores the resulting payload. Type metadata is not the same as a native, field-addressable secret with selected-field rotation. The Scaleway API quickstart shows the request and access model.

Scaleway is therefore a sensible choice when the organization already relies on Scaleway IAM, projects, API keys, and deployment tooling. Outside that boundary, the workload must receive and protect a Scaleway API credential, normally sent as X-Auth-Token. That is a standard cloud API model, but it is materially different from SikkerKey's machine-generated key and per-request signatures.

SikkerKey: a purpose-built secrets-management platform

SikkerKey starts with a different abstraction. A workload is not merely a holder of an API token. It is a named machine with its own cryptographic identity, grants, lifecycle, guardrails, and audit history.

During enrollment, a machine generates an Ed25519 keypair locally. SikkerKey stores the public key; the private key remains on the machine. Each API request is signed over the method, path, timestamp, one-time nonce, and body hash. A captured request cannot simply be replayed, and the workload does not carry a reusable SikkerKey bearer token.

Authentication alone is not authorization. Before a read succeeds, SikkerKey checks that the machine is valid, approved, associated with the project, explicitly granted the secret, allowed by the vault IP rules, and compliant with the secret's access policy. See the security overview and standard-machine guide.

At rest, each stored value receives a fresh AES-256-GCM data key. That key is wrapped by a per-project master key behind isolated root-key infrastructure. Eligible plans can add a customer-controlled Google Cloud KMS or OVHcloud KMS key above the project-key layer. Enabling or disabling BYOK re-encrypts the vault rather than leaving old values under a different protection model, and the OVHcloud integration separates KMS authorization from renewable mTLS access certificates. See Bring Your Own Key.

SikkerKey provides standard, temporary, and ephemeral machine workflows. Enrollment tokens can be constrained by projects, secrets, expiry, use count, source network, and machine naming. Temporary machines add absolute expiry plus IP/CIDR, country, day, and time-window guardrails that are evaluated on reads. This makes CI runners, containers, contractors, test systems, and short-lived jobs first-class identities rather than exceptions to a server-centric model. See Enrollment Tokens and Ephemeral Machines and Temporary Machines.

Structured Secrets are more than JSON

Many secret stores let a user paste JSON into a text field. The application must then know the schema, parse it, select fields, and implement any field-specific lifecycle itself.

SikkerKey Structured Secrets make the fields part of the product model. A database credential can contain host, port, username, and password under one secret identity. The CLI and SDKs can retrieve the full map or address an individual field. At creation, selected fields can be marked for automatic generation and scheduled rotation while the other fields remain static. Each rotation preserves the static values, replaces only the selected fields, and versions the complete structure.

That distinction matters. Rotating a password should not unexpectedly rewrite a hostname, port, or username, and consuming one field should not require every application to carry bespoke JSON glue code. See Structured Secrets.

Generated, managed, and leased credentials solve different problems

“Rotation” often gets used for several different operations. SikkerKey separates them:

• Generated rotation replaces a SikkerKey-generated standard value, or selected fields inside a Structured Secret, on a schedule.
• Managed Secrets rotate a credential in the destination database and keep the stored credential synchronized.
• Leased Secrets mint a separate, short-lived database account for the requesting machine on demand.

Leased Secrets are not simply fast rotation. For PostgreSQL, Supabase, MySQL, MariaDB, Redis, and Microsoft SQL Server, SikkerKey can create a temporary account per machine with configured grants and a bounded lifetime. A lease can renew within policy, enforce a hard maximum, re-mint after expiry or on every read, use database-native expiry where supported, and revoke credentials when the machine is disabled.

The result is better attribution and a smaller blast radius than distributing one shared database password to a fleet. Disabling one machine can revoke its account without forcing every healthy workload to adopt another shared password. See Managed Secrets and Leased Secrets.

Tunnels reach private databases without opening inbound access

Credential lifecycle is only useful if the platform can reach the target system. SikkerKey tunnels solve this for private infrastructure.

A tunnel binds to one approved machine running inside the customer's network. That connector establishes an outbound connection to SikkerKey. Operators expose only named targets—specific internal hosts and ports—through the tunnel. Managed rotation and lease minting, renewal, and revocation can then operate against a private database without publishing that database to the internet or exposing the wider network.

This applies across clouds, on-premises networks, internal DNS zones, and mixed estates. It is not a claim that ordinary secret reads need the tunnel; it is a controlled route for SikkerKey's database operations. See Tunnels.

Native secret lifecycles go beyond stored versions

SikkerKey models several security workflows as dedicated secret types:

• TTL Secrets create a one-time sharing URL and separate passphrase. The value is viewable once, and an incorrect passphrase destroys it.
• Canary Secrets are intended never to be read. If a granted machine retrieves one, SikkerKey can freeze the current project and related projects, causing machine reads to return a locked response until an operator investigates and unfreezes them.
• Certificate Secrets issue short-lived SSH or X.509 certificates from vault-scoped certificate authorities. The requester generates the private key; SikkerKey signs the public key subject to the configured principals, names, usages, source restrictions, and maximum validity.

These are not labels on arbitrary blobs. They are separate execution paths with different security semantics. See TTL Secrets, Canary Secrets, and Certificate Secrets.

Policies, detection, and audit are part of the same system

SikkerKey access policies are reusable within a project and can combine:

• Allowed days, times, and time zones.
• Source IP and CIDR restrictions.
• Per-minute and per-day read limits.
• A second machine acting as a co-signer within a defined window.
• Absolute destruction time.
• Destruction after a maximum number of reads.
• Rotation after a configured number of reads.

This allows the organization to express rules about how a secret may be used, not only who may retrieve it. See Access Policies.

Alerts can be delivered through email, native Slack and Discord destinations, or generic HTTPS webhooks carrying signed SikkerKey JSON. Event selection spans secrets, machines, authentication, organizations and SSO, sessions, AI agents, billing, integrations, temporary secrets, and tunnels.

The audit log is directly usable during an investigation. Operators can filter by action, severity, actor type or specific actor, source IP, free-text detail, and date range. Exports are available as CSV, JSON, or text, with the JSON export including provenance such as the export time, selected range, filters, and entry count. See Alerts and Audit Log.

First-party delivery is part of the product

SikkerKey provides a single-binary CLI and six official SDKs: Go, Python, Node.js, .NET, Kotlin, and PHP. The SDKs are open source under the MIT license and share the machine-signing protocol.

Beyond basic reads, the SDKs support field-oriented Structured Secret access and project-scoped exports. They can use an encrypted, machine-bound fallback cache for defined connectivity failures without substituting stale data for an authoritative denial or revocation. Five SDKs can also watch secrets and notify the application when a value changes, is deleted, becomes inaccessible, or cannot be refreshed.

That is meaningfully different from saying a generic cloud SDK can call an endpoint. It is a purpose-built application delivery layer with consistent authentication, caching, change handling, and errors across languages. See the CLI guide and SDK overview.

Where each competitor genuinely outperforms SikkerKey

A fair comparison should still identify the cases where another product has the advantage.

AWS Secrets Manager

AWS has the advantage when the target architecture is intentionally AWS-native. IAM roles, VPC endpoints, CloudTrail, CloudFormation, Lambda, RDS, Aurora, Redshift, and DocumentDB already share one provider boundary. AWS also supports rotation patterns and database engines beyond SikkerKey's currently documented managed and leased provider list.

That is ecosystem integration and provider breadth—not a broader dedicated secrets-management model.

Google Cloud Secret Manager

Google has the advantage when Google Cloud IAM, organization policy, Cloud Audit Logs, Pub/Sub, Cloud Asset Inventory, and multi-region or explicitly placed replicas are required as native GCP resources. Its regional Cloud SQL automatic rotation feature may also be attractive for the supported engines once Preview status fits the organization's risk policy.

Again, the advantage is tight GCP integration. For general rotation workflows, Google documents a notification-and-subscriber pattern rather than a complete field-aware or per-machine lease lifecycle.

OVHcloud Secret Manager

OVHcloud has the advantage for an OVHcloud-centered estate that wants the secret service, IAM, KMS, regional endpoint, and logs from one European cloud provider. Its published Vault KV2-compatible endpoint can also reduce the code changes required by an existing KV2 client.

That compatibility should not be inflated into Vault feature parity.

Scaleway Secret Manager

Scaleway has the advantage for a Scaleway-centered estate using its IAM, projects, Key Manager, Kubernetes, Terraform, and Ansible integrations. Its immutable-version model and irreversible single-access/TTL policy are simple, native mechanisms for expiring stored values.

Those policies are not equivalent to SikkerKey TTL sharing, read-count policies, selected-field rotation, or per-machine database leasing. They are narrower features that may nevertheless be exactly right for a particular Scaleway workflow.

A practical decision matrix

How to evaluate a migration

Do not compare only the number of stored values or the price per API call. Inventory the whole secrets workflow:

1. Which identity does each workload carry, and how is that identity bootstrapped, rotated, and revoked?
2. Is a “structured secret” actually field-aware, or is it application-parsed JSON?
3. Does rotation merely create a version, update the real credential at its destination, or mint a new account for each workload?
4. Can the platform reach private targets without exposing them publicly?
5. What happens automatically after a suspicious read?
6. Can an investigator filter and export the relevant audit trail without first building a logging pipeline?
7. Are Slack, Discord, email, and signed webhook notifications native, or must the team assemble them elsewhere?
8. Does the provider supply and maintain the runtime SDKs, caching behavior, change watching, CLI, and CI workflows?
9. Which parts of the design belong to the secrets manager, and which depend on the surrounding cloud?

A safe migration should overlap the old and new systems, move one non-critical workload first, test denied and revoked reads as well as successful ones, rotate the migrated credential at its source, and remove the old value only after every consumer has moved.

The recommendation

OVHcloud Secret Manager and Scaleway Secret Manager are legitimate European alternatives when the objective is to use a European cloud's native vault. AWS and Google Cloud remain effective when the organization has deliberately accepted their respective cloud boundaries.

SikkerKey is the stronger choice when the objective is secrets management itself.

Its advantage is not simply that it works across clouds. It combines cryptographic machine identities, explicit grants, native Structured Secrets, several distinct rotation and credential-lifecycle models, private tunnels, reusable policies, containment secrets, certificate issuance, operational alerting, audit export, and a first-party application delivery layer.

Cloud-native secret stores can be extended with functions, agents, external operators, logging pipelines, and custom code. That can be the right engineering decision inside a strategic cloud. It should not be mistaken for the same product capability being available natively.

For teams that want one dedicated European secrets platform across their infrastructure—not another cloud-specific place to store encrypted blobs—SikkerKey is the most complete option in this comparison.