Notes from three separate API environments
When an application uses an AI API, it is common to begin with one key and place it wherever the application needs access. That is convenient for a first test, but it creates problems as soon as the project has more than one environment.
A better habit is to use a separate Vana API key for each environment: one for development on your computer, one for staging or testing, and one for production. The environments may use the same endpoint and the same application code, but their access should remain separate.
§ What an environment means
An environment is a place where your application runs. Development is where you write and experiment. Staging is usually a copy of the application used for testing before release. Production is the live version used by real people.
These environments often have different settings. Development may contain temporary code and detailed logs. Staging may run automated tests. Production should be more restricted and carefully monitored. A separate key for each environment keeps these differences visible and manageable.
§ Why one key causes trouble
Suppose the same key is used by a local script, a staging server, and the live application. If the key is accidentally committed to a repository or printed in a log, you have to assume that every environment is affected. You may also have difficulty identifying where requests came from.
Separate keys reduce the size of the problem. If a development key is exposed, you can revoke and replace that key without interrupting the production application. Usage and token costs are also easier to understand because requests from each environment can be reviewed independently.
This matters with Vana API because requests are billed by the real number of tokens used, without a monthly fee. A test script that sends an unexpectedly large prompt should be distinguishable from normal production traffic.
§ A simple naming pattern
Choose names that describe the purpose of the key. For example:
- vana-development for local work
- vana-staging for pre-release testing
- vana-production for the live service
The name is for your own organization. The important part is that each environment receives a different secret value. Store the key in that environment's secret manager or environment variables, rather than placing it directly in source code.
§ Keep configuration outside the code
Your application should read the key from configuration. During development, this might be a local environment file that is excluded from version control. On a hosted service, use its secrets or environment-variable settings. Production secrets should be accessible only to the services that need them.
The code can then use the same Vana API integration in every environment while each deployment supplies a different key. Vana API provides an OpenAI-compatible endpoint and also supports the Anthropic Messages and Gemini native protocols, so the same separation principle applies regardless of which client style your application uses.
§ Rotate keys calmly
Keys should be replaceable without a rushed code change. Create a new key, update the relevant environment, verify that requests succeed, and then revoke the old key. Rotate a key immediately if it appears in a public repository, a shared screenshot, a client-side bundle, or an unexpected log.
Keep API keys on a server whenever possible. A key embedded in browser JavaScript or a mobile application can be extracted by anyone who receives that software. For a client application, send requests through your own backend and keep the Vana API key there.
§ A small setup worth keeping
For a new project, create the development key first and confirm that a small request works. Add a separate staging key before automated tests or team use. Create the production key only when the live deployment is ready, and give it to the production service alone.
That small separation makes debugging, billing review, and incident response much clearer. If you are ready to try the endpoint, create a Vana API account and begin with a development key before connecting a live application.