This is the start of a series on exactly how Chattanooga.Digital was built — start to finish, with the real commands, the real recipe files, and the real trade-offs. The goal is that by the end you could rebuild a site like this one yourself, or fork ours and make it your own. We are, quite literally, giving away the recipes.

Before any code, this first post answers the question people ask first: why this stack? Three choices shaped everything that follows.

Why a CMS, not a framework

You can build a website by writing application code from scratch (a framework like Laravel, Rails, or Next.js) or by configuring a content management system (a CMS like Drupal or WordPress). The difference matters more than it sounds.

A framework hands you a blank page and a toolbox. Total control, and total responsibility — you build the content editing, the user accounts, the media library, the access rules, all of it. A CMS hands you a running site with all of that already built, and your job becomes modeling your content and arranging it. For a community organization that needs members, events, programs, and a blog — not a bespoke application — the CMS gets you to "useful" in days instead of months, and a non-developer can run it afterward.

Why Drupal, not WordPress

This is the choice with the most depth, and it comes down to how each system stores your content.

Picture how WordPress thinks about a piece of content. Almost everything is a "post" — a single big blob of HTML in one column, plus a bag of loosely-attached key/value metadata. It is wonderfully simple to start, and it works great for, well, posts. But the moment your content has structure — an event that has a start time, an end time, a location, and a recurrence rule; a member who has skills and interests; a program that links to its facilitators — you are stuffing structured data into an unstructured blob, or reaching for a pile of plugins that each invent their own way to fake structure.

Drupal thinks about content the opposite way. The core idea is the entity: a typed thing with typed fields. An "event" is its own content type with a real date field, a real location field, a real recurrence field. A "member" is an entity with real skills and interests fields. Because the fields are real and typed, Drupal can do things with them — sort events by date, filter members by skill, render a calendar, generate an iCal feed — without a plugin guessing at your intent.

The one-line version: WordPress stores content as a blob with metadata bolted on; Drupal stores content as entities with typed fields. For a site that is mostly articles, the blob is fine. For a site that is members + events + programs with relationships between them — which is exactly Chattanooga.Digital — the entity model is the difference between "fighting the tool" and "the tool doing the work for you."

Three honest caveats, because tribalism helps no one:

• WordPress's simplicity is a real strength for simple sites, and its ecosystem is enormous.
• Drupal's power comes with a steeper learning curve — the rest of this series is partly about flattening that curve.
• You can add structure to WordPress (custom post types, ACF). The difference is that in Drupal, structure is the default and the foundation, not an add-on.

Why Docker and Recipes, not click-ops

The last choice is about how we build, not what. We do not build this site by logging into an admin screen and clicking until it looks right. We build it two disciplined ways:

• Docker gives every developer (and the production server) the exact same environment — the same PHP, the same database, the same web server — defined in a file and started with one command. No "works on my machine."
• Drupal Recipes capture the site's structure — its content types, fields, views, menus, pages — as version-controlled YAML files. The site can be rebuilt from scratch, identically, from git. The configuration is code you can review, diff, and roll back.

Together these mean the whole site is reproducible: clone the repository, run a couple of commands, and you have Chattanooga.Digital running on your laptop. That reproducibility is the thing that makes a tutorial series like this one even possible — every post points at real files you can run.

What's next

Enough philosophy. In Part 1 we install the whole site on your own machine with Docker and watch it come up at localhost:8081 — the foundation everything else builds on.

Part 1: Install It in Docker →