"Which secrets manager is best for cloud?" usually gets answered with a reflex: use whatever your cloud provider ships. If you run on one cloud and you only ever will, that answer is fine. Most teams are not in that situation, which is why "best for cloud" is the wrong question to optimize for. The better one is "best across whatever clouds I end up running on," because that is the situation almost everyone is actually in.

The hidden assumption in "best for cloud"

A cloud provider's built-in secrets manager is built for that provider's cloud. It authenticates through that cloud's identity system, it is reached through that cloud's APIs, and it is operated on that cloud's terms. Inside a single cloud, that is convenient.

The trouble starts the moment something runs somewhere else: a second cloud after an acquisition, a hybrid setup with on-prem or edge machines, a migration, a SaaS platform or CI runner that is not in your cloud at all. The built-in option does not reach those places, so you end up doing one of two things. You run a second secrets manager for the other environment, which leaves you with two systems and two mental models. Or you copy your secrets out into wherever they are needed, which spreads copies of your credentials across platforms and becomes its own security problem.

A cloud-native secrets manager optimizes for a single-cloud world. Fewer and fewer teams live there for long.

"Best for cloud" should mean "works on any cloud"

Reframe the question and the answer gets simpler. The secrets manager that is genuinely best for cloud is the one that does not care which cloud you are on. Your machines run wherever they run, and every one of them reaches the same vault the same way.

That is what cloud-agnostic means in practice:

One vault and one workflow, whether a machine is on one cloud, another, a hybrid setup, or your own hardware.
A migration between clouds does not touch your secrets. The vault stays where it is, and the machine keeps reading from it.
Multi-cloud is the default rather than a special case you bolt extra tooling onto.
One source of truth and one audit trail across every environment, instead of one per provider.
No lock-in to a single provider's identity model, APIs, or pricing for something as foundational as your secrets.

How SikkerKey stays cloud-agnostic

SikkerKey does not live inside any cloud's identity system, so it does not inherit any cloud's boundaries. Each machine gets its own identity, an Ed25519 keypair, and reads secrets at runtime by signing its request. Anything that can run code and make an authenticated HTTPS call can read from the vault: a container on one cloud, a function on another, a server in your own rack, a CI job, a laptop.

There is nothing cloud-specific to wire up, because there is no cloud-specific path. The same call and the same signed request work identically on every platform. When you add a cloud, you add machines, not a new secrets stack. When you leave a cloud, your secrets stay exactly where they were, because they were never tied to it.

The honest answer

If you will only ever run on one cloud, that cloud's built-in manager will do the job. If your reality already includes more than one environment, or might later, the best secrets manager for cloud is the one that treats every cloud the same and ties your secrets to none of them. That is what SikkerKey is built for: your machines read one secret from one vault wherever they run, so which cloud you choose stops being a question about your secrets at all.