Gehärtetes TYPO3-Hosting: Unser Boilerplate für sichere Produktionsumgebungen

Christopher Zechendorf

03.04.2026

Share:

Wie wir mit einem einzigen Setup-Script produktionsreife TYPO3-Umgebungen generieren — mit Docker, Nginx-Härtung, automatischer Ressourcenberechnung und CI/CD.

Die Herausforderung

Jedes neue TYPO3-Projekt braucht eine Produktionsumgebung. Server aufsetzen, Docker konfigurieren, Nginx härten, SSL einrichten, Firewall-Regeln definieren, CI/CD-Pipeline bauen — das sind pro Projekt schnell mehrere Tage Arbeit. Und bei jedem manuellen Schritt schleichen sich potenzielle Fehler ein: ein vergessener Security Header, eine fehlende Rate-Limiting-Regel, PHP-FPM-Worker die nicht zum verfügbaren RAM passen.

Wir haben über die letzten Jahre für jedes Kundenprojekt dieselben Bausteine konfiguriert — mit leichten Variationen je nach Servergrösse und Domain. Die Frage war: Können wir diesen Prozess so standardisieren, dass jedes neue Projekt automatisch den gleichen gehärteten Standard bekommt?

Unsere Lösung

Wir haben ein TYPO3-Boilerplate entwickelt, das mit einem einzigen setup.sh-Aufruf ein vollständiges, produktionsreifes Projekt generiert. Das Script fragt Domain, Projektname und Server-Ressourcen ab und erzeugt daraus die komplette Infrastruktur — von Docker Compose über Nginx-Konfiguration bis zur GitLab-CI/CD-Pipeline.

Architektur: Drei Container, zwei Netzwerke

Die generierte Umgebung besteht aus drei Services in Docker Compose:

• TYPO3 (PHP 8.4-FPM + Nginx + Supervisor) — der Applikations-Container
• MariaDB 10.11 — die Datenbank
• Redis 7 — Cache-Backend mit LRU-Eviction

Entscheidend ist die Netzwerktrennung: MariaDB und Redis befinden sich ausschliesslich im internen backend-Netzwerk. Nur der TYPO3-Container hat Zugang zu beiden Netzwerken — backend für die Datenbank-Kommunikation und frontend für HTTP/HTTPS-Traffic. Die Datenbank ist damit von aussen nicht erreichbar, auch nicht über einen Portscan auf dem Host.

networks:
  backend:
    internal: true  # Kein Zugang von aussen
  frontend:

Für die lokale Entwicklung stehen zusätzlich phpMyAdmin und MailHog als Docker-Profiles zur Verfügung — sie werden nur mit COMPOSE_PROFILES=development gestartet und sind in Staging/Production nicht vorhanden.

Intelligente Ressourcenberechnung

Einer der Kernaspekte des Boilerplates ist die automatische Berechnung von Docker-Ressourcenlimits basierend auf dem verfügbaren Server-RAM. Das Setup-Script fragt die RAM-Grösse für Staging und Production ab und generiert daraus jeweils eine docker-compose.staging.yml und docker-compose.production.yml mit passenden Limits.

Die Verteilung folgt einem festen Schema:

Aus dem TYPO3-Anteil berechnet das Script zusätzlich die optimale Anzahl PHP-FPM-Worker — ein Worker pro 80 MB verfügbarem Speicher. Bei einem 4-GB-Server ergeben sich so ca. 25 Worker, bei 8 GB etwa 51. Die pm.start_servers, pm.min_spare_servers und pm.max_spare_servers-Werte werden proportional dazu gesetzt.

Auch die MariaDB-Konfiguration wird angepasst: Der InnoDB Buffer Pool erhält 60% des Datenbank-Limits, die InnoDB Log File Size skaliert mit der RAM-Grösse (64 MB bis 256 MB). Ab 16 GB RAM werden zusätzliche Performance-Optionen wie tmp-table-size, join-buffer-size und Performance Schema aktiviert.

Das Ergebnis: Kein manuelles Tuning mehr. Die Ressourcen-Konfiguration ist immer auf den jeweiligen Server abgestimmt und verhindert sowohl OOM-Kills als auch ungenutzte Kapazität.

Automatische Server-Provisionierung

Für neue Server liefert das Boilerplate eine Cloud-Init-Konfiguration mit, die den Server beim ersten Start automatisch härtet:

• SSH-Härtung: Root-Login deaktiviert, nur Public-Key-Authentifizierung, maximal 3 Login-Versuche
• UFW-Firewall: Standardmässig alles blockiert, nur SSH, HTTP und HTTPS offen
• fail2ban: SSH-Schutz mit maximal 3 Fehlversuchen, plus ein eigener Jail für Vulnerability Scanner
• Automatische Sicherheitsupdates: Unattended Upgrades mit täglicher Prüfung und automatischem Reboot um 4:00 Uhr morgens — Docker-Pakete sind von Updates ausgenommen, um unerwartete Container-Probleme zu vermeiden
• Deploy-User: Ein dedizierter deploy-Benutzer mit Docker-Zugang für CI/CD-Deployments

