Create an IAM user
A user with only the Secrets Manager permissions we need. The exact policy is in the docs, you can paste it as is.
AWS Secrets Manager Integration
Connect an IAM access key and we push each variable into Secrets Manager as its own secret, in the region you choose. Your services keep reading secrets through IAM like they do today, we only take over the part where someone has to keep the values up to date.
Follow this flow and your variables are synced in minutes.
A user with only the Secrets Manager permissions we need. The exact policy is in the docs, you can paste it as is.
Paste the access key and pick a region. We check it can actually reach Secrets Manager there, not just that the key exists.
Defaults to the environment name, so production gets PROD_DATABASE_URL and staging gets STAGING_DATABASE_URL.
Manually, or automatically on every change if you turn that on.
Everything needed to operate AWS Secrets Manager secrets from EnvManager.
DATABASE_URL becomes a secret called PROD_DATABASE_URL. No JSON blob to unpack on the other side.
We compare before we write, so a sync where nothing changed creates no new versions and costs you nothing extra.
Every secret we create carries managed-by=envmanager and the environment name, so you can always tell which ones we own.
Delete a variable and we schedule the secret for deletion with a 7-day recovery window. Add it back within that week and we restore it.
The documented policy grants seven Secrets Manager actions on your prefix and nothing else. If one is missing, the error names it.
Pick the region per connection. Several AWS accounts or regions? Add a connection for each.
The IAM policy to paste, how prefixes and versions work, and what happens when you remove a variable. Curious what it costs on the AWS side? Read our AWS Secrets Manager pricing breakdown on the blog.
14-day free trial. Connect AWS Secrets Manager and sync your first variables in under 5 minutes.