monkeys
Concepts

.monkeys

A project lists the keys it needs once, in a .monkeys file next to the code. It is the secret half of .env.example: the list of what the program reads, with…

A project lists the keys it needs once, in a .monkeys file next to the code. It is the secret half of .env.example: the list of what the program reads, with nothing it reads in it. Commit it.

Format

+foo
@test,production
DATABASE_URL
STRIPE_SECRET_KEY
@production
SENTRY_DSN
linemeaning
+foothe namespace, first and at most once
@test,productionopens a block for one profile or several
DATABASE_URLa key, belonging to every profile of the block above it
# ...a comment

The first profile mentioned is the default. A key listed twice for one profile, a key before any @ line, or a name that is not a key is refused with the line quoted.

Where it is looked for

From the current directory upward, nearest first, stopping at the root of the git checkout, so a file above the checkout is never read. Outside a checkout only the current directory counts. Where no file is found the commands take keys on the line, as they do anywhere else.

What it replaces

The twelve-factor habit of a .env that is never committed, a .env.example that lists the same keys again by hand, and a .gitignore line that keeps the two apart. .monkeys is one file, it is committed, and the secrets are somewhere a repository cannot reach.

Who writes it

You, or unpack, which writes it at the root of the checkout from a bundle. doctor reads it whole and says what each profile still lacks.

On this page