TYPO3 Hosting

Betrieb auf Servern in Deutschland (Hetzner, DE). Pro Projekt eine logisch getrennte Umgebung (z. B. eigene Instanz/Namespace/Container/VM – je nach Setup), damit Ressourcen, Zugriffe und Risiken separiert sind.

CPU/RAM/Storage werden passend zur erwarteten Last dimensioniert und können später skaliert werden. Je nach Projektprofil sind getrennte Komponenten für Datenbank, Objektspeicher (z.B. S3), Cache und Webserver möglich.

Optional zwei Umgebungen: Staging (Test/Abnahme) und Produktion (Livebetrieb). Staging ist ein möglichst reales Abbild der Produktion (Konfiguration, PHP-Version, Extensions, Caching, Parameter), damit Updates und Deployments zuverlässig validiert werden können.

Änderungen werden zuerst im Staging geprüft und nach Freigabe in Produktion übernommen. Für geplante Releases können Wartungsfenster vereinbart werden; für kritische Security-Fixes gelten verkürzte Abläufe nach SLA. Bei Bedarf sind weitere Umgebungen möglich (z. B. für neue Schnittstellen).

Deployments erfolgen automatisiert und reproduzierbar (CI/CD) – inkl. Code, Konfiguration, Tests und ggf. Datenbankmigrationen. Der Prozess ist versioniert (Git), nachvollziehbar (Logs/Artefakte) und enthält eine Rollback-Strategie.

Ziel: standardisierte Releases mit weniger Handarbeit, weniger Risiko und schnellerer Reaktionsfähigkeit.

Regelmäßige, automatisierte Backups vom Dateisystem (z. B. fileadmin, Konfiguration, ggf. Deploy-Artefakte) und der Datenbank. Zusätzlich: Einzeldatei-Wiederherstellung (Restore einzelner Dateien/Verzeichnisse) sowie kompletter Restore bei schweren Fehlern.

Der Applikations-Quellcode ist in einem Versionskontrollsystem (Git) abgelegt und erlaubt eine Wiederherstellung von früheren Zuständen der Code-Basis.

Backup-Frequenz und Aufbewahrungszeiten (Retention) werden gemeinsam definiert.

Einspielen von Updates für TYPO3 Core (Security-/Bugfix-/Maintenance-Releases der verwendeten LTS Version), Extensions (TER/Composer) und PHP/Composer Libraries (Dependencies). Updates werden zuerst im Staging eingespielt und per Smoke-Tests geprüft (Backend-Login, zentrale Seitentypen/Layouts, Formulare, Caching, Logs).

Nach Freigabe erfolgt der Rollout in Produktion. Für Security-Advisories gilt ein beschleunigter Prozess nach SLA (zeitnahes Patchen). Ziel ist ein dauerhaft wartbarer Zustand ohne „Upgrade-Schulden“.

Unser Update-Prozess für TYPO3 ist weitgehend automatisiert: Mit Renovate, einem Tool zur intelligenten Dependency-Automatisierung, überwachen und aktualisieren wir den TYPO3 Core, Erweiterungen, Bibliotheken und Sicherheits-Patches kontinuierlich. Ein automatisierter QS-/Test-Prozess gewährleistet, dass die Applikation mit den Updates weiterhin funktionsfähig ist, bevor die Übertragung auf die Staging-/Produktionsumgebung erfolgt.

Zertifikatsmanagement inkl. Einrichtung, Erneuerung und Prüfung. Umfasst TLS-Zertifikate (z. B. Let’s Encrypt oder kundeneigene Zertifikate), HTTPS-Weiterleitungen und sichere Basiskonfiguration.

Überwachung von Uptime, Fehlerquoten, Antwortzeiten und Ressourcen (CPU/RAM/Disk) inkl. Alarmierung. Optional: Log-Monitoring (500er, PHP-Fatals, TYPO3-Exceptions) und proaktives Erkennen von Engpässen.

Benachrichtigungen erfolgen, je nach Priorität, über verschiedene Kommunikationskanäle (Push-Notification, Slack, E-Mail), um eine schnelle Reaktionsfähigkeit zu gewährleisten.

Basishärtung (Firewalls, Fail2ban/Rate limiting, restriktive Zugriffe, SSH-Key-Only, Minimalrechte). Optional: WAF/Reverse-Proxy-Regeln.

Zusätzlich: Security-Headers, CSP-Konzept, CORS, HSTS Header, SSRF Abwehr

Performance-Optimierung (Caching-Strategie, Redis/Valkey, Varnish/Static File Cache, CDN, S3, Bildoptimierung, Datenbank-Tuning). Ziel ist stabile Performance – auch bei Lastspitzen.

Einrichtung stabiler Mailzustellung via SMTP-Relay sowie SPF/DKIM/DMARC-Konfiguration. Optional Bounce-Handling/Monitoring, wenn viele Formulare oder Newsletter-Integrationen im Einsatz sind.

Mit Apache im Prefork-Modus belegt jede offene Keep-Alive-Verbindung einen ganzen Worker. Hinter einem Reverse Proxy hat Debians Voreinstellung von 5 Sekunden den Pool leerlaufen lassen, Anfragen warteten sekundenlang auf einen freien Worker. In unserem Basis-Image steht der Wert deshalb auf 1 Sekunde.

Die Zahl der Worker ergibt sich aus dem Speicher, denn jeder darf bis zum PHP-memory_limit wachsen: 8 Worker mit 256 MB brauchen im ungünstigsten Fall rund 2,3 GiB, und das Speicherlimit des Containers muss das tragen. Welche Stellschrauben sonst messbar etwas bringen, steht unter TYPO3 schneller machen.

GraphicsMagick läuft als eigener Prozess, das PHP-memory_limit gilt für ihn nicht. Seinen Speicher bemisst er am Arbeitsspeicher des Servers, nicht am Limit des Containers: Ein einziges übergroßes Bild kann auf 5 bis 6 GB anwachsen, und der Container wird wegen Speichermangels beendet.

Abhilfe schaffen Grenzen über Umgebungsvariablen, bei uns MAGICK_LIMIT_MEMORY und MAGICK_LIMIT_MAP mit je 256 MB und MAGICK_LIMIT_PIXELS als harte Obergrenze. Den Überlauf lenkt MAGICK_TMPDIR auf ein Volume auf der Platte, nicht im Arbeitsspeicher. Große Bilder werden dann langsamer verarbeitet statt gar nicht.

Dasselbe gilt für die Threads: GraphicsMagick richtet sich nach den Kernen des Servers, nicht nach dem CPU-Kontingent des Containers, und bremst sich damit selbst aus. Mit OMP_NUM_THREADS=1 war jede Umwandlung bei uns rund 17 % schneller.

Liegt var/cache/ auf einem Volume, überlebt der Cache einen Neustart des Containers, auch einen harten wegen Speichermangels mitten im Schreiben. Der neue Container startet dann mit halb geschriebenen Cache-Dateien und meldet Fehler, bis jemand die Caches leert.

Unser Basis-Image räumt deshalb beim Start auf, bevor der Webserver Anfragen annimmt: Cache-Verzeichnis leeren, fehlende Ordner anlegen (install:fixfolderstructure), den System-Cache aufwärmen (cache:warmup --group system). Beide TYPO3-Befehle laufen mit festem Zeitlimit, sodass sich die Startprüfung des Containers (startupProbe) daran bemessen lässt.

Im Container ist das Dateisystem meist schreibgeschützt, language:update kann beim Deploy dort nichts ablegen. Wir legen die Sprachpakete deshalb ins Image. Ein geplanter CI-Job aktualisiert sie regelmäßig und öffnet dafür einen Merge Request.

Läuft der Scheduler als eigener Cronjob, kann er während eines Deploys gegen eine Datenbank laufen, deren Schema noch nicht aktualisiert ist. Wir halten ihn vor dem Deploy an und warten laufende Aufgaben ab – der Neuaufbau des Referenzindex kann Minuten dauern. Danach schalten wir ihn wieder ein, auch wenn der Deploy scheitert.

Liegt der Seitencache in Redis, ist er nach einem Neustart von Redis leer, während die übrigen Caches in der Datenbank weiterleben. Die beiden Stände passen dann nicht mehr zusammen, und TYPO3 antwortet mit Fehler 503, bis jemand alle Caches leert.

Mit b13/graceful-cache übersteht die Seite einen kurzen Ausfall von Redis. Für den Neustart prüft bei uns ein Scheduler-Task jede Minute die Kennung, die Redis bei jedem Start neu vergibt (run_id). Ändert sie sich, leert er alle Caches.

Teilen sich Staging und Produktion einen Datenbankserver, kann eine Schemaänderung oder eine ausufernde Abfrage auf Staging die Live-Seite treffen. Wir geben jeder Umgebung einen eigenen Server.

Galera-Cluster meiden wir für TYPO3. Galera repliziert nur InnoDB-Tabellen, Schreibzugriffe auf MyISAM- oder Aria-Tabellen landen ohne Fehlermeldung nur auf einem Knoten. Schemaänderungen laufen unter einer Sperre für den ganzen Cluster, und database:updateschema löst sie wiederholt aus. Tabellen ohne Primärschlüssel repliziert Galera nicht zuverlässig.

TYPO3 wertet die X-Forwarded-*-Header nur für Anfragen von Adressen aus reverseProxyIP aus. Deckt die Einstellung das Netz des Ingress ab, aber nicht die Loopback-Adresse, liefert eine Anfrage an 127.0.0.1 im Container eine 404-Seite statt der Seite: TYPO3 hält die Verbindung für http, und die Site mit https-Basis passt nicht. Zum Testen im Container deshalb die IP des Pods ansprechen, mit Host- und X-Forwarded-Proto-Header.

Beim Wechsel der Domain gehören vier Stellen zusammen: Ingress-Host, TLS-Zertifikat, die Basis-URL der Site und trustedHostsPattern. Passt das Muster nicht, lehnt TYPO3 jede Anfrage mit dem neuen Host ab.