Storing Web App Configuration: Disk or DB?

Caleb Brown

As a web developer I've struggled for a while trying to decided where the best place to store the configuration of the applications I'm developing.

Initially I thought a configuration file stored in revision control with the application's source code would be the most appropriate technique.

But it gets complicated when you have to account for multiple development, staging and production environments. Do you stick them in separate files and rename them depending on the environment, or do you stick them in the one file and use conditions to figure it out?

And what if we have to make a small change to the production configuration? Doing that would require another release.

That meant while the configuration file was stored in revision control it was a mess, and getting updates pushed live was slow and cumbersome.

So my thinking changed. Perhaps the database would be a better place to store configuration information. While I lost the handy revision control, I gained better site independence and could update settings whenever appropriate. I even get a pretty admin interface to play with. This is what Drupal and many other user-friendly web apps like to do.

However keeping the configuration outside revision control means that it's only a matter of time before something gets screwed up badly. In the database it's very hard to tell which settings have been changed, when they changed, or why they changed. And if we need to setup a new website the configuration has to be done all over again.

But there is a better way.

Since adding revision control to the database is difficult at best, we need to put the configuration into files again. But this time we're not going to make a big mess by keeping it in revision control with the application. This time we'll keep the environment specific configuration in it's own special place. Either an independent branch, or it's own independent repository.

Updating the configuration is now simply a matter of updating it in it's own branch or repository, committing it, testing it and then moving it out to the appropriate environment.

Doing it this way keeps the configuration files nice and clean, changes to the configuration are tracked, and it can be updated independently from application releases. Perfect.

To make life even easier, I would suggest keeping any default configuration in a different place or in a file with a different name to the actual configuration file (e.g. config.default.php for config.php), so upgrading the application doesn't destroy the configuration.

And finally, use a configuration management tool, like cfengine or puppet, if you're deploying your application out onto a cluster.