Der gesamte Prozess läuft ohne manuellen Eingriff. Nach dem Boot ist der Server produktionsbereit.

Nginx-Konfiguration mit Security-by-Default

Das Boilerplate enthält drei Nginx-Konfigurationen — Development, Staging und Production — die der Container beim Start je nach TYPO3_CONTEXT-Umgebungsvariable automatisch aktiviert. Die Production-Konfiguration umfasst:

TLS-Härtung:

• Ausschliesslich TLS 1.2 und 1.3
• Moderne Cipher Suite (ECDHE + ChaCha20 + AES-GCM)
• OCSP Stapling für schnellere Zertifikatsprüfung
• HSTS mit includeSubDomains und preload (1 Jahr)

Rate Limiting:

• 5 Requests pro Sekunde pro IP
• Burst von 15 für kurzzeitige Spitzen
• TYPO3-Backend-Dateiuploads sind vom Rate Limit ausgenommen

Blockierte Angriffspfade:

• Versteckte Dateien und Verzeichnisse (.git, .env, .svn)
• PHP-Ausführung in Upload-Verzeichnissen (fileadmin, typo3temp, uploads)
• Zugriff auf composer.json, Konfigurationsdateien, Logs und SQL-Dumps
• TYPO3-interne Verzeichnisse (Resources/Private, Tests, Documentation)

Performance:

• Aggressive Browser-Caching-Regeln: CSS, JS, Bilder und Fonts mit 1 Jahr Laufzeit und immutable-Flag
• Gzip-Komprimierung für 26+ Content-Types
• Support für versionierte Dateinamen (z.B. style.abc123.css)

Automatische SSL-Zertifikate

Der Entrypoint-Script des TYPO3-Containers kümmert sich selbstständig um Let’s-Encrypt-Zertifikate. Beim ersten Start erkennt er, ob bereits Zertifikate vorhanden sind. Falls nicht, startet er zunächst eine temporäre HTTP-only-Konfiguration, fordert über Certbot ein Zertifikat an und wechselt dann zur vollständigen HTTPS-Konfiguration. Die Zertifikate werden in einem Docker Volume persistiert und zweimal täglich per Cron-Job erneuert.

Dieser Mechanismus funktioniert identisch für Staging und Production — der einzige Unterschied ist die Domain. Manuelle Zertifikats-Verwaltung entfällt komplett.

CI/CD-Pipeline

Die generierte .gitlab-ci.yml definiert zwei Deployment-Stages:

• Staging: Deployment bei Push auf den staging-Branch
• Production: Deployment bei Push auf den main-Branch

Beide Stages folgen demselben Ablauf:

1. Repository per rsync auf den Server synchronisieren (Runtime-Verzeichnisse und .env werden ausgeschlossen)
2. .env-Datei aus GitLab-CI-Variablen generieren (Passwörter liegen nie im Repository)
3. Ressourcen-Override als docker-compose.override.yml aktivieren
4. Container neu bauen und starten
5. fail2ban-Konfigurationen auf den Host deployen
6. TYPO3-Caches leeren

Log Rotation und Monitoring

Logs werden auf drei Ebenen rotiert:

• PHP-Fehler: Wöchentlich, 8 Wochen Aufbewahrung
• TYPO3-Applikationslogs: Täglich, 14 Tage Aufbewahrung
• Docker-Container-Logs: Maximal 10 MB pro Datei, 3 Dateien pro Service

Redis hat einen eingebauten Health Check (10-Sekunden-Intervall), der Container-Neustarts bei Problemen auslöst. Der Entrypoint-Script setzt beim Start alle blockierten Scheduler-Tasks zurück — ein häufiges Problem, wenn Container während laufender Cronjobs beendet werden.

Das Ergebnis

Was früher Tage manueller Konfiguration erforderte, ist jetzt ein 5-Minuten-Prozess:

./setup.sh
# → Domain, Titel, Server-RAM eingeben
# → Fertiges Projekt mit allen Konfigurationen
cd ../client.tld
docker compose up -d

Jedes Projekt startet mit demselben gehärteten Standard — unabhängig davon, ob es auf einem 2-GB-VPS oder einem 32-GB-Dedicated-Server läuft. Die Ressourcen-Konfiguration passt sich automatisch an, die Sicherheitsmassnahmen sind identisch.

Das Boilerplate ist ein lebendes System: Erkenntnisse aus dem Betrieb — wie die Absicherung gegen Vulnerability Scanner, die wir kürzlich beschrieben haben — fliessen zurück in die Standardkonfiguration. Jedes neue Projekt profitiert automatisch von den Erfahrungen aller bestehenden Projekte.

Sie suchen eine Agentur, die nicht nur TYPO3-Websites entwickelt, sondern auch das Hosting und die Infrastruktur professionell betreut? Sprechen Sie uns über unser Kontaktformular an — wir beraten Sie gerne.