Repeatable Systems Instead of Snowflakes: Infrastructure as Code for SMEs

The Tuesday Nobody Knew the Server

At a mid-sized logistics service provider in the DACH region, operations have been running on the same virtual servers for eight years. Thirty-eight employees, regional logistics software, twelve virtual machines spread across two cloud providers. Managing director Markus carries the IT decisions but has no dedicated DevOps team. Klaus Hartmann, the system administrator, manages all servers and works four days a week. Sarah Lenz, an external developer, deploys new software versions — and depends entirely on Klaus.

One Tuesday in July, a critical security alert arrives for the database in use. The patch requires restarting the staging environment to test compatibility with production. Klaus is on holiday. Markus asks Sarah whether she can rebuild the staging environment. Sarah logs in, finds four servers that should all look "more or less the same", but none has up-to-date documentation. The nginx configuration on staging diverges from production — a manual tweak from last autumn that only Klaus knew about. The firewall rules are not versioned. The SSL certificate chain was assembled by hand at the time.

After three days of reverse engineering, the staging environment is half-heartedly restored. A customer demo has been postponed. The team has invested four person-days in manual trial and error — and nobody is sure whether the environment is truly identical to production.

This Tuesday is not an isolated incident. It is the logical consequence of infrastructure that is not documented, not versioned, and not reproducible. For SMEs with 10 to 100 employees and no dedicated platform team, this is the normal state — and it becomes more expensive the longer it persists.

What Infrastructure as Code Really Means — And What It Does Not

Infrastructure as Code sounds like enterprise jargon. In conference talks it is often about Terraform providers, Kubernetes operators, and GitOps pipelines at global scale. For a mid-market business with half a system administrator, that sounds abstract and out of reach.

That is a category error. Infrastructure as Code is not an enterprise luxury. It is the technical implementation of an operational foundation that every organisation running on servers needs: The ability to rebuild the entire environment from a defined, versioned source.

This ability rests on three pillars:

Declare. Instead of configuring a server step by step manually, you describe the desired state in a file: which packages are installed, which services are running, which ports are open, which users exist. The goal is not a script that "somehow works". The goal is a description that says: "This is what this server should look like."

Version. This description lives in Git. Every change is a commit. Every commit has an author, a timestamp, and a review process. If something goes wrong, you can restore the previous state — not from a backup drive, but from a known, tested code revision.

Automate. An automation tool applies the declared configuration. Ansible for operating-system and service configuration. Terraform or Kubernetes manifests for cloud resources and containers. GitLab CI as the execution and review layer. The decisive difference from manual clicking: The tool ensures that the actual state matches the declared state — and reports deviations.

The MarketsandMarkets analysis of the IaC market shows that the global IaC market is expected to grow from USD 0.8 billion in 2022 to USD 2.3 billion by 2027 — with the SME segment growing faster than large enterprises. Precedence Research updates this forecast to USD 9.40 billion by 2034. The signal is clear: smaller organisations increasingly recognise that manual infrastructure management is unsustainable.

Three Fault Lines That Make Manual Infrastructure Dangerous for SMEs

Manual infrastructure is not merely inconvenient. It creates three systemic fault lines that are especially dangerous for SMEs because no redundant department closes the gaps.

1. Person Dependency: When Knowledge Is Remembered, Not Documented

If only Klaus knows which changes were made to a server, any stand-in has to reconstruct that information. Check whether another person can understand the desired state from the repository, configuration, and operating instructions. A general percentage about key-person dependency cannot replace that exercise.

For infrastructure, this means: when Klaus falls ill, resigns, or is simply on holiday, the operational knowledge does not exist in documented form. It exists as terminal history, Slack messages, and oral tradition.

2. Configuration Drift: Why Identical Environments Never Stay Identical

Six months ago, the three environments — development, staging, production — were "identical". Today each server has accumulated ad-hoc changes: a manual nginx tweak on staging, a forgotten cron job on production, a test port left open on development. The environments look similar visually but have diverged technically.

Configuration drift can explain why the same release works in staging and fails in production. Compare declared state with actual configuration. Git alone does not detect changes made outside the process; suitable checks and an owner for deviations are still needed.

3. Audit Blindness: When Changes Leave No Trace

A cyber insurance review, an ISO 27001 audit, or the NIS2 directive asks for evidence: how is your infrastructure configured? Who changed what? Was there a review process? With manual infrastructure, the answer is a collection of email threads, Slack messages, and handwritten notes. There is no changelog, no approval trail, no reproducible baseline.

NIS2 applicability depends on the entity and national implementation. Germany's implementation applies from 6 December 2025; Austria's NISG 2026 from 1 October 2026. Version control and traceable changes can support technical evidence; Infrastructure as Code is neither universally mandated nor proof of full compliance.

