Stop pasting your .env into Slack.
My App Secrets will be one place to keep, share and sync an app's environment variables across your machines, your teammates and your servers. It does not exist yet. Tell us you want it.
here's the staging .env, don't share
APP_KEY=base64:xxxxxxxxxxxxxxxx
DB_PASSWORD=hunter2hunter2
STRIPE_SECRET=sk_test_xxxxxxxx
MAIL_PASSWORD=xxxxxxxxxxxx
- APP_KEY••••••••
- DB_PASSWORD••••••••
- STRIPE_SECRET••••••••
- MAIL_PASSWORD••••••••
The .env file is the one file nobody has a good home for.
-
Secrets end up in chat and email
A teammate needs the staging keys, so the whole file gets pasted into a thread. It stays there, searchable, long after the keys should have been rotated.
-
Every machine has a slightly different copy
Your laptop has one version, the server another, and the new hire's copy came from a message three weeks old. Nobody knows which one is right.
-
No record of who changed what
A value changes on production and something breaks. There is no history to read, no diff to look at and no one to ask.
How it would work
The plan, in the order you would use it. None of this is built yet.
-
Keep each app's variables per environment
Every app would have its own vault with a separate set of values for local, staging and production. The same key, a different value in each.
secrets init lanternbox -
Invite teammates
You would invite people to an app, not hand them a file. Access could be limited to the environments they actually work in.
secrets invite teammate@example.com --env staging -
Pull a fresh .env with one command
On any machine, one command would write a current .env for the environment you pick. Values would stay masked in your terminal.
secrets pull --env staging -
Push to your server
The same command would run on a server, so a deploy could fetch its variables instead of someone editing a file over SSH.
secrets pull --env production -
See a history of changes
Every change would be recorded: which key, which environment, who changed it and when. Old values would stay masked unless you ask.
secrets history --env production
What it might look like
Two sketches of the idea. The app names are made up and every value is fake.
~/code/lanternbox $ secrets pull --env staging
Fetching staging for lanternbox
7 variables written to .env
APP_ENV=staging
APP_URL=https://staging.lanternbox.example
APP_KEY=base64:••••••••••••••••••••••••
DB_PASSWORD=••••••••••••
STRIPE_KEY=pk_test_xxxxxxxxxxxx
STRIPE_SECRET=sk_test_••••••••••••
MAIL_PASSWORD=••••••••••
~/code/lanternbox $ lanternbox
- local
- staging
- production
| Key | Value | Changed |
|---|---|---|
| APP_KEY | base64:•••••••••••• | you2 days ago |
| DB_PASSWORD | •••••••••••• | you2 days ago |
| STRIPE_KEY | pk_test_xxxxxxxx | a teammate1 week ago |
| STRIPE_SECRET | sk_test_•••••••• | a teammate1 week ago |
| MAIL_PASSWORD | •••••••••• | you3 weeks ago |
History
- DB_PASSWORD changed on staging2 days ago
- STRIPE_SECRET rotated on staging1 week ago
- teammate invited to staging1 week ago
Questions
- Does it exist yet?
- No. This page describes an idea and collects the email addresses of people who would use it. Nothing is built yet, and there is no launch date.
- Is it for Laravel?
- It is being designed with Laravel developers in mind, but it would work for any app that reads a .env file: PHP, Node, Python, Rails or anything else.
- Where would secrets be stored?
- Encryption is the first design question and it has not been answered yet. There are no promises about where values would live or how they would be protected until that work is done.