Keep credentials in data, not config

A deploy that might invalidate your API keys is a deploy you'll hesitate to run. That hesitation is a smell, and the cause is usually that secrets are living in the wrong place.

When API keys are baked into configuration files or app settings, every deployment risks disturbing them, and rotating one means a config change and a release. When they live as rows in a database — stored hashed, never in plaintext — deploys stop touching them entirely. The code that validates a key reads the table; shipping new code doesn't rewrite the table. A key keeps working across any number of deployments, and the only things that revoke it are the explicit actions you take: flipping a revoked flag, deleting the row.

That separation buys two things. Deploys get less scary, because the credential surface is simply out of their path. And revocation gets instant and precise — one row, one kill switch, no release required.

The principle generalizes past API keys: state that needs its own lifecycle — created, rotated, and revoked on its own schedule — belongs in data you can mutate at runtime, not in config you can only change by shipping.