Your own key vault (Azure, AWS or Google Cloud)

Under Environments, click Development and choose Secrets and keys: there you see where this environment's secrets live and whether the vault works. A new environment uses Flow's own vault: encrypted in its own database.

Check now checks that this environment's vault answers: that it can open its key and read the names Flow uses. For Flow's own vault there is nothing to set up — no rights, no test secret. If a name a workflow or connection uses is missing, you see that here too.

Choose another vault and fill in where the secrets will live: the region, the role Flow assumes and the prefix under which this environment may read — every environment a prefix of its own, so Development can never reach Production's secrets. A developer may propose this too; only an owner approves it.

The portal writes out exactly what you set up in AWS, with this environment's values already filled in: the portal as identity provider, a role that trusts only this environment, and read access under the prefix. No access key is needed. Then put the values in Secrets Manager under their workspace's name — /; Flow shows that name with every secret — plus the test secret flow-canary right under the prefix.

Before anyone approves, the environment reads the test secret flow-canary from the proposed vault — with its own identity, as it will for real — and checks that every name it uses is there. You see what was found, never a value.

An owner approves; who asked and who decided is recorded. The environment restarts and from then on reads from AWS. The same workflows keep working: the names stayed the same.

Once the environment runs again, AWS Secrets Manager is at the top, with the prefix. Check now reads the test secret from the environment's own vault; the result stays as its health, with who tested and when. An error stays visible until a later test succeeds.

Every environment chooses its own vault. Open Production and propose Google Cloud Secret Manager: the project ID that holds the secrets, the project number, the workload identity pool and the provider in it. A service account is not needed: left empty, Flow reads with the environment's own identity, without a key file.

The steps in the portal already name your project number, pool and provider: create the pool, add the portal as OIDC provider with the condition that lets only Production in, and give that identity the role Secret Manager Secret Accessor. Put the values in Secret Manager under their workspace's name, __, plus flow-canary. Then test the vault: Production reads the test secret with its own identity.

After approval Production restarts and from then on reads from Secret Manager; Development stays on AWS. The same workflow looks up the same name, each in its own vault. Check now proves it.