I have a hobby app with an API key and a few environment-specific settings. Hardcoding them is clearly wrong, but adopting a giant secrets platform for a script only I run seems excessive. I'm considering a local `.env` file ignored by Git plus an example config showing required variables, with production values provided by the hosting environment. What beginner mistakes should I check before pushing the project to a public repository?
Handling configuration and secrets in a hobby project without enterprise-level tooling
- programming-help
- handling
- configuration
- secrets
17
0 replies
One more thing: keep a clean sample file with names and no values. It saves you later when you come back after a month and can’t remember wh...
One more thing: keep a clean sample file with names and no values. It saves you later when you come back after a month and can’t remember which setting was which.
2 replies
Make the app fail loudly if a required variable is missing. A vague fallback can be worse than no config because it hides the problem until...
Make the app fail loudly if a required variable is missing. A vague fallback can be worse than no config because it hides the problem until later.
Do you mean the app should stop at startup, or just show a warning? I’m trying to picture what “loudly” looks like without making local testing miserable.
Usually startup failure for required secrets, warning for optional settings. If the app can’t do its job without a value, don’t let it drift...
1 reply
Your .env plus example config plan is exactly the normal starting point for a hobby project. Biggest mistakes I’d watch for are committing t...
Your .env plus example config plan is exactly the normal starting point for a hobby project. Biggest mistakes I’d watch for are committing the real file, echoing secrets in logs, and leaving defaults that silently point at production.
Also check your editor backups and shell history. People remember the Git ignore file and then paste the key into a terminal once anyway.