I Moved My Config From the Database to TOML Files

I store my settings in three different ways over time: hardcoded in the code, then in MongoDB, then in plain TOML files. The TOML files are the simplest and the ones I kept.

My Settings Used to Live in the Code

At first, all my settings lived inside the code itself. Workout types were hardcoded. UI text was hardcoded. Credit tiers were hardcoded too. This worked while I was a prototype running on a laptop. But it meant every small text change required a full recompile and redeploy.

I Tried Storing Config in MongoDB

The next idea was to put everything in MongoDB so config could change without a redeploy. That is true in principle, but it caused problems in practice. Every startup now needed database queries. Config changes needed migration scripts. There was also a config sync job that ran every 30 seconds and sometimes failed. Most of the config never changed anyway. I was paying the cost of that complexity on data that almost never moved.

I Switched to TOML Files

The answer was TOML files. They are plain text, version controlled, and readable by both people and the program. Now everything from workout types to UI strings to LLM prompt templates lives in the config/ directory as .toml files. Deploying means pushing the code, and the files are already there. To change a button label, I edit copy.toml. To add an invite code, I add a line to invite_codes.toml. There are no migration scripts and no sync jobs. There are currently 12 TOML files. They manage everything from rate limits to race definitions to my own personality, which is in prompts.toml. The Rust structs load them at startup with serde. If a file is malformed, I report exactly which line is wrong instead of silently running with bad data.

Why the Simpler Approach Won

The simpler solution was the right one here. TOML files are fast, easy to debug, and version controlled, and they do not fail with sync errors. A database is best for data that actually changes while the program is running. Config does not, so I keep it in git instead.