The repository is public and the secrets are not

Local development needs real credentials for the services the project integrates with. CI needs its own for publishing and releases. Neither may ever appear in the repository, and the repository is where all the work happens.

The margin for error is thinner than in a private project: a public push is scanned within minutes, and history rewrites are far more disruptive when other people have clones.

What breaks

1. A public accident is immediate and permanent

   There is no window in which you can quietly fix it. Assume anything pushed to a public repository has been read, and rotate rather than delete.

2. Contributors need a working setup without your keys

   A contributor has to be able to run the project, which usually means documenting a .env.example and hoping nobody fills it in and commits it.

3. Local and CI credentials get muddled

   The token that publishes releases has no business being on a laptop, and the local development key has no business being in CI, but both live in the same conceptual bucket of "the secrets".

How it works here

1. Nothing to commit

   Local credentials live in the vault, outside the working tree, so there is no file in the repository for git add -A to catch.

2. Generate .env, keep .env.example in the repo

   The committed example documents the variable names. The real file is generated when you need it and deleted when you do not.

3. CI secrets go to CI

   The GitHub Actions export emits the commands to set secrets in the repository’s own secret store, which keeps release credentials where they belong instead of on anyone’s machine.

4. Separate projects for separate scopes

   Local development and release automation are separate projects with separate keys, so the distinction is structural rather than a matter of remembering.