Mittelstand-Stack, Teil 2: Terraform für kleine Teams — ab wann es sich lohnt

In Teil 1 stand Hetzner als bezahlbare, souveräne Basis. Ein Satz fiel dort fast nebenbei: dass die Integration in Terraform der eigentliche Pluspunkt sei. Genau darum geht es jetzt.

Meine Botschaft, knapp: Terraform lohnt sich ab der ersten Person im IT-Team. Nicht ab dem fünften, nicht ab dem eigenen Plattformteam — ab eins.

Ab wann es sich lohnt: ab eins

Der Einwand kommt sofort, und er ist nicht dumm: Zusammenklicken geht schneller. Eine Konsole, ein paar Klicks, der Server läuft. Stimmt — für die ersten Wochen. Dann kommt der zweite Server, eine Firewall-Regel hier, ein Volume da, eine DNS-Änderung „schnell zwischendurch". Nach ein paar Monaten weiß niemand mehr verlässlich, welche Konfiguration warum so ist. Spätestens bei einem Hardware-Defekt oder einem Anbieterwechsel wird aus dem „schnell zwischendurch" ein Tag voller Raterei.

Der Punkt ist nicht Bequemlichkeit, sondern Gedächtnis. Eine Konsole erinnert sich nicht, warum eine Regel existiert. Git schon.

Wofür ich es einsetze — und wo der State liegt

Ich beschreibe damit alle Dienste, die Infrastruktur bereitstellen oder beeinflussen — bei mir Hetzner und Cloudflare. Server, Volumes, Firewalls, DNS, Load Balancer: alles in Code, alles in Git.

Der State liegt bei mir in einem S3-kompatiblen Bucket bei Hetzner. Der Grund ist kein technischer Selbstzweck, sondern Selbstabsicherung: Die Infrastruktur ist versioniert, ich behalte den Überblick, und bei einem Komplettausfall sind die manuellen Schritte minimal. Für mich — und für die Kunden, die sich darauf verlassen.

Was es konkret rettet

Drei Situationen, in denen sich der Aufwand auszahlt: Wiederherstellung nach Ausfall, Drift und der Aufbau von Testsystemen.

Manuell vergisst man immer etwas. Eine Firewall-Regel, eine Netzwerk-Einstellung, ein Volume, das falsch oder gar nicht gemountet ist. Jedes einzelne Detail ist klein. In Summe kostet es Stunden — und im Ausfall sind das die teuersten Stunden, die es gibt.

So fängt es an — ein Server, ein Volume, eine Firewall, die nur durchlässt, was rein soll, und ein cloud-init, das die Kiste schon beim ersten Boot härtet. Alles in Dateien, die in Git liegen:

resource "hcloud_server" "app" {
  name         = "app-01"
  server_type  = "ccx23"
  image        = "debian-12"
  location     = "nbg1"
  firewall_ids = [hcloud_firewall.web.id]
  user_data    = file("cloud-init.yaml")
}

resource "hcloud_volume" "data" {
  name      = "app-data"
  size      = 100
  server_id = hcloud_server.app.id
  automount = true
  format    = "ext4"
}

resource "hcloud_firewall" "web" {
  name = "web"

  rule {                               # SSH nur von der eigenen IP
    direction  = "in"
    protocol   = "tcp"
    port       = "22"
    source_ips = ["203.0.113.10/32"]
  }
  rule {                               # HTTPS offen
    direction  = "in"
    protocol   = "tcp"
    port       = "443"
    source_ips = ["0.0.0.0/0", "::/0"]
  }
  rule {                               # nur für den Redirect auf 443
    direction  = "in"
    protocol   = "tcp"
    port       = "80"
    source_ips = ["0.0.0.0/0", "::/0"]
  }
}

#cloud-config
# beim ersten Boot: Härtung statt Handarbeit
package_update: true
packages:
  - fail2ban
  - unattended-upgrades
users:
  - name: deploy
    groups: [sudo]
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... deploy@laptop
ssh_pwauth: false
runcmd:
  - echo 'PermitRootLogin no' >> /etc/ssh/sshd_config.d/hardening.conf
  - echo 'PasswordAuthentication no' >> /etc/ssh/sshd_config.d/hardening.conf
  - systemctl restart ssh
  - systemctl enable --now fail2ban

Mehr ist es am Anfang nicht. Kein Modul-Gerüst, kein Workspace-Konstrukt — ein paar Ressourcen plus ein cloud-init. Aber der Server kommt reproduzierbar und gehärtet hoch: fail2ban, kein Root-Login, kein Passwort-SSH, Port 22 nur von der eigenen IP. Genau das vergisst man beim Zusammenklicken zuverlässig. Der Einstieg ist klein, der Nutzen sofort da.

Die Overhead-Falle

Und damit zur Kehrseite: Terraform kippt in Overhead, wenn man es überzieht. Der häufigste Fehler in kleinen Teams ist der Versuch, alles in ein einziges Terraform-Projekt zu zwingen — ein „One-Click"-Setup, das jeden Handgriff abbildet.

Mein Rat fürs kleine Team: Nicht jeder Handgriff muss in Terraform. Dokumentation, Runbooks und ein paar Shell-Skripte sind kein Versagen, sondern Teil eines gesunden Setups. Terraform bildet die Infrastruktur ab — den Rest darf ruhig ein gut geschriebenes Runbook tragen. Wer das „One-Click"-Ideal erzwingt, baut sich genau den Overhead, vor dem ihn Terraform eigentlich bewahren sollte.

Fazit

Terraform ist im kleinen Team kein Enterprise-Tooling, das man sich erst leisten können muss. Es ist die billigste Versicherung gegen den Tag, an dem etwas ausfällt oder der Anbieter wechselt. Ab einer Person lohnt es sich — vorausgesetzt, man bildet die Infrastruktur ab und nicht die ganze Welt.

Teil 3 schließt die Serie ab; danach steht der Mittelstand-Stack komplett.

Wenn bei Ihnen Infrastruktur „historisch gewachsen" ist und niemand mehr genau sagen kann, was warum läuft: Genau dieses Aufräumen — und der Aufbau eines Setups, das ein kleines Team trägt — ist Teil meiner Arbeit im Technical Consulting.