In multi-tenant SaaS systems, configuration eventually becomes part of the product itself. Tenant rules, workflow mappings, pricing behavior, routing logic, UI controls, over time these “configs” quietly become production-critical code. Yet many teams still store them in databases and allow direct edits in production on releases or on informal requests.
From my experience, that model creates anxiety.
Someone changes a value directly in a table. Nobody knows who changed it, why it changed, or what exactly the previous state was. Audits exist, but database audits rarely feel natural to engineers. They’re fragmented, harder to review, and disconnected from normal development workflows.
That’s why I started preferring a CaC mindset: Configuration as Code.
Not secrets. Secrets belong in proper secret managers. But operational and business configuration should live in versioned files, committed to Git, reviewed through pull requests, and deployed through pipelines just like application code.
This is also distinct from feature flags. Feature flags are intentionally dynamic, frequently toggled, and often owned by product teams. Configuration is different. It defines long-term system behavior.
The advantages are surprisingly practical:
- Every config change is reviewable
- Environments stay reproducible and most importantly predictable
- Engineers stop “hot-fixing” production tables
- Rollbacks become trivial
- History is permanent and searchable
- Tenant-specific behavior becomes explicit instead of tribal knowledge
Most importantly, it creates calmness within engineering teams. Nobody silently edits production state anymore. The system becomes predictable.
While GitOps is standard for infrastructure, we need to apply that exact same philosophy to business and tenant configuration: a paradigm we can call Configuration as Code (CaC).
Use YAML, JSON, or any structured format that fits your system. Design folder structures around domains, tenants, environments, or ownership boundaries.
For large-scale systems, keeping configuration in a separate repository can work even better. Pull requests remain isolated, review ownership becomes clearer, and configuration evolves independently from application deployments.
Even legacy systems that rely heavily on database-driven configuration still have a practical migration path. The database can remain, but only as a deployment target and not the source of truth.
Store configuration in files, then use CI/CD pipelines to reconcile and overwrite database values automatically. At that point, direct human write access to configuration tables should ideally disappear entirely.
Git repo → PR → CI/CD → Config Sync → Database/Application
Configs deserves the same engineering discipline as code. Versioning, reviews, approvals, traceability, and reproducibility should not stop at the application layer.
Top comments (0)