From Documentation to Code: A Pragmatic Adoption Path

The leap from "everything manual" to "everything automated" is too large for SMEs. A four-phase adoption path, modelled on the JISEM IaC Maturity Model (2025), reduces risk and produces measurable progress after each phase.

Phase 1: Inventory and Document (1 Week)

Before you automate, you must know what you have. Create an inventory of all servers, services, cloud resources, and configuration files. Document the current state — not as a novel, but as a structured list: server name, IP, operating system, running services, open ports, responsible person, last change.

The goal of this phase is not perfection. The goal is transparency. If Klaus goes on holiday tomorrow, a colleague should be able to read this inventory and at least know which systems exist and where they run.

Phase 2: Codify Configuration (2–4 Weeks)

Choose a single service or server type and describe its desired state in code. For Linux servers and services, Ansible is suitable: a playbook that defines which packages are installed, which configuration files exist, and which services are running. For cloud resources, Terraform is suitable: a manifest that defines which virtual machines, networks, and storage exist.

Do not start with the most complex server. Start with one you understand — perhaps the staging web server. If you can rebuild this server from code, you have provided the most important proof: the configuration no longer lives in a person's head, but in a file.

Phase 3: Automate and Review (1–2 Months)

Connect the code to Git. Every change becomes a merge request. Every merge request is reviewed by a second person — even if that person initially only understands that something changed, without knowing every detail. The GitLab CI pipeline executes the playbook after the merge request is approved.

The decisive cultural shift happens here: infrastructure changes are no longer "done"; they are "proposed, reviewed, and applied". This creates the audit trail that compliance auditors look for.

Phase 4: Govern and Monitor (Ongoing)

Run monthly drift checks: compare the declared configuration with the actual configuration on the servers. Run quarterly recovery exercises: rebuild a test server completely from code. Maintain the inventory. Review merge request quality.

These routines seem unspectacular. But they prevent the infrastructure from reverting to a collection of manual tweaks after six months.

GitOps for SMEs: Git as the Single Source of Truth

GitOps is not a new tool. It is an operating model: Git is the single source of truth for both application code and infrastructure code. When the desired state changes, you change a file in Git. An automation tool notices the change and brings the actual environment into the desired state.

For SMEs, Git is the right control point because most businesses already use Git for software development. This means: no new tool, no new licence, no new learning curve. It also means: the review process you already know for code changes now applies to infrastructure changes as well.

The toolchain for mid-market businesses is pragmatically scalable:

• Ansible for operating-system and service configuration. It requires no agent on target servers, works over SSH, and is idempotent: running the same playbook multiple times always leads to the same state.
• Terraform or Kubernetes manifests for cloud resources and container orchestration. Terraform is especially valuable when switching cloud providers or pursuing a multi-cloud strategy.
• GitLab CI as the execution and review layer. The pipeline executes playbooks, runs quality gates, and documents every step.

The Planfold proof story on infrastructure standardisation validates this model in practice: GitLab as the source of truth for inventories, playbooks, and role structure. GitLab CI for quality and hygiene gates. Ansible for Linux and Windows administration. Semaphore for controlled execution, scheduling, and operator workflows. The result is not merely automation — it is a governable operating model with less drift, lower person dependency, and clear audit traces.

The Planfold Perspective: Sovereignty Begins With Repeatability

Planfold treats infrastructure as code from day one. Every server, every network rule, every service configuration is declared in versioned files that live in Git, pass review, and are applied by automated pipelines. This is not a tool stack. This is an operating model.

Plan means mapping your current infrastructure. Which servers exist? Where does the knowledge live? What dependencies exist? Where is the greatest drift? What audit gaps are present?

Unfold means building the repeatability layer. A first inventory, a first playbook, a GitLab CI pipeline, a review process. Not as a separate compliance portal, but as part of your digital headquarters: in workflows, documentation, roles, and automation.

Resonate means maintaining evidence. Monthly drift checks. Quarterly recovery exercises. Review of merge request quality. Updating playbooks when a system changes. These routines prevent infrastructure from reverting to memory and assumption after a year.

Why portable means being able to rebuild from code: when your entire infrastructure lives in versioned, reviewed files, you keep the exit key. You can switch cloud providers without three months of reverse engineering. You can answer audit questions with a Git log. You can build new environments in hours rather than days — because the code describes the environment, not a person reconstructing it from memory.

The next step is concrete. If your infrastructure today is based on manual configuration, person-dependent knowledge, and missing audit trails, then the first step is not buying an enterprise platform. The first step is the decision that server configuration may no longer be a personal memory exercise.