Warum TYPO3 14 LTS + Camino gerade jetzt spannend ist
Wer 2026 professionelle Websites baut, braucht zwei Dinge gleichzeitig: Geschwindigkeit beim Projektstart und eine saubere Basis für Betrieb, Wartung und Weiterentwicklung. Genau in dieser Schnittmenge liegt die Kombination aus TYPO3 14 LTS, einem Composer-basierten Setup, lokaler Entwicklung mit DDEV und einem pragmatischen Theme-Ansatz wie dem TYPO3 Theme Camino.
Wichtig ist dabei die korrekte Einordnung: Camino ist nicht „mit TYPO3 14 LTS gekommen“, sondern wird als kompatibles TYPO3-Theme bzw. Paket genutzt, um schneller zu einem modernen, konsistenten Frontend zu gelangen. TYPO3 selbst liefert die stabile Enterprise-Basis; Camino liefert die Startbeschleunigung im Frontend.
In diesem Artikel geht es um mein Projekt landolsi-typo3-camino14: eine Demo-Website auf Basis von TYPO3 14 LTS, die bewusst produktionsnah aufgesetzt wurde – inklusive Branching-Strategie, CI/CD mit GitHub Actions, Deployment auf einen CloudPanel-Server und klarer Trennung zwischen Code und Uploads in public/fileadmin/.
Ausgangspunkt: ein schnelles, professionelles TYPO3-Testprojekt – aber produktionsnah
Das Ziel von landolsi-typo3-camino14 war nicht, „noch eine lokale TYPO3-Installation“ zu bauen, sondern ein Setup, das sich wie ein echtes Kundenprojekt anfühlt:
Modernes TYPO3 14 LTS als langfristig wartbare Basis
Composer als Standard-Workflow für Dependencies und reproduzierbare Builds
DDEV für schnelle lokale Entwicklung, Onboarding und wiederholbare Umgebungen
Camino als Theme-Grundlage, um Layout und Komponenten nicht bei Null zu starten
GitHub Actions für automatisiertes Deployment des Codes auf einen CloudPanel-Server
Klare Datenstrategie: Uploads in public/fileadmin/ bleiben außerhalb von Git und werden separat synchronisiert
So entsteht ein Projekt, das sowohl für Entwickler als auch für Entscheider nachvollziehbar ist: schnelle Ergebnisse, aber ohne Abkürzungen, die später teuer werden.
Tech Stack im Überblick
Projektname: landolsi-typo3-camino14
TYPO3: 14 LTS
Theme: TYPO3 Theme Camino als kompatibles Theme/Paket
Setup: Composer-basiert
Lokale Entwicklung: DDEV
PHP: 8.5
Docroot: public
Deployment-Ziel: CloudPanel-Server
CI/CD: GitHub Actions für Code-Deployment
Branching: main / develop plus Feature- und Hotfix-Branches
Production-Domain: camino14.landolsi.de
Inhalte: Demo-Website mit Startseite, Leistungen, Projekte/Referenzen, Kontakt und Mehrsprachigkeit DE/EN
Extras: Cookie-/Consent-Banner, OpenPanel-Tracking nur nach Statistik-Consent, Color-Switcher, Carousel und fileadmin-Sync über DDEV
Warum Composer + DDEV eine saubere Grundlage sind
TYPO3 ist seit Jahren im professionellen Umfeld stark – und der Composer-Workflow ist einer der Gründe, warum TYPO3 auch 2026 eine sehr solide Wahl bleibt. Composer sorgt dafür, dass Abhängigkeiten wie TYPO3 Core, Extensions und Tools reproduzierbar installiert werden. Das reduziert „Works on my machine“-Probleme und macht Deployments deutlich planbarer.
DDEV ergänzt das ideal: Es standardisiert die lokale Umgebung mit Webserver, PHP-Version und Datenbank und macht Onboarding schnell. Gerade in Teams oder bei Agenturprojekten ist das ein echter Produktivitätshebel: Neue Entwickler können das Projekt starten, ohne erst manuell PHP-Extensions, vHosts oder Datenbanken zu konfigurieren.
Konkrete Schritte: lokales Setup mit DDEV
In landolsi-typo3-camino14 ist der Webroot bewusst auf public gesetzt. Das ist im Composer-Kontext üblich und erhöht die Sicherheit, weil nicht der gesamte Projektordner öffentlich erreichbar ist.
Ein typischer Start in der lokalen Umgebung sieht so aus:
Terminal
ddev startTerminal
ddev composer installDanach folgt – je nach Projektstand – entweder die Installation von TYPO3 oder das Einspielen einer Datenbank aus einer Staging- oder Production-Quelle. Entscheidend ist: Der Weg ist reproduzierbar, dokumentierbar und für Teams skalierbar.
Realistische Caveats, die man früh adressieren sollte
PHP 8.5: Bei sehr neuen PHP-Versionen sollte geprüft werden, ob alle benötigten Extensions, Libraries und Server-Komponenten bereits kompatibel sind.
Composer-Plugins und Scripts: In professionellen Setups sollte klar sein, welche Composer-Scripts beim Installieren oder Aktualisieren laufen.
Environment-Konfiguration: TYPO3-Konfigurationen wie Datenbank, Trusted Hosts und Application Context müssen sauber zwischen Local, Staging und Production getrennt sein.
Was Camino für den schnellen Website-Aufbau bringt
Camino ist in diesem Projekt der pragmatische Beschleuniger: Statt ein Frontend von Grund auf zu entwerfen und alle Komponenten selbst zu bauen, liefert ein Theme wie Camino eine konsistente Grundlage – typischerweise mit Layout-Patterns, Komponenten, sinnvoller Typografie und einem Designsystem-Ansatz.
Das bedeutet nicht, dass man „fertig“ ist. Aber man startet nicht bei Null. Für viele Projekte ist genau das der Sweet Spot: schnell eine professionelle Optik, klare Struktur und ein gemeinsames Vokabular für Komponenten – und dennoch genug Raum für individuelle Anpassungen.
Was ein Theme nicht ersetzt
Kein Content-Konzept: Seitenstruktur, Informationsarchitektur, Tonalität und Redaktionsprozesse bleiben entscheidend.
Keine Deployment-Strategie: Ein Theme löst nicht die Fragen rund um CI/CD, Server-Setup, Backups oder Rollbacks.
Keine Performance-Disziplin: Auch mit Theme müssen Bildoptimierung, Caching, kritische CSS-/JS-Pfade und Tracking sauber umgesetzt werden.
Praxischeck: PageSpeed Insights für camino14.landolsi.de
Nach dem technischen Aufbau habe ich die Demo-Website zusätzlich mit Google PageSpeed Insights geprüft. Mir war dabei wichtig, nicht nur lokal zu testen, sondern die öffentlich erreichbare Domain unter realistischen Bedingungen zu analysieren:
Das Ergebnis zeigt, dass ein TYPO3-Projekt mit sauberem Setup, schlankem Theme-Einsatz und kontrolliertem Tracking sehr gute technische Werte erreichen kann. Nach einem weiteren Test erreichte die mobile Auswertung folgende Ergebnisse:
Performance: 100
Barrierefreiheit: 100
Best Practices: 100
SEO: 100
Besonders wichtig ist dabei die Einordnung: PageSpeed Insights unterscheidet zwischen Felddaten aus echten Nutzerdaten und Labordaten aus einer technischen Analyse. Für diese Demo-Domain lagen zum Zeitpunkt des Tests noch keine ausreichenden Nutzerdaten vor. Das ist bei neuen oder wenig besuchten Demo-Projekten normal und bedeutet nicht, dass die Website schlecht performt. Es bedeutet nur, dass Google noch keine belastbaren realen Nutzerdaten für diese URL anzeigen kann.
Für mich ist dieser Test trotzdem wertvoll, weil er früh zeigt, ob die technische Basis stimmt. Gerade bei einem neuen TYPO3-Setup möchte ich nicht erst nach dem Livegang feststellen, dass Bilder zu groß sind, JavaScript unnötig blockiert, Fonts schlecht geladen werden oder Tracking-Skripte die Performance verschlechtern.
Warum die 100/100/100/100-Werte kein Zufall sind
Die PageSpeed-Werte hängen nicht nur vom Theme ab. Entscheidend ist das Zusammenspiel aus sauberem TYPO3-Setup, schlankem Frontend, sinnvoller Asset-Strategie und kontrollierter Einbindung externer Dienste. In diesem Projekt wurden mehrere Punkte bewusst berücksichtigt:
Bilder werden nicht unnötig groß ausgeliefert.
Tracking wird erst nach Statistik-Consent aktiviert.
Der Docroot ist sauber auf public gesetzt.
Das Theme wird als Grundlage genutzt, aber nicht mit unnötigen Erweiterungen überladen.
Deployment und Dateistruktur sind so vorbereitet, dass später keine technischen Altlasten entstehen.
Der Test zeigt damit genau das, was ich mit diesem Projekt überprüfen wollte: TYPO3 14 LTS und Camino können eine sehr solide Grundlage für moderne Websites sein, wenn man das Setup nicht nur optisch, sondern auch technisch sauber aufbaut.
Wichtig: Performance bleibt ein laufender Prozess
Ein PageSpeed-Wert von 100 in allen Kategorien ist ein sehr gutes Signal, aber kein Freifahrtschein. Sobald neue Inhalte, Bilder, externe Skripte, Tracking-Tools oder komplexere Komponenten hinzukommen, können sich die Werte verändern. Deshalb sollte Performance nicht als einmaliger Check verstanden werden, sondern als Teil des laufenden Entwicklungs- und Wartungsprozesses.
Gerade bei TYPO3-Projekten lohnt es sich, PageSpeed Insights regelmäßig zu nutzen: nach größeren Inhaltspflegen, nach Theme-Anpassungen, nach Extension-Updates und vor wichtigen Releases. So bleibt die technische Qualität messbar und Probleme werden früh erkannt.
Wie die Demo-Website aufgebaut wurde
Die Demo-Website auf camino14.landolsi.de ist bewusst so strukturiert, dass typische Anforderungen abgedeckt sind:
Startseite als Einstieg mit klarer Value Proposition und schnellen Einstiegen
Leistungen als strukturierte Leistungsdarstellung für Nutzer und Suchmaschinen
Projekte/Referenzen als Portfolio- bzw. Case-Study-Bereich
Kontakt als Conversion-Ziel mit klaren Kontaktmöglichkeiten
Mehrsprachigkeit DE/EN als realistische Anforderung für viele Unternehmen
Zusätzlich wurden typische Professionalitäts-Features integriert: ein Consent-Banner, ein Color-Switcher für Branding-Varianten, ein Carousel für visuelle Inhalte und ein Tracking-Setup, das Datenschutz ernst nimmt.
Mehrsprachigkeit: früh einplanen, nicht nachrüsten
Mehrsprachigkeit ist ein klassischer Punkt, der in Projekten oft zu spät berücksichtigt wird. In einem produktionsnahen Setup lohnt es sich, früh zu klären:
Welche Inhalte sind wirklich übersetzt, welche bleiben identisch?
Wie werden URLs und Slugs pro Sprache gehandhabt?
Wie sieht der Redaktionsprozess für Übersetzungen aus?
Gerade mit TYPO3 ist Mehrsprachigkeit gut beherrschbar – aber sie wird deutlich einfacher, wenn Struktur und Content-Modelle von Anfang an darauf ausgelegt sind.
Vorteile für Redakteure und Entwickler
Für Redakteure
Konsistentes Design: Durch die Theme-Grundlage wirken Seiten auch bei mehreren Redakteuren wie aus einem Guss.
Schneller Content-Aufbau: Wiederverwendbare Komponenten reduzieren Abstimmungsaufwand.
Mehrsprachigkeit im Alltag: Klare Struktur erleichtert Pflege und Übersetzungen.
Für Entwickler
Reproduzierbarkeit: Composer und DDEV minimieren Umgebungsdrift.
Saubere Trennung: Code liegt in Git, Uploads werden separat behandelt und Datenbank-Syncs laufen über definierte Wege.
CI/CD-Fähigkeit: Automatisiertes Deployment ist von Anfang an Teil des Systems.
DevOps: GitHub Actions, Deployment auf CloudPanel und Production-Sync
Ein Kernziel des Projekts war, dass Deployments nicht per Hand passieren müssen. GitHub Actions übernimmt das Code-Deployment, während DDEV für lokale Workflows und für definierte Pull-/Push-Prozesse für Datenbank und fileadmin genutzt wird.
Wichtig: GitHub Actions deployt nur Code. Das ist bewusst so, weil Uploads und Inhalte nicht in Git gehören und weil Datenbankzustände nicht per Code-Deployment „mitgerollt“ werden sollten.
Branching-Strategie: main/develop plus Feature-/Hotfix-Branches
Die Branching-Strategie ist klassisch und bewährt:
develop für laufende Entwicklung und Integration
main als stabiler Stand, der deployt wird
feature/* für isolierte Änderungen
hotfix/* für schnelle Produktionsfixes
Das ist nicht die einzige mögliche Strategie, aber sie ist für Agenturen, Freelancer und Teams gut verständlich und lässt sich sauber mit CI/CD kombinieren.
Deployment auf CloudPanel: pragmatisch und servernah
CloudPanel ist in vielen Setups eine praktische Wahl, weil es Serververwaltung und Webhosting-Aspekte übersichtlich zusammenführt. Für TYPO3-Projekte ist dabei entscheidend:
Docroot korrekt setzen: auf public
PHP-Version passend wählen: hier PHP 8.5
Schreibrechte korrekt setzen: für Caches, Logs und Uploads
Deployments wiederholbar machen: möglichst automatisiert und nachvollziehbar
Ein typischer Build-Schritt im CI-Kontext ist das Installieren der Dependencies:
Terminal
composer install --no-dev --prefer-dist --no-interactionIn der Praxis wird dieser Schritt entweder im CI ausgeführt und das Ergebnis deployt oder auf dem Server nach dem Code-Sync. Welche Variante besser ist, hängt von Serverrechten, Build-Zeit, Caching und Sicherheitsanforderungen ab.
Praxispunkt: fileadmin gehört nicht in Git
Ein häufiger Fehler in TYPO3-Projekten ist, Uploads und Bilder in Git zu versionieren. Das führt schnell zu großen Repositories, Merge-Konflikten und unklaren Zuständigkeiten. In landolsi-typo3-camino14 ist deshalb klar:
Bilder und Uploads liegen in public/fileadmin/ und werden bewusst nicht in Git versioniert.
Das hat direkte Konsequenzen für Deployments. Viele Deployments nutzen rsync --delete, um entfernte Dateien zu entfernen, die lokal nicht mehr existieren. Das ist für Code sinnvoll, kann aber Uploads zerstören, wenn fileadmin im Zielverzeichnis liegt.
Wichtig: rsync so konfigurieren, dass fileadmin nicht gelöscht wird
Der Deployment-Workflow wurde deshalb so angepasst, dass public/fileadmin/ beim Sync geschützt ist, zum Beispiel über Excludes. Das ist ein kleiner, aber entscheidender Unterschied zwischen „Demo läuft lokal“ und „Website ist produktionsfähig“.
Zusätzlich wird DDEV genutzt, um fileadmin und je nach Bedarf Datenbankinhalte gezielt zu synchronisieren. So bleibt die Verantwortlichkeit klar:
GitHub Actions: Code ausrollen
DDEV: definierte Pull-/Push-Prozesse für Daten und Uploads
Das reduziert Risiken und macht Deployments wiederholbar, ohne Redaktionsarbeit zu gefährden.
Datenschutz und Professionalität: Consent-Banner + OpenPanel nur nach Zustimmung
Tracking ist ein typischer Stolperstein: technisch schnell eingebaut, rechtlich und organisatorisch aber anspruchsvoll. In diesem Projekt ist die Leitlinie klar:
OpenPanel-Tracking wird erst nach Statistik-Consent aktiviert.
Das ist nicht nur Compliance, sondern auch ein Qualitätsmerkmal. Wer professionell deploybare Websites baut, muss Datenschutz als Teil der technischen Architektur verstehen. Dazu gehören:
Saubere Kategorisierung im Consent-Banner, zum Beispiel notwendig und Statistik
Technische Entkopplung: Tracking-Skripte dürfen ohne Consent nicht laden
Dokumentierbarkeit: nachvollziehbar, wann was aktiviert wird
Lessons Learned aus landolsi-typo3-camino14
Produktionsnähe lohnt sich ab Tag 1: Branching, CI/CD und Deployment-Fragen früh zu klären spart später Zeit und Stress.
Theme als Beschleuniger, nicht als Endlösung: Camino hilft beim Start, aber Content-Modelle, Performance und UX müssen trotzdem bewusst gestaltet werden.
fileadmin-Strategie ist nicht optional: Wer das nicht sauber trennt, riskiert Datenverlust oder chaotische Repositories.
Consent ist ein Architekturthema: Tracking erst nach Zustimmung ist technisch sauberer und reduziert rechtliche Risiken.
Composer-Disziplin zahlt sich aus: Reproduzierbare Builds und klare Abhängigkeiten sind die Basis für stabile Deployments.
Performance früh messen: PageSpeed Insights hilft bereits in der Demo-Phase zu erkennen, ob Theme, Bilder, Tracking und technische Basis sauber zusammenspielen.
100 Punkte sind machbar: Auch ein TYPO3-Projekt kann sehr starke PageSpeed-Werte erreichen, wenn Frontend, Assets, Consent und Deployment sauber zusammenspielen.
Fazit: Für wen TYPO3 14 LTS + Camino sinnvoll ist
Die Kombination aus TYPO3 14 LTS und einem Theme wie Camino ist besonders sinnvoll, wenn man schnell zu einer professionellen Website kommen möchte, ohne bei Wartbarkeit und Deployment-Fähigkeit Kompromisse zu machen. TYPO3 liefert die robuste Plattform, Composer und DDEV machen den Workflow reproduzierbar, und Camino reduziert den initialen Frontend-Aufwand deutlich.
Ideal ist dieser Ansatz für:
Agenturen, die standardisierte Projektstarts und saubere Deployments brauchen
Freelancer, die schnell Ergebnisse liefern wollen, aber professionell deployen müssen
Technische Entscheider, die langfristige Wartbarkeit und klare Prozesse erwarten
TYPO3-Teams, die Mehrsprachigkeit, Consent und CI/CD als Standard sehen
Wenn dagegen ein hochgradig individuelles Designsystem oder sehr spezielle Frontend-Interaktionen gebraucht werden, ist Camino eher Startpunkt als Ziel. Genau so sollte man es auch einsetzen: pragmatisch, ehrlich und mit Blick auf die nächste Ausbaustufe.
Checkliste: eigenes TYPO3-14-Projekt mit Camino produktionsnah starten
Composer-Setup mit Docroot public festlegen
DDEV für lokale Entwicklung standardisieren
Branching mit main, develop, feature/* und hotfix/* definieren
CI/CD mit GitHub Actions für Code-Deployment einrichten
public/fileadmin/ aus Git ausschließen und Sync-Strategie definieren
rsync --delete nur mit Excludes bzw. Schutz für fileadmin nutzen
Consent-Banner integrieren und Tracking erst nach Zustimmung laden
Mehrsprachigkeit früh planen: Struktur, URLs und Redaktion
CloudPanel korrekt konfigurieren: PHP-Version, Docroot und Rechte
PageSpeed Insights regelmäßig prüfen, besonders nach größeren Änderungen
FAQ
Ist Camino ein offizieller Bestandteil von TYPO3 14 LTS?
Nein. Camino ist ein eigenständiges TYPO3-Theme bzw. Paket, das mit TYPO3 14 LTS kompatibel eingesetzt werden kann. TYPO3 selbst bleibt davon unabhängig.
Warum ist TYPO3 14 LTS für neue Projekte interessant?
TYPO3 14 LTS bietet eine moderne, langfristig wartbare Basis mit etabliertem Composer-Workflow, klaren Strukturen und guter Eignung für professionelle Websites inklusive Mehrsprachigkeit, Rollen/Rechte-Konzept und erweiterbarer Architektur.
Warum sollte public/fileadmin/ nicht in Git liegen?
Weil Uploads schnell groß werden, sich schlecht mergen lassen und im Deployment zu Datenverlust führen können. Besser ist eine separate Sync-Strategie, zum Beispiel über DDEV, und ein Deployment, das fileadmin schützt.
Wie spielt GitHub Actions mit DDEV zusammen?
GitHub Actions deployt den Code automatisiert auf den Server. DDEV wird lokal genutzt, um Entwicklung zu standardisieren und definierte Pull-/Push-Prozesse für Datenbank und fileadmin zu unterstützen. So bleiben Zuständigkeiten klar getrennt.
Sind PageSpeed-Werte von 100/100/100/100 mit TYPO3 realistisch?
Ja, solche Werte sind realistisch, wenn das Projekt technisch sauber aufgebaut ist. Entscheidend sind nicht nur TYPO3 und das Theme selbst, sondern auch Bildoptimierung, Caching, schlanke Assets, kontrolliertes Tracking und ein sauberer Deployment-Workflow. Die Werte können sich später verändern, wenn mehr Inhalte, externe Skripte oder komplexere Funktionen hinzukommen.