Every New Project, the Same Provider Dance — Solved
New project API key setup means re-extracting 15 keys every time. How 1 command mints them all from your .env.example, scoped and value-free.
Rocco has done this dance a hundred times. He finally choreographed it into one command.
🦝 Rocco: same fifteen providers, same clicks, every repo. i got tired of the dance.
Every new project starts with the same provider dance — re-extracting the same 15 API keys from the same token pages, guessing the same scopes, pasting into the same .env files. Ringtail Keys ends it: a local, open-source, agent-led tool that reads your .env.example and mints every scoped key from the providers' official APIs in one command, value-free, straight into .env.local and Infisical.
What is the "provider dance," and why does it repeat?
The provider dance is the ritual you perform at the start of every repo: open Stripe, find "create key," pick scopes; open OpenAI, same; open Resend, Neon, Cloudflare, Vercel — same, same, same. The steps don't change between projects because the providers don't change; you're running an identical setup script by hand, in a browser, 15 tabs at a time.
The Twelve-Factor App's config principle tells you to keep every secret in the environment — good advice that quietly assumes you've already got the keys to put there. It repeats because the whole secrets tooling category solved the wrong half. Vaults and env managers got good at storing the keys you already have. Nobody automated getting them — the acquisition step stayed a manual chore, so you pay it in full on every new project. That's the half the dance lives in.
Why hasn't this been solved already?
Because "store the secret" and "acquire the secret" look similar but are different problems, and the market built for the first one. A vault assumes you've already minted the key by hand and just want somewhere safe to keep it. So it never touches the token-page raid — it starts one step after the tedious part ends.
Acquisition needs something a storage tool doesn't: it has to drive each provider's official key-minting API, pick least-privilege scopes, validate them, and know which variable each key belongs to. That's the gap Ringtail fills. For the honest storage-vs-acquisition breakdown, see Ringtail vs Doppler: acquisition versus storage.
🦝 Rocco: the vault is a great drawer. somebody still has to go get the keys. that was always me.
How does one command replace the dance?
Install the local daemon and point it at a repo:
curl -fsSL ringtail.sh | sh
ringtail up
Ringtail reads the variable names in .env.example as the choreography — STRIPE_SECRET_KEY, OPENAI_API_KEY, RESEND_API_KEY, and the rest. For each one, your coding agent drives that provider's official API to mint a scoped key, validates the scope on the spot, and writes the value to .env.local, syncing across dev, staging, and prod via Infisical. You approve one "allow" per provider the first time; after that it's zero-touch. The 15-tab raid becomes one command, and the secret values never pass through the model.
Because .env.example is the source of truth, the same manifest works on every project — see treating .env.example as a manifest — and the whole one-command provisioning flow is the same no matter how many providers you list.
When should you use this — and when not?
Use it when:
- You start new projects often and keep repeating the same provider setup.
- You want scopes right the first time, not debugged at runtime.
- You want the same keys, correctly scoped, across dev/staging/prod without hand copy-paste.
Skip it when:
- You need one key, once, for a throwaway script — the manual flow is fine.
- You want a hosted vault to store keys you already have — that's storage, not the dance.
- A provider has no key-minting API — Ringtail uses official APIs first and defers to a human login where none exists, never a bot with your credentials.
Isn't a boilerplate template or setup script good enough?
A template gets you the code, not the keys. A starter repo or a shell script can scaffold your .env.example, your folder structure, your dependencies — but it can't mint a live Stripe key or a scoped Cloudflare token, because those require driving each provider's real API with your consent. So the template hands you a fresh repo and the dance still starts: 15 empty variables waiting to be filled by hand.
| Ringtail (one command) | Boilerplate template | |
|---|---|---|
| Scaffolds project structure | No (that's your template's job) | Yes |
| Mints live scoped keys | Yes — from .env.example | No — variables left empty |
| Validates scopes | Yes, on mint | No |
Fills .env.local per env | Yes — synced | No — you paste each one |
| Repeats effort per project | One command | Manual key raid every time |
The template and Ringtail are complements: the template gives you the manifest, Ringtail fills it. That's why the dance survived the boilerplate era — nobody automated the part that touches real providers. For letting a coding agent run the whole thing safely, see how to give a coding agent API keys without leaking them.
Does this work when providers change between projects?
Yes — the manifest drives it, so the dance adapts automatically. If one project needs Neon and another needs Supabase, you just list the variables you actually use in each .env.example, and Ringtail mints exactly those. There's no fixed list baked into the tool; the shopping list is whatever your project declares. Change providers, change the manifest, and the one command still does the whole raid.
FAQ
How do I stop repeating API key setup on every new project?
Automate the acquisition step. With Ringtail Keys, you point the tool at your project's .env.example and it mints every scoped API key from the providers' official APIs in one command — value-free, straight into .env.local and Infisical. Instead of re-raiding 15 token pages by hand on each repo, you run one command plus a single "allow" per provider the first time.
Why does every new project need the same API keys again?
Because most projects use the same core services — a database, auth, email, payments, an LLM, a CDN, a host — and each key is minted per project for least privilege. Existing vaults only store keys you already have; they don't acquire them, so the manual token-page setup repeats. Ringtail closes that gap by minting the scoped keys for you from the manifest.
Can a boilerplate template handle API keys for me?
No — a template scaffolds your code and an empty .env.example, but it can't mint live keys, because that requires driving each provider's real API with your consent. Ringtail complements a template: the template gives you the manifest, and Ringtail fills it with scoped, validated keys value-free.
Does Ringtail adapt when I use different providers?
Yes. Ringtail reads whatever variables your .env.example declares, so the set of providers it mints from is exactly what each project lists — swap Neon for Supabase, add Cloudflare, drop Vercel, and the same one command still provisions precisely those keys.
How do I run the one-command setup?
Install with curl -fsSL ringtail.sh | sh, then run ringtail up to start the local daemon. Point your coding agent at a repo's .env.example, and it mints each scoped key via official APIs, value-free, writing values to .env.local and Infisical. You approve one "allow" per provider the first time; after that it's zero-touch on every project.