API keys and secrets
Keep private keys private while still using them in your app.
Some services need a private key: a mapping provider, an SMS gateway, an AI model. Those keys are dangerous in the wrong place, and easy to put there by accident.
The rule
A secret belongs on the server. Your browser code should never contain a key that can spend money or read private data. Anything that ships to the browser can be read by anyone who opens developer tools.
Adding a secret
Ask the builder to add a secret. It will give you a secure place to enter the value, never the chat itself. Then tell it the name of the key and what it is for:
Use the secret MAPS_API_KEY in a server function that returns
the driving distance between two postcodes.The key is kept on the server side and used only by server code. The app calls your own endpoint; the key is never sent to the browser.
What still counts as public
Some values are designed to be public and are safe in the browser:
- Your payment provider's publishable key
- Analytics identifiers
- Your project's public address
Knowing the difference is what matters. If a value would cost you money or expose someone's data, it is a secret.
When a key leaks
Rotate it. A leaked key is replaced, not hidden: create a new one with the provider, replace the stored secret, then revoke the old one.
Never paste a private key into the chat as part of a description. Add it as a secret and refer to it by name.
Common mistake to avoid
Building a feature against a test key and forgetting to change it before publishing. Before you go live, check that every connected service is using live credentials, and that the test ones are gone.
Was this page helpful?