If a Bolt-generated app has an API key written into source, treat that key as compromised the moment the project was shared or pushed. Rotate it first, then clean up the history, then move it to an environment variable. Fixing the code without rotating the key leaves you exposed.
Why it's a problem
A hardcoded key in an exported or deployed Bolt project is readable by anyone with the code, and if it reached a public repo it has almost certainly been scraped already. Any key that costs money or reaches a database is a direct liability while it stays live.
How to fix it, in order
- 1Rotate the key at the provider. Revoke or regenerate it before touching anything else. This is what actually invalidates the leaked copy.
- 2Check the provider's logs. Look for usage you did not create. Treat unexplained activity as an incident.
- 3Remove it from the code and history. Delete the inline value, and if it was committed, purge it from git history with filter-repo or BFG and force-push.
- 4Read the new key from the environment. Store it in a gitignored .env and read it via import.meta.env or process.env depending on your stack.
Why Bolt does this
Bolt generates a full working app from a prompt, and the fastest way to make an integration work in that generated code is to place the key inline. It runs immediately in the preview, so the hardcoded key survives into the export unless you move it.
Stop it happening again
After exporting a Bolt app, do a pass for inline secrets before you push. Move every key to an environment variable, confirm .env is gitignored, and install a gitleaks pre-commit hook so a hardcoded key cannot be committed again.
The quick fix
- Rotate the key first.
- Check provider logs for unauthorized use.
- Purge from git history if committed.
- Move the key to a gitignored .env and add a pre-commit secret scanner.