Env and Config Generator for AI Apps
Pick the features your app has and take away an .env.example, a validating config loader, and an audit of the .env you already have.
5 required, 18 with a default, 2 that must come from a secret store rather than from a file.
- Providers configured
- 2
- Required variables
- 5
- Optional variables
- 18
- Secrets
- 2
- Variables missing from the .env you pasted
- —
- Values that look like live credentials
- —
REPLACE_ME, replace-with-a-model-id — because a generator that emitted a plausible-looking key would eventually have one committed. Everything on this page runs in your browser. Nothing you paste or open is uploaded, logged or sent anywhere.The reason to lift these values out of the code is not tidiness, it is that every one of them is something you will want to change without a release: the model id when a better one appears, the token ceiling when the bill arrives, the timeout when the p99 moves. The reason to validate them at startup is that the alternative is discovering a missing key when a user hits the feature, which is both later and quieter than it should be.
The two variables that are not like the others
MAX_OUTPUT_TOKENS is the only line that bounds what a single request can cost, and it is usually left at whatever the SDK defaults to — which is generous, because the SDK does not know what your feature does. A daily cost cap is the only line that bounds what a loop can cost; without it a retry storm against a large prompt runs until someone reads a dashboard. Both are cheap to set and are the two most common items missing from a config that later needed an incident write-up.
Prompts are user data
LOG_PROMPTS defaults to false here on purpose. Prompt text contains whatever your users typed, which in most jurisdictions makes your log aggregator a processor of personal data. Turning it on for a debugging session is reasonable; leaving it on is a decision that should be made deliberately, by someone who knows it was made.