TYPO3 14 LTS Camino: Mit Composer, DDEV und GitHub Actions schnell zur deploybaren Website (Projekt landolsi-typo3-camino14)

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:

ddev start

ddev composer install

Danach 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:

https://camino14.landolsi.de/

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:

composer install --no-dev --prefer-dist --no-interaction

In 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.