Contents8
A server installed three years ago has had a life: a package added during an outage one evening, a setting changed for a client, a service started by hand and never documented. It runs, and nobody could rebuild it identically. The day it disappears, rebuilding starts with an investigation. Infrastructure as code starts from the other end: the server is described in files, and it is the description you change, not the machine. It is one of the building blocks in our guide to the cloud infrastructure foundation.
In short
Infrastructure as code describes infrastructure in versioned files that are reviewed and can be replayed, instead of configuring it by hand.
Microsoft presents it as the answer to environment drift: “snowflake” servers, unique and impossible to reproduce.
For the business, it serves disaster recovery first, then traceability of changes and the freedom to change host.
Tools fall into layers: resources (Terraform, OpenTofu, Pulumi), machine configuration (Ansible, cloud-init), services (Docker Compose).
It rebuilds the machine, not the data: backups and a secrets vault remain essential.
What “infrastructure as code” means
Definition
Infrastructure as code
The practice of describing servers, networks, access rights and services in text files, stored in a repository like code, then letting a tool apply that description.
Microsoft sums up the principle in its introduction to infrastructure as code:
Just as the same source code always generates the same binary, an IaC model generates the same environment every time it deploys.
The same text names the problem it solves: without it, each environment becomes over time a “snowflake”, a unique configuration that can no longer be reproduced automatically. It stresses idempotence: a deployment command always brings the environment to the same state, whatever its starting point. And the method: to change something, the team edits the source, not the target.
What it changes for the business
The benefit is not technical. It shows in four situations every company eventually goes through.
- The lost server. Hardware failure, a mistaken command, a suspended account: with an up-to-date description, rebuilding follows a recipe instead of a memory. It is the “restart” part of the disaster recovery plan.
- The reviewed change. A change to the infrastructure takes the same path as a change to code: proposed, reviewed, applied, kept in the history. You know who opened which port, when, and why.
- The test copy. The same file creates a test environment identical to production, long enough to test an update, then deletes it.
- The way out. A described infrastructure moves more easily to another host: you know exactly what needs recreating. That helps in a cloud migration without breaking things as much as in thinking about dependence on American clouds.
The path of an infrastructure change
- The proposal
The change is written in the file.
- The review
Another person reads it, and the tool shows what will change.
- The application
The tool brings the infrastructure to the described state.
- The history
The change stays dated, signed, reversible.
System administrators do not disappear in the process: they are the ones who write the description, review it and decide what goes in. Their knowledge simply stops living in a single head.
The tools, layer by layer
No tool does everything. They are grouped by what they describe.
- Resources. Machines, networks, DNS records, storage accounts, at one or several providers. Terraform is the most widespread tool; OpenTofu is an open fork of it; Pulumi describes the same resources in a programming language. Each big cloud also has its own format, such as ARM templates and Bicep on Microsoft Azure or CloudFormation on AWS.
- Machine configuration. Packages, users, firewall rules, configuration files: Ansible applies these settings to one or more machines, cloud-init sets them on first boot.
- Services. On a server running containers, a Docker Compose file describes each service, its data volumes, its network and its restart policy.
Licensing matters in the choice, because it has already changed once:
- 10 August 2023
HashiCorp announces that its products, Terraform included, move from the MPL 2.0 licence to the Business Source License, which bars competing service providers from incorporating future releases.
- After the announcement
Several vendors create OpenTofu, a Terraform fork under the stewardship of the Linux Foundation, presented as a drop-in replacement.
A company using Terraform for its own infrastructure is not barred from carrying on. The choice between the two comes down to governance and supported providers, not fear of a lawsuit.
What it does not rebuild
Watch out
The machine, not the data
Infrastructure as code recreates an empty, well-configured server. CRM clients, invoices and files uploaded by users come from backups, and only from them. Passwords and API keys have no place in description files: they live in a vault, which the description references without containing them.
Rebuilding fast is useless if the data does not follow. Our guide to backing up your own server explains how to check that a restore really works, and our article on managed or self-hosted Postgres covers the database case. For secrets, see the secrets vault and stolen API keys.
What we learned
From the field
On 5 July 2026, a badly targeted clean-up command destroyed the containers of ten services on our server at once. The data, stored in volumes, was saved; our operating rules are now written down. The lesson: what is described and kept separate from the data can be rebuilt, what only lives on the machine is lost. The site you are reading applies the same idea: its hosting configuration, redirects and headers are files in its repository, and deployment refuses to go out if a page lives at a redirected URL.
Where to start, without rewriting everything
Nobody needs to describe their whole infrastructure in one go. The order that pays off fastest:
- Take stock.
Every server, every service, every DNS record, and where their data lives.
- Describe the services first.
One file per service, with its data volumes kept separate: that is what gets recreated most often.
- Then the machine.
Packages, users, firewall, reverse proxy, in a configuration tool.
- Test the rebuild.
On a fresh machine, with a real backup: the stopwatch tells you whether the recipe holds.
- Route every change through the description.
A change made by hand on the server is a debt; carry it into the files the same day.
The rest of the project
Infrastructure as code applies wherever you host (dedicated server, VPS or cloud) and does not require Kubernetes (when you do not need it). It makes the resources that cost money visible (what inflates a cloud bill), describes the proxy in front of your services (what Cloudflare protects) and goes hand in hand with monitoring that warns you before customers do. It also applies to self-hosted tools (n8n in production, which tools to move out of SaaS first, the three-year cost of leaving SaaS) and to AI servers (the hardware you need). Team access (a password manager), email (Google, Microsoft or a European host) and resilience obligations (NIS2 in France) complete the foundation.
Our self-hosted stack delivers your tools installed on a server of your own, with off-server backups whose restore has been tested and operating documentation: €5,500 and three weeks.
Frequently asked questions
Is infrastructure as code useful for a single server?
Yes, and that is often where it pays off fastest. A single server is a single point of failure: if it disappears, everything that ran on it has to be redone. Describing its services and configuration in files turns that rebuild into a known procedure, which can be tested in advance on a fresh machine. The gain does not depend on the number of machines.
Terraform or OpenTofu: which should we choose?
Both describe the same resources in the same language, OpenTofu having started as a fork of Terraform after the 2023 licence change. A company describing its own infrastructure can use either. The choice comes down to the project’s governance, the providers supported and the habits of the team or provider who will run it day to day.
Do we need to describe everything before starting?
No. Start with the services, with their data kept separate, then the machine configuration, then the resources at the provider. Each step has value on its own. What matters is testing the rebuild on a fresh machine from the first step, and then routing every change through the files rather than through the server.
Does infrastructure as code replace backups?
No. It recreates a configured but empty machine. Your tools’ data, such as customer records, invoices or uploaded files, only comes back from backups, provided a restore has been tested. The two work together: the description rebuilds the server, the backup restores its contents, and the recovery plan says in which order.
Sources
- Microsoft Learn, What is infrastructure as code? (new tab)learn.microsoft.com
- HashiCorp, announcement of 10 August 2023 (new tab)hashicorp.com
- OpenTofu, project website (new tab)opentofu.org
Jim · founder of Brain Plus AI
Also in infrastructure and cloud
Practical guide8 min
Disaster recovery plan: what has to be written down
The day a server, a data centre or an account disappears, it is too late to decide the order of things. What a disaster recovery plan must contain, the two figures management must set, and how to know it works.
Practical guide7 min
Backing up your own server: what really breaks
Everyone knows the 3-2-1 rule, but what loses data is more mundane: a backup never restored, a forgotten volume, a global clean-up command run in production. Here is what we learned from operating our own server.
Practical guide13 min The topic guide
Cloud infrastructure: the foundation for all your projects
Before the first project, a cloud infrastructure foundation settles accounts, access, backups and budget once and for all, and every later project inherits it. What it contains, where to put it, what it costs and why running it matters more than installing it.