A while back I was building a side project that needed five different API keys before anything would work. One for the language model. One for sending notifications. Two for posting to social platforms. One for the database. Five secrets, minimum, just to see if the prototype did anything useful.
I refused to put any of them in a .env.local file.
Instead, I built a settings page right into the app. Whoever uses it — me when I'm testing, or anyone I send the link to — drops in their own keys right there in the running app. No editor, no config file, no "did I forget to restart?" moment.
Here's why this is the workflow I keep coming back to, and when it's the right shape for what you're building.
The slow way: config files
When you spin up most AI prototypes, the default workflow looks like this:
- Open your code editor
- Find the
.env.localfile - Paste your API key there
- Save the file
- Restart your dev server
- Hope it worked
Want to swap from Claude Sonnet to Haiku for a quick test? Edit the file, save, restart. Want to try with a different key for an hour? Edit, save, restart. Want a designer on your team to play with the demo? Walk them through editing a config file in a code editor they don't know how to open.
It's not broken. It's just slow. And it requires being a coder.
The faster way: a settings page in the running app
What if your app had its own little settings panel — like the Preferences in a tool you use every day? Type the key, save, the app uses it. That's the whole pattern.
Roughly, a settings page like that looks something like this:
Same idea for any app you build. Every key the app needs has a field. Type it. Save it. The app uses it on the next call. No editor, no restart.
When I want to test with a different Claude key, I open the settings page and paste a new one. When I want to swap from Sonnet to Haiku, I change a dropdown. When a friend wants to try the tool, I send them the URL — they paste their own keys, and the app works against their accounts.
The iteration loop goes from "edit file → save → restart → test" to "paste → click → test." Same code, just configured while it's running instead of before it starts.
Is this safe?
It depends on two things: whose key is being pasted, and where the key gets used from.
Whose key
If it's the user's own key — they pay the bill, they control the account — this pattern is increasingly standard. Cursor, OpenRouter playgrounds, most AI tinkering apps work this way. The user types their key, they own the cost, you ship the tool.
If it's your app's own production key — the one that bills your account every time any user makes a request — never. That belongs in proper environment variables locked down on your server, where the browser can never see it.
The mental rule: whose pocket does the API call come out of? If it's the user's, a settings page is fine. If it's yours, never.
Where it gets used from
There are two ways the key can flow once it's pasted:
Straight from the browser to the AI. Your browser remembers the key, your browser calls the AI service directly. Simplest to build. The catch: the key is visible in the browser's network log on every call — there's no hiding it. Fine for personal dev tools and BYOK demos where the user knows it's their key, in their browser, against their account.
Through your own backend. Your browser remembers the key, your browser sends it to your own server, your server makes the call to the AI. The key still lives in the browser, but it's not floating around in network responses. Slightly more to build, much better security profile. This is the approach I usually take when I care.
Most "is BYOK safe?" articles miss this distinction. The architecture matters more than the pattern.
When the keys live in a settings page instead of a config file:
- Change anything in seconds. New model, new prompt, new provider. No rebuilds.
- Test with different keys without editing. Personal key vs work key vs free-tier key. Just paste.
- Hand the URL to anyone. Friend, workshop participant, designer on your team. They paste their own key and the app works against their account.
- No more "did I commit my .env?" panic. There's nothing to commit.
- Non-coders can use your tool. No terminal, no config file, no code editor.
It's not free. The honest tradeoffs:
- If the key lives in the browser, it's exposed. Anything running on your page can read your browser's local storage — your own code, a chat widget, a compromised library. A single bad script leaks the key. Storing it on your own backend (encrypted) is the safer alternative.
- If you take the simple route (browser talks straight to the AI), the key is on display. Anyone who opens their browser's developer tools and watches what's being sent can read it. That's just how browsers work — they don't hide what they're sending.
- Won't pass an enterprise security review. Big buyers want audit logs (who used which key when) and security certifications. BYOK in a settings page has neither. Fine for personal tools; not for selling to a bank.
- The work lands on your user. They have to find the key in their account, paste it in, and remember to update it when it expires. Fine for a prototype. For paying customers, it's friction a competitor will use against you.
- Keys you can see leak in ways you didn't plan for. Screenshots. Screen recordings sent to support. Screen-share videos. A key visible in an input field shows up in all of them. A key tucked away in a config file at least stays hidden.
When to use this pattern
Prototypes. Personal dev tools. BYOK demos. Workshops. Anything where the key belongs to the user and the stakes are low-to-medium.
Production apps that use your company's keys. Anything an enterprise customer is paying for. Anything that needs an audit trail.
The rule, because it's the whole article in one line: it depends whose key it is.
So for the way you actually build and test AI tools — that quick afternoon iteration loop, the demo you want to send a friend, the prototype you want a designer on your team to play with — try this: open the app, paste the key, see if it works.
You'll never go back to editing config files.