CARGRAPHIC — Infrastruktur, TYPO3-Update & Deployment

Ist-Zustand

Ein Server für alles — nichts davon aktuell

srv1.cargraphic.com, verwaltet über pd-admin (Reseller-Hosting-Panel). Alle Projekte teilen sich dieselbe PHP-Version, dieselbe MySQL-Version und dieselbe Hardware. Deployment per FTP-Dateikopie — kein Git, kein Staging, kein Rollback.

srv1.cargraphic.com · ein physischer Server

TYPO3 8.27

End of Life seit März 2020

PHP 7.x

End of Life seit November 2022

MySQL 5.5.62

End of Life seit Dezember 2018

4 Domains · 8 Datenbanken · 300 von 400 GB belegt

cargraphic.de
+ eigenes DB-Scheme

cargraphic.com
+ eigenes DB-Scheme

cargraphicts.com
+ eigenes DB-Scheme

Stage-Variante
+ eigenes DB-Scheme

old.cargraphic.de
Status unklar

old.cargraphicts.com
Status unklar

Performance
+ eigene DB-Schemes

Ein PHP- oder MySQL-Upgrade auf diesem Server betrifft zwangsläufig alle Projekte gleichzeitig.
Jedes Projekt hat einen anderen Versionsstand und eigene Extensions — alle gleichzeitig upgrade-fähig zu machen ist unrealistisch.

Derzeitiger Arbeitsflow

Marc (Entwickler)

arbeitet auf seinem Computer

Bernhard

meldet sich im Browser an und pflegt die Seite

lädt Code hoch

holt Datenbank-Kopie

meldet sich an und ändert Inhalte

srv1.cargraphic.com · pd-admin

Dateiablage

Webseitencode + alle Bilder gemischt

Webseitencode (Design, Vorlagen, Erweiterungen)

Alle Bilder — 40 GB

Kein Rückgängig-Knopf, kein Versionsstand

Änderungen

Die Webseite

cargraphic.de

Änderungen von Marc gehen direkt hier hin

Kein Test vorher möglich

liest Texte & Inhalte

Inhaltsdatenbank

alle Texte, Seitenstruktur, Produkte · kein Bild drin

Protokoll & Änderungshistorie2.570 MB

Zwischenspeicher330 MB

Echter Inhalt~600 MB

Bernhard lädt Bild hoch

Bernhard ändert Text

Marcs Änderungen landen sofort auf der Live-Webseite — ein Testlauf vorher ist nicht möglich.

Marcs Workflow

Bevor ich anfangen kann ...

1 DB-Dump vom Provider ziehen und lokal importieren

2 FTP-Stand herunterladen — TYPO3-Code und 40 GB fileadmin

3 Lokales TYPO3 starten gegen lokale MySQL + lokales fileadmin

Hat Bernhard zwischenzeitlich einen Inhalt geändert — Dump veraltet, von vorne (sollte eigtl so sein — ist derzeit aber nicht tragbar, da jeder Dump den Server lahmlegt.

Wenn ich fertig bin ...

1 Geänderte Dateien per FTP auf den Server hochladen

2 DB-Änderungen als SQL-Statement direkt auf der Live-DB ausführen

3 Kein Staging — Änderungen sind sofort live. Kein Rollback möglich.

Ein Fehler im SQL-Statement trifft direkt die Live-Datenbank — ohne Rückweg.

TYPO3-Update blockiert Kernproblem

TYPO3 v14 braucht PHP 8.2+ und MySQL 8.0+ / MariaDB 10.6+.
Auf srv1 läuft PHP 7.x und MySQL 5.5.62 — für alle Projekte.
PHP oder MySQL auf dem Server upgraden? Dann müssen alle 4 Domains und 8 Datenbanken gleichzeitig die neuen Versionen vertragen.
Jedes Projekt hat eigene Extensions mit eigenen Versionsanforderungen — ein gleichzeitiges Upgrade aller Projekte ist nicht realistisch.
Ergebnis: cargraphic.de kann auf diesem Server nicht aktualisiert werden.

Datenbank blockiert Migration MySQL 5.5 — alle Projekte betroffen

Der Server läuft mit MySQL 5.5.62 — alle Projekte haben ihre eigenen Datenbank-Schemas, die auf Basis dieser Version angelegt wurden.
TYPO3 v14 erfordert mindestens MySQL 8.0 (oder MariaDB 10.6+) — ein In-Place-Upgrade von 5.5 auf 8.0 über drei Major-Versionen hinweg ist auf einem laufenden Produktivserver mit 8 Datenbanken nicht realistisch.
Schema-Inkompatibilitäten: Zeichensatz-Defaults, SQL-Modi und veraltete Storage-Engine-Optionen aus MySQL 5.5 müssen bei der Migration auf 8.0+ einzeln geprüft und angepasst werden.
Konsequenz: Für das TYPO3-Update von cargraphic.de wird ein neuer Server mit aktueller Datenbankversion benötigt — ein Upgrade auf dem bestehenden Server ist ausgeschlossen.
Langfristig sollten auch die übrigen Projekte auf die neue Infrastruktur migriert werden — sowohl aus Sicherheits- als auch aus Performance-Gründen.

FTP als einziger Zugang pd-admin Dateimanager

Deployment INT (lokal) → PRD ausschließlich manuell über FTP-Dateikopie im pd-admin Dateimanager — kein reproduzierbarer Prozess.
Code und Mediendateien (40 GB Bilder) liegen im selben Verzeichnis — Code und Bilder sind nicht trennbar.
Kein Versionsverlauf: wer was wann geändert hat, ist nicht nachvollziehbar. Kein Rollback.

Ein Server, kein Ausfallschutz srv1.cargraphic.com

4 Domains und 8 MySQL-Datenbanken auf einer physischen Maschine — fällt sie aus, sind alle Seiten gleichzeitig offline = CARGRAPHIC und PERFORMANCE
300 von 400 GB Speicher belegt — wenig Spielraum, kein Wachstum möglich.
CPU und RAM werden zwischen allen Projekten geteilt — Lastspitzen auf einer Seite bremsen alle anderen.
Ein fehlerhaftes Deployment auf einem Projekt kann den gesamten Server beeinträchtigen.
Diverse Alt-Ordner (old.cargraphic.de, old.cargraphicts.com) ungeklärter Aktualität — Nachteilig bei SEO, Speicher, ...
Bilder direkt auf Server-Dateisystem — kein Objektspeicher, keine Skalierung, an diesen einen Server gebunden.
Externe Bild-Referenzierung kann nicht verfügbar sein, wenn der Server down ist

Sicherheitsrisiko Drei Schichten ohne Updates

MySQL 5.5.62 — seit Dezember 2018 End of Life. Keine Sicherheitsupdates seit über 7 Jahren.
PHP 7.x — seit November 2022 End of Life. Bekannte Schwachstellen bleiben offen.
TYPO3 8.27 — seit März 2020 End of Life. Keine Patches mehr.
DSGVO-Haftungsrisiko: veraltete Software ohne Sicherheitsupdates ist ein dokumentierter Mangel.

Veraltetes CMS TYPO3 8.27 — 4 Hauptversionen zurück

Keine modernen Extensions — aktuelle Erweiterungen setzen mindestens TYPO3 v12 voraus.
Kein eingebautes SEO — Canonical Tags, XML-Sitemaps, strukturierte Daten nur über veraltete Plugins.
Kein Redirect-Management — defekte Links nach Umstrukturierungen werden nicht aufgefangen.
Veraltetes Backend — langsame Oberfläche mit Seitenreloads bei jeder Aktion.

Soll-Zustand

2 Hetzner-Server, Git, Deployer, Object Storage + Cloudflare

Physische Trennung: CPX32 für PRD, CPX12 für INT. Code in Git, Deployment per Deployer + GitHub Actions. Bilder in Hetzner Object Storage mit Cloudflare CDN davor. Cloudflare zusätzlich als WAF, DDoS-Schutz und Access-Gate für INT.

Bernhard (& Team)

pflegt Texte und Bilder im Browser wie gewohnt

Git + Deployer + GitHub Actions

develop-Branch → INT (CPX12)

main-Branch → PRD (CPX32)

Marcs Rechner

Kein 40 GB Download

Bilder per Proxy von INT/ PRD

pflegt Live-Seite

Deployer verteilt automatisch

entwickelt lokal

Cloudflare

CDN · WAF · DDoS-Schutz · Bot Fight Mode · Rate Limiting · Access (Zero Trust für INT)

Hetzner CPX32 · PRD

cargraphic.de

Git-Branch: main

4 vCPU · 8 GB RAM · 160 GB SSD

PHP 8.4 + MariaDB 10.6+

Eigene DB-Instanz · Backup aktiv

TYPO3 FAL → S3-API

Object Storage · PRD-Bucket

Bilder entkoppelt vom Server

Hetzner CPX12 · INT

int.cargraphic.de

Git-Branch: develop

1 vCPU · 2 GB RAM · 40 GB SSD

PHP 8.4 + MariaDB 10.6+

Eigene DB-Instanz · kein Backup

TYPO3 FAL → S3-API

Object Storage · INT-Bucket

Eigener Bucket

Physische Trennung: kein gemeinsamer Ausfallpunkt, keine Ressourcenkonkurrenz. Cloudflare als Schutzschicht vor beiden Servern.

Physische Trennung 2 getrennte Hetzner-Server

CPX12 (INT) und CPX32 (PRD) — keine gemeinsame Hardware, keine Ressourcenkonkurrenz.
Je Server eigene MariaDB 10.6+ Instanz — Pflichtvoraussetzung für TYPO3 v14, gleichzeitig Behebung des MySQL-5.5-Risikos.
PHP 8.3/8.4 — Mindestanforderung TYPO3 v14, 8.3/8.4 für optimale Performance.
PHP- und DB-Version pro Server frei wählbar — kein anderes Projekt wird berührt.

TYPO3 v14 LTS Sicherheitsupdates bis 2029

Long-Term-Support bis Juni 2029, ELTS bis 2032.
SEO nativ eingebaut — XML-Sitemaps, Canonical Tags, strukturierte Daten im Core.
Redirect-Monitoring — automatische Erkennung defekter Links.
Content Blocks — strukturierte Inhaltstypen, kein TypoScript nötig.
Modernes Backend — überarbeitete Redaktionsoberfläche ohne Seitenreloads.
Fluid 5 — spürbar schnellere Seitenladezeiten.
Volles Extension-Ökosystem — Zugang zu allen aktuellen Erweiterungen.

Sicherheit wiederhergestellt Alle drei Schichten aktuell

TYPO3, PHP und Datenbank erhalten regelmäßig Sicherheitsupdates.
DSGVO-konform — kein dokumentierter Mangel durch veraltete Software.
Hosting zukunftssicher — keine erzwungene Umstellung durch auslaufende PHP-Unterstützung.
Angriffsoberfläche reduziert — Alt-Ordner und unkläre Domains bereinigt.

Kostenreduktion Monatliche Hosting-Kosten im Vergleich

Vorher: €243,00 / Monat (Providerdienste, gemeinsamer vServer — Anteil CARGRAPHIC muss noch aufgeschlüsselt werden)
Nachher: ~€62,93 / Monat netto (Hetzner Cloud, 2 Server + Object Storage + Cloudflare)

Vorgehen / Empfehlung

Konkreter Umsetzungsplan — Migration zu Hetzner (cargraphic.de, cargraphic.com, cargraphicts.com)

Migration vom bestehenden Providerdienste-Reseller-Server (EOL-Software: MySQL 5.5, PHP 5.2) zu Hetzner Cloud, unmanaged, in Eigenverwaltung. performance-automobildesign.de bleibt auf dem alten Server.

Vorab zu klären: CARGRAPHIC und PERFORMANCE teilen sich aktuell einen vServer bei Providerdienste mit einer shared Datenbank. Vor der Migration muss geklärt werden, wie sich die aktuellen Hosting-Kosten zwischen CARGRAPHIC und PERFORMANCE verteilen. performance-automobildesign.de bleibt auf dem alten Server — eine gemeinsame Migration ist nicht nötig.

Kernproblem: Der bestehende vServer ist nicht für TYPO3 v14 ausgelegt — weder PHP-Version noch Datenbank sind kompatibel. Zwei mögliche Wege:

Option A — Neuer vServer bei Providerdienste. Weiterhin Managed, aber höhere laufende Kosten und Abhängigkeit vom Hoster-Update-Zyklus.

Option B — Kompletter Umzug zu Hetzner. Unmanaged, volle Kontrolle, günstiger, aber Eigenverantwortung für Server-Administration.

Idee für eine Anpassung

Architektur

PRD · CPX32 (cargraphic.de)

2 vCPU · 4 GB RAM · 80 GB SSD

TYPO3 v14 · MySQL (eigene Instanz)

FAL → Object Storage Bucket (PRD)

Backup aktiv (im Preis enthalten)

INT · CPX12 (int.cargraphic.de)

1 vCPU · 2 GB RAM · 40 GB SSD

TYPO3 v14 · MySQL (eigene Instanz)

FAL → Object Storage Bucket

REIN INTERN - Whitelist für IP-Range, E-Mail, SEO ausgeschlossen, ...

Neue Features, neue Versionen testen, ...

Kein Backup — wird regelmäßig aus PRD neu befüllt

Warum Bilder auslagern?

Bilder und Dateien werden vom Server getrennt in einen eigenen Speicherdienst (Object Storage) verschoben.

›Speicher skaliert unabhängig vom Server. Der Server hat eine feste Speichergrenze (aktuell gering: 400 GB für alle Kunden). Object Storage ist für genau diesen Zweck ausgelegt und bietet in der Regel mindestens 1 TB.
›Hochauflösende Bilder sind kein Problem. Auch Dateien mit mehreren MB Größe belasten nicht den Server-Speicher oder die Server-Performance.
›Performance-Entlastung des Servers. Bild-Requests gehen nicht mehr an den Webserver — der kann sich auf TYPO3 und die Datenbank konzentrieren.
›Weitere Vorteile in der Entwicklung. Kein 40-GB-Download für lokale Entwicklung, kein fileadmin/-Sync beim Deployment, einfacherer Serverwechsel.
›CDN: Bilder und Dateien von überall nutzbar. Dieselben Assets können im Webshop, lokal in der Entwicklung, in E-Mails, auf Drittseiten — überall per URL eingebunden werden, ohne am Server zu hängen. Beispiel: assets.cargraphic.de/Porsche.png ODER cargraphic.de/assets/Porsche.png

Object Storage + Cloudflare CDN

Original-Assets (Bilder, Dokumente) in Hetzner Object Storage (S3-kompatibel, Standort Falkenstein).

          Frontend-Request → Cloudflare CDN (Cache) → Hetzner Object Storage (Origin)

          TYPO3 (PRD/INT) → schreibt Original-Assets direkt in den Bucket

Cloudflare (bereits als DNS-Provider im Einsatz) als CDN-Layer — Free-Tier ausreichend. CNAME auf Bucket-Endpoint, z. B. assets.cargraphic.de.

Cloudflare — mehr als nur CDN

Bei Hetzner unmanaged ist man für Security selbst verantwortlich.

›Web Application Firewall (WAF). Filtert bekannte Angriffsmuster (SQL-Injection, XSS, bekannte CVEs) auf HTTP-Ebene, bevor der Request den Hetzner-Server erreicht. Gerade bei TYPO3 (regelmäßig Ziel von Exploit-Scans) sinnvoll — reduziert die Angriffsfläche, die die eigene Server-Firewall abfangen müsste.
›Bot-Management / Bot Fight Mode. Blockt automatisierte Scraper, Credential-Stuffing-Bots, Content-Scraper. Entlastet den Server von unnötigem Bot-Traffic (Ressourcenschonung, weniger Log-Rauschen).
›DDoS-Schutz. Cloudflare filtert volumetrische Angriffe bereits am Edge. Cloudflare als vorgelagerte Schicht ist ein echter Sicherheitsgewinn ohne Zusatzkosten.
›Cloudflare Access (Zero Trust). Bereits im Einsatz für cargraphic-ideas.marcmaerdian.de (Email OTP). Gleiches Prinzip für INT: Die Staging-Umgebung muss nicht öffentlich erreichbar sein — Access/ IP-Whitelisting als Login-Gate verhindert, dass Testdaten oder unfertige Inhalte versehentlich einsehbar sind, ohne eine eigene Auth-Lösung bauen zu müssen.
›Page Rules / Caching-Feinsteuerung. Nicht nur für den Object-Storage-Bucket, sondern auch für statische TYPO3-Frontend-Seiten (Full Page Cache für unveränderte Inhalte) — kann die Serverlast bei Traffic-Spitzen zusätzlich senken.

Kosten (Stand: August 2026, exkl. USt.)

Finale Preise aus dem Hetzner-Konsolen-Checkout nach Preisanpassung vom 15.06.2026.

Position	Specs	Preis/Monat
PRD (Server + Backup + IPv4)	CPX32, 4 vCPU, 8 GB RAM, 160 GB SSD	€35,49
INT (Server + IPv4, ohne Backup)	CPX12, 1 vCPU, 2 GB RAM, 40 GB SSD	~€12,00
Object Storage PRD	1 TB Storage + 1 TB Traffic	€7,72
Object Storage INT	1 TB Storage + 1 TB Traffic	€7,72
Cloudflare	CDN, WAF, DDoS, Bot-Schutz, Access	0 €
Gesamt (netto)		~€62,93
Gesamt (brutto, inkl. 19 % USt.)		~€61,08

Umsetzung in 4 Phasen

Phase 1 — Infrastruktur aufsetzen

Hetzner, Cloudflare, Object-Storage-Buckets (PRD + INT) und GitHub-Repository konfigurieren
Zwei Cloud-Server bestellen (CPX32 für PRD, CPX12 für INT), Ubuntu 24.04 LTS als Basis
Webserver-Stack installieren: nginx/Apache, PHP 8.4, MySQL/MariaDB
Hochziehen auf neuer Domain: cargraphic.marcmaerdian.de

Phase 2 — TYPO3 v14 + Migration

TYPO3 v14 erstellen und bestehende Daten migrieren
Bilder in Object-Storage-Bucket auslagern
Code nach GitHub bringen (Versionskontrolle)

Phase 3 — Deployment-Pipeline

Pipelines bauen, damit INT und PRD automatisiert genutzt werden können

Phase 4 — Go-Live & Weiterentwicklung

DNS-Umstellung: cargraphic.de auf den neuen PRD-Server umbiegen
Weitere Entwicklungen und Verbesserungen auf der neuen Infrastruktur

DNS-Umstellung: Providerdienste → Cloudflare MX-Records + SPF + Nameserver-Wechsel

Ausgangslage

Domain cargraphic.de ist bei Providerdienste registriert (Registrar). Für die Migration ist kein Registrar-Transfer nötig — die Domain bleibt bei Providerdienste. Nur die Nameserver werden auf Cloudflare umgestellt, damit die DNS-Verwaltung zentral in Cloudflare liegt. ZU PRÜFEN: Was ist sinnvoller: Domainumzug oder Nameserver umstellen

Ziel: Managen der Domain durch Cloudflare

Vorgehen

Domain cargraphic.de als neue Zone in Cloudflare anlegen
Alle bestehenden DNS-Einträge 1:1 in Cloudflare nachbilden, bevor die Nameserver umgestellt werden — insbesondere A-/AAAA-Records, MX-Records, SPF/DKIM/DMARC (TXT), sonstige CNAME-/TXT-Records
Erst wenn alle Records korrekt hinterlegt sind: Nameserver bei Providerdienste auf die Cloudflare-NS umstellen
Propagierung abwarten (wenige Stunden, bis zu 24–48h möglich)
Erst danach A-/AAAA-Records in Cloudflare auf den neuen Hetzner-PRD-Server umbiegen

E-Mail-Situation: Ergebnis der DNS-Prüfung (09.08.2026)

Alle drei Domains nutzen denselben externen Mail-Security-Gateway antispameurope.de (Hornetsecurity) mit identischer MX-Prioritätsstruktur. Die Mail-Zustellung läuft nicht über Providerdienste-eigene Mailserver, sondern extern — risikoärmer beim Nameserver-Wechsel als ursprünglich angenommen.

DomainMigration zu CloudflareStatus

cargraphic.com Ja Kein Mail-Risiko

cargraphicts.com Ja Kein Mail-Risiko

cargraphic.de Voraussichtlich ja MX extern — SPF/DKIM/DMARC vorher prüfen

SPF-Records je Domain (Stand: 09.08.2026)

DomainSPF-RecordBesonderheit

cargraphic.de v=spf1 a mx ip4:24.134.22.149 include:spf.hornetsecurity.com -all Enthält hartcodierte Providerdienste-IP

cargraphic.com (kein TXT/SPF-Record vorhanden) NS aktuell virtualhosts.de

cargraphicts.com v=spf1 a mx include:spf.crsend.com ~all Nutzt CleverReach (Newsletter)

Kritisch: IP-Update im SPF-Record nach Server-Umzug

Die IP 24.134.22.149 im SPF-Record von cargraphic.de autorisiert den aktuellen Providerdienste-Server zum direkten Mailversand (z. B. TYPO3-Kontaktformulare über PHP mail()). Der SPF-Record endet mit -all (harter Fail) — nach dem Umzug auf Hetzner muss diese IP durch die neue Server-IP ersetzt werden, sonst werden vom Webserver versendete Mails als Spoofing gewertet und abgelehnt.

# Neuer SPF-Record in Cloudflare:
v=spf1 a mx ip4:<NEUE-HETZNER-PRD-IP> include:spf.hornetsecurity.com -all

cargraphicts.com: Beim Nachbilden der TXT-Records in Cloudflare muss include:spf.crsend.com erhalten bleiben, nicht durch das Hornetsecurity-Include der anderen Domains ersetzt werden — sonst bricht der Newsletter-Versand über diese Domain.

Object Storage — Konfiguration & Strategie Bucket-Setup + CDN + _processed_-Handling

Bucket-Konfiguration (final)

EinstellungWert

StandortFalkenstein (DE)

Namecargraphic-prd (final, nachträglich nicht änderbar)

Object LockDeaktiviert

SichtbarkeitÖffentlich (read-only) — nötig für Frontend-Auslieferung über CDN

Preis~€7,72/Monat je Bucket, 2 Buckets (PRD + INT) = ~€15,44/Monat

fileadmin-Strategie: Object Storage statt lokales Filesystem

Auslagerung auf Hetzner Object Storage (S3-kompatibel), Anbindung via FAL-Treiber (z. B. flownative/aws-s3). Kein File-Sync-Problem im Deploy-Flow — Code wird deployed, Assets bleiben zentral im Bucket.

Original-Assets → Bucket

Bilder, Dokumente, Videos — alles, was redaktionell hochgeladen wird, wandert direkt in den Bucket.

Kein shared_dirs-Handling für fileadmin/ im Deployer-Setup nötig.

Empfehlung für den Start: INT zeigt direkt auf den PRD-Bucket (kein Sync nötig).

_processed_ → lokal auf dem Server

TYPO3 erzeugt im _processed_-Verzeichnis viele kleine Bild-Derivate (Thumbnails, Crops) bei Uploads/Rendering.

Diese bleiben lokal auf dem Server gecacht, nicht bei jedem Request live aus dem Bucket geladen.

Üblicher Ansatz bei TYPO3-Setups mit externem FAL-Storage — vermeidet Latenz-Probleme.

Hetzner-Hinweis: Object Storage ist kein CDN

Die direkte Auslieferung großer Mengen statischer Inhalte an Endnutzer über den Bucket wird von Hetzner explizit nicht empfohlen (schlechte Performance, mögliche Überlastung). Lösung: Cloudflare als CDN-Layer vor den Bucket — Free-Tier ausreichend, bereits als DNS-Provider im Einsatz.

Vor dem v14-Rebuild klären

Ob im TYPO3-8.7-Content noch direkte fileadmin/...-Pfadverweise statt sauberer FAL-Referenzen existieren — sonst brechen beim Content-Import Bilder.

DB-/Bucket-Refresh-Workflow (PRD → INT) mysqldump + rclone sync

Datenbank

# Datenbank von PRD nach INT kopieren
mysqldump -u user -p cargraphic_prod > dump.sql

# auf INT:
mysql -u user -p cargraphic_stage < dump.sql

# Nach Import: sys_domain-Einträge bzw. Site-Konfiguration
# auf INT-URLs umbiegen

Bucket (nur falls INT einen eigenen Bucket nutzt)

# Nur bei Bedarf ausführen (z.B. vor größerem INT-Test),
# nicht bei jedem Deploy automatisiert

rclone sync hetzner-prd:cargraphic-prd-bucket \
            hetzner-int:cargraphic-int-bucket

Bei der empfohlenen Pointer-Strategie (INT zeigt auf PRD-Bucket) entfällt der Bucket-Sync komplett.

TYPO3-Update, Server & Deployment