Infrastructure as code: why we write the setup down
What it means to define hosting, DNS and configuration in files rather than clicking through dashboards, and why that protects the business that owns them.
The short answer
Infrastructure as code means that the way your website is set up, the hosting project and its build settings, the redirects, the security headers, the environments, the DNS records, the names of the secrets and where they live, is written in files in the repository rather than clicked into dashboards and remembered by a person. Written setup has the same properties as the site’s code: it is versioned so every change has a record, reviewed before it takes effect, reproducible on a fresh account in minutes, and reversible when a change turns out wrong. It is also documentation that cannot drift from reality, because it is the reality. For a small business the practical consequences are that a partner can be replaced without archaeology, an environment can be rebuilt after a disaster from the files, and nobody has to remember which setting was changed in 2024 and why. The dashboard is for looking; the files are for changing.
Clicked versus written
| Aspect | Setup clicked in dashboards | Setup written in files |
|---|---|---|
| Record of changes | The dashboard’s audit log, if any | Every change, author, reason, in the repository |
| Review before change | None | Reviewed like code, previewed where possible |
| Reproducing on a new account | Hours of remembering and screenshots | Minutes from the files |
| Recovering after a provider failure | Start from scratch | Apply the files elsewhere |
| Handing over to a new partner | Walk-throughs and guesswork | Read the files |
| Documentation accuracy | Drifts from reality within months | Is the reality |
| Auditing | Screenshots of settings | The files themselves |
| Undo | Remember the previous value | Revert the change |
What we write down
- Hosting project configuration: build command, output, framework settings, regions, function settings.
- Redirects and rewrites, including the migration map.
- Security headers and the content security policy.
- Environments and which variables each expects, by name, with values in secret storage.
- DNS records, as a file that can be applied to the provider, or at minimum an exported zone kept current.
- Third-party configuration that matters: the email sending domain setup, the analytics setup, the form endpoints.
- Dashboard-only settings, documented with date and reason where a provider offers no file-based way.
What it means for ownership
Ownership of a website is more than the code: it is the ability to run it somewhere else without the current partner. Code in your repository is half of that; setup in your repository is the other half. Together they are what makes the hand-over promise real rather than a sentence in a contract.
What this means for you
Insist that your site’s setup, hosting configuration, redirects, headers, environments and DNS, is written in files in your repository alongside the code, with only the unavoidable dashboard settings documented separately. It costs little at build time and gives you a versioned, reviewable, reproducible description of your own infrastructure, which is what lets you replace a partner, recover from a disaster or answer an audit without depending on anyone’s memory.
Frequently asked questions
Is this not overkill for a small website?
The scale is small and so is the effort: a handful of configuration files describing the hosting project, the redirects, the headers, the environment variables' names and the DNS records. Writing them takes little longer than clicking, and afterwards every setting is visible, versioned and reproducible. The value shows the first time something must be rebuilt, audited or handed over, which happens to every site eventually.
What do we as the business get from it?
A complete, current description of how your site is set up, in your repository, readable by any competent partner. If your partner disappears, the next one reads the files and reproduces the setup. If a provider fails, the same files rebuild it elsewhere. If an auditor or an enterprise client asks how things are configured, the answer is a file, not a memory.
Does it cover everything?
Most things: hosting configuration, redirects, headers, build settings, environments, DNS records, and the names and locations of secrets, though never their values. A few provider settings can only be set in a dashboard; those are documented in a file next to the rest, with the date and the reason, so nothing lives only in someone's head.