Put your secrets in the repo. Yes, really.
A .cake holds machine-readable secrets as happily as it holds a PDF. Commit it next to the code, grant the humans and the CI runner, rescind anyone who leaves. No vault service to run, no console to babysit. We run our own infrastructure this way.
The situation
A small technical team has a prod.env, a couple of service keys, and a database password. The choices today are a dedicated secrets manager (another system to run, another bill, another set of IAM rules) or the thing everyone actually does: paste it in Slack and hope. What the team wants is for the secret to live where the code lives, readable by exactly the people and machines that should read it, and nobody else.
The recipe
- CLIBake the secrets file, granting the two engineers who own production and the identity your CI runner signs in as. Give it a time to live so access lapses on its own if nobody renews it.
# humans and the deploy machine, 90 day access
honeycake bake prod.env \
--grant priya.devops@co.com,marco.sre@co.com,deploy-runner@co.com \
--ttl 90d
🍰 Baked prod.env.cake (keys granted: 3, expires in 90 days) - GitCommit
prod.env.caketo the repository and addprod.envto.gitignore. The ciphertext is safe in a public or private repo; only the granted identities hold keys. - CIAt deploy time the runner authenticates as itself and Opens the secret straight into the pipeline, with structured output for scripts.
# in the deploy job
honeycake --output=json unbake prod.env.cake - PortalMarco leaves the company. Rescind
marco.sre@co.comin the Portal. The file in git does not change, the commit history does not change, and Marco's copy stops Opening. Change the secret itself on your normal schedule; Honeycake controls who can read it, and you control what it says.
What each reader sees
Production engineers
The plaintext prod.env, on their own machine, after signing in.
The CI runner
The same plaintext, headless, as JSON the pipeline consumes.
Everyone with repo access
An opaque .cake they can clone, diff, and never read.
Why it works
- Encryption happens on your machines. Honeycake never sees the secret, in plaintext or otherwise; our servers only decide who receives a key.
- Access is by identity, not by possession. Holding the file means nothing without a granted key, so the repo can be as open as you like.
- The same
bakedirautomation that runs a Vault can Bake an entire config tree on every change. See the CLI.