Provision a New Project's API Keys in One Command
Provision all 15 of a new project's API keys in one command: point Ringtail at your .env.example and it mints every scoped key, value-free, into .env.local.
Rocco set up the whole project while the coffee was still brewing. All fifteen keys. One command.
🦝 Rocco: one command, fifteen keys, correct scopes. you make coffee, i make the raid.
To provision a new project's API keys in one command, point Ringtail at your .env.example after starting the daemon. Ringtail Keys is a local, open-source, agent-led tool that reads every variable in .env.example, mints each scoped key from the providers' official APIs, and writes the values to .env.local and Infisical — value-free, so the secrets never touch your coding agent or any model.
What does "provision in one command" actually mean?
It means the whole setup collapses into a single flow you kick off once, instead of a fifteen-tab afternoon. The command is the install-and-start; from there your coding agent reads the .env.example manifest and works it top to bottom — minting, scoping, validating, and writing each key. You're not clicking through token pages one at a time; you're approving one "allow" per provider and letting the raid run.
"One command" is the honest description of the ergonomics, not a claim that a machine logs in as you. Where a provider exposes a key-minting API, the agent drives it directly. Where one doesn't, you handle that login in a guided step. The point is that the repetition — the same 15-key dance on every new repo — is gone.
🦝 Rocco: the dance is always the same fifteen steps. so i learned the dance. you don't have to.
How do you provision a new project with Ringtail?
Install Ringtail and start the local daemon, then point your agent at the repo:
curl -fsSL ringtail.sh | sh
ringtail up
ringtail up starts the local daemon. Your coding agent (Claude Code, Cursor) reads the project's .env.example, and for each variable it drives the provider's official API to mint a least-privilege key, validates the scope on the spot, and writes the value to .env.local and Infisical across dev, staging, and prod. You approve one "allow" per provider the first time; after that it's zero-touch. The values land in your files — they never pass through the model.
For why the .env.example is the right input, see .env.example is a manifest. For the pain this replaces, see how to stop juggling 15 API keys.
What does one-command provisioning give you?
Everything the manual flow does, minus the manual part — and with a couple of properties you'd rarely get by hand:
| What you get | By hand | One command (Ringtail) |
|---|---|---|
All keys from .env.example | Copy-paste each, per provider | Minted in one flow |
| Correct scopes | Guessed, checked at runtime | Least-privilege, validated on spot |
| Multi-env setup | Repeat for dev/staging/prod | .env.local + Infisical, all envs |
| Agent involvement | You do it manually | Agent orchestrates, value-free |
| Time to first run | An afternoon | About as long as coffee |
The multi-environment part is the quiet win: provisioning by hand means doing the whole thing three times, once per environment, which is where drift creeps in. One flow that writes all three keeps them consistent.
When should you use Ringtail? (and when not)
Use Ringtail when:
- You spin up new projects often and are tired of re-extracting the same keys by hand.
- You want a coding agent to set up infra without ever seeing secret values — see why your agent shouldn't see your API keys.
- You want least-privilege keys minted correctly the first time.
- You want the setup to also cover rotation that doesn't break production later.
Don't reach for Ringtail when:
- You want a hosted vault to store secrets you already have — Ringtail acquires keys, it isn't a storage console.
- You need an enterprise compliance and governance suite.
- A provider offers no key-minting API. Ringtail uses official APIs first; where one is missing, it falls back to a guided flow where a human handles the login — never a bot acting with your credentials.
FAQ
How do I provision all my API keys for a new project at once?
Point Ringtail at your project's .env.example after running curl -fsSL ringtail.sh | sh and ringtail up. Your coding agent reads every variable as a manifest, mints each scoped key from the provider's official API, validates it, and writes the value to .env.local and Infisical across environments. You approve one "allow" per provider; after that the whole batch runs zero-touch.
Does one-command provisioning mean a bot logs in as me?
No. Where a provider exposes a key-minting API, Ringtail drives that official API directly. Where a provider has no such API, Ringtail falls back to a guided flow where you handle the login yourself — it never runs a bot with your credentials. "One command" describes the ergonomics of kicking off the whole flow, not a machine impersonating you.
Where do the provisioned keys end up?
Ringtail Keys writes each minted key to your own .env.local and to Infisical, across dev, staging, and prod. There's no Ringtail server in the path — it runs locally and is open source — so the values live only in files you control. The provisioning is value-free, meaning the secrets go straight into those files without passing through your coding agent or any model.
Can a coding agent do this without seeing my secrets?
Yes. The agent orchestrates the provisioning — deciding which keys to mint and how to scope them from .env.example — while each provider's official API returns the secret straight into your .env.local and Infisical. The agent handles names and scopes, never the key strings, so letting it provision a new project doesn't expose your values.