GuidesOnly show guides for your app
GuidesGuidesTokens and connection strings belong in your server's .env, never in your repository — here's the workflow, and what to do if one slips out.
A bot token or a database connection string sitting in a public repository is a live key anyone can grab. The good news: keeping secrets safe on Falix takes about two minutes and one file. This guide is the whole workflow.
| At a glance | |
|---|---|
| You need | a project you deploy from Git (see Deploy from Git) |
| Plan | any |
| Time | five minutes |
Secrets never go in the repository. Not tokens, not connection strings, not API keys — and not even in a commit you plan to delete later.
⚠️ Heads up: Git remembers everything, so a secret that was ever committed is a secret you have to treat as leaked.
Three small pieces, and you're safe by default:
Ignore .env from day one. Add a .gitignore file containing a line that reads .env. Now Git won't track your secrets file even if you git add everything. (The Falix bot templates already ship a .gitignore with .env in it — one less thing to set up.)
Keep the real secrets only on the server. Put your actual token and connection string in the .env file on your Falix server — see Environment variables and secrets. Your code reads them from the environment, never from a hard-coded string:
process.env.DISCORD_TOKENos.environ["DISCORD_TOKEN"]Commit a .env.example instead. Put a placeholder file in the repo listing the keys with empty or fake values:
DISCORD_TOKEN=your-token-here
DATABASE_URL=mysql://user:pass@host:port/dbname
Anyone cloning the repo copies it to .env and fills in real values. It documents what your app needs without leaking anything.
Deploys on Falix copy files in and overwrite same-named files — they never delete files that aren't in the repo. Since .env is not in your repo, every deploy leaves your server-side .env exactly where it is. Your secrets live in one place, on the server, and code changes flow in over the top without ever touching them.
🎯 Good to know: The flip side — if you do commit a file named
.env, a deploy will overwrite the server's copy. Another reason to keep it ignored.
If a token or password ever landed in a repo — especially a public one — assume it's compromised the moment it was pushed. Deleting the commit is not enough; bots scrape public repos within minutes, and the value may already be copied. You have to invalidate the secret itself:
| Secret | How to invalidate |
|---|---|
| Discord bot token | Developer Portal → your app → Bot → Reset Token (the old one dies instantly), then paste the new one into .env |
| Database password | rotate it on the server's Databases page, then update the connection string in .env |
| Any other API key | revoke or regenerate it wherever it was issued |
For the database password, the Databases page walkthrough is in Add a database. Then, and only then, clean up the repo — remove the file and add it to .gitignore. Because a plain deletion still leaves the secret in your old commits, purging it from history takes a tool built for that job — git-filter-repo or the BFG Repo-Cleaner — rather than editing by hand. But resetting the secret is what actually protects you, so never skip it for the sake of a history rewrite.
Run git status (or check your Git host) and confirm .env is not among the tracked files, while .gitignore and .env.example are. Then look at your latest deploy: your app still reads its token, which means the server-side .env survived — as designed.
.env still shows up in Git — it was committed before you ignored it, and .gitignore only stops untracked files. Remove it from tracking, then rotate the secrets that were in it..env; reading process.env / os.environ only works if it's set there. See Environment variables and secrets.