Keep secrets out of Git

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.

The rule

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.

The workflow

Three small pieces, and you're safe by default:

1. 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.)

2. 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:

   • Node: process.env.DISCORD_TOKEN
   • Python: os.environ["DISCORD_TOKEN"]

3. 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.

Why this is safe on Falix specifically

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 secret already leaked

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:

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.

Verify it works

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.

Troubleshooting

• .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.
• App can't find its token after I removed it from the code — the value has to exist in the server's .env; reading process.env / os.environ only works if it's set there. See Environment variables and secrets.
• Is deleting the leaking commit enough? No — reset the token or rotate the password. A pushed secret is a leaked secret.

Next steps

• Environment variables and secrets
• Deploy from Git
• Your first Discord bot