Kann ein klassisches PHP-CMS, das am Server Datenbank, Dateien und Sessions braucht, auf einer serverlosen Plattform laufen, die eigentlich für statische Sites und Edge-Funktionen gebaut wurde? Ja, das funktioniert: Ein vollständiges TYPO3 14.3 inklusive Backend läuft als Container-Image bei Vercel. Wie der Aufbau aussieht, wo die Grenzen liegen und für welche Projekte sich das eignet, beschreiben wir in diesem Artikel.
typo3-camino-vercel ist ein Community-Starter (kein offizielles TYPO3-Paket), der die offizielle TYPO3-Camino-Distribution als PHP-8.5-Container bei Vercel betreibt. Die Live-Demo ist ein mehrsprachiger Camino-de-Compostela-Reiseführer – Frontend, Backend, Suche und Visual Editor funktionieren vollständig.
Live-Demo: typo3-camino-vercel.vercel.app
Ein vollständiges TYPO3 14.3 mit Camino-Distribution, fünf Sprachen (EN, DE, ES, ZH, HU), Solr-Suche und Visual Editor – als Container-Image bei Vercel. Das Backend liegt unter /typo3/.
Inhaltsverzeichnis
Was es wirklich ist
Echtes Full-Stack-TYPO3 – weder headless noch statisch exportiert.
Die Herausforderung
Ein zustandsbehaftetes CMS auf zustandsloser Infrastruktur.
Kurzfassung
Das Wichtigste in Kürze: zwei Produkte, klare Grenzen.
Mini-Anleitung
Von null zur eigenen Seite – ohne bestehendes Vercel-Konto.
Grenzen
Cold Starts, Upload-Limit, kein Cron-Daemon, kein Mailserver.
Wann es passt
Klare Empfehlung, wofür die Plattform taugt – und wofür nicht.
Was Camino-on-Vercel wirklich ist
Um Missverständnisse zu vermeiden: Es handelt sich weder um einen statischen Export noch um ein Headless-Setup. Hier läuft echtes, vollständiges TYPO3 – mit Backend – als Dockerfile-basierter Container-Service auf Vercel Services (von Vercel derzeit als Beta gekennzeichnet).
Die Projekt-Doku fasst die wichtigste Erfahrung sinngemäß so zusammen: Nicht die PHP-Kompatibilität ist das Problem, sondern die Anpassung eines zustandsbehafteten CMS (samt JVM-Suchmaschine) an ein zustandsloses Funktionsmodell, das auf null skaliert. PHP 8.5 läuft problemlos; die eigentliche Arbeit steckt in der Zustandshaltung.
TYPO3 14.3.5
Offizielle Camino-Distribution
Kein Fork des Cores. Frontend, Backend, Redaktion – alles vorhanden.
PHP 8.5 + nginx
Alpine-Linux-Container
PHP-FPM und nginx statt Apache/mod_php, das Image ist bewusst schlank gehalten.
Vercel Services (Beta)
Region fra1 (Frankfurt)
Dockerfile-basierter Container-Service. Skaliert auf null, wenn niemand die Seite besucht.
Visual Editor + 5 Sprachen
Community-Extension friendsoftypo3/visual-editor 1.9
Maßgeblich entwickelt von Matthias Vogel („Kanti") von der anders und sehr GmbH. Inline-Bearbeitung im Frontend, strikte Übersetzungen in EN, DE, ES, ZH und HU.
Die zentrale Herausforderung: Zustand
Ein CMS braucht dauerhaften lokalen Zustand: Datenbank, Dateien, Cache, Suchindex, Cron-Jobs. Vercel stellt stattdessen einen flüchtigen Container bereit, der auf null herunterskaliert. Einen allgemeinen Schalter „Persistenz einschalten" gibt es nicht – jede Art von Zustand braucht einen eigenen externen Baustein.
| Baustein | Umsetzung bei Vercel |
|---|---|
| Datenbank | Externe, dauerhafte SQL-DB über DATABASE_URL (Postgres/MySQL). SQLite nur als Smoke Test. |
| Dateien (FAL) | Eigener FAL-Treiber für Vercel Blob (oder S3-kompatibel). Demo-Bilder sind ins Image gebacken. |
| Cache | Optional Redis über redis:// bzw. rediss:// für geteilten Cache zwischen Instanzen. |
| Suche | EXT:solr 14 (aktuell Release Candidate) + Apache Solr 10 (nur Demo). Produktiv: externes, gemanagtes Solr. |
| Jobs / Cron | Geschützte Vercel-Cron-Endpunkte. Kein Cron-Daemon im Image, lange Jobs in kurze Batches teilen. |
| HTML-Caching | Anonyme, cookiefreie GET-Antworten erhalten eine Edge-TTL – Vercel antwortet ohne PHP. |
Vercel beantwortet nicht, wo die Daten liegen – die Plattform zwingt einen, jede Zustandsart bewusst nach außen zu legen. Dadurch lässt sich Baustein für Baustein nachvollziehen, was ein serverloses TYPO3 tatsächlich braucht.
Cold Start vs. Warm Request: die Zahlen
Nach einem Idle muss der Container erst wieder hochfahren – das kostet spürbar Zeit. Ist er warm, antwortet TYPO3 in Sekundenbruchteilen.
| Zustand | Antwortzeit (Median) |
|---|---|
| Cold Start (nach Idle) | ≈ 10–12 s |
| Warm Request – Frontend | 0,14 s |
| Warm Request – Backend | 0,26 s |
| Suche (warm) | 0,37 s |
Redis, mehr CPU und PHP-JIT haben den Cold Start dagegen nicht beseitigt. Auch ein um 53 Prozent verkleinertes App-Image hat an den rund zwölf Sekunden Aktivierungszeit kaum etwas geändert. Geholfen hat am Ende vor allem, die Anwendung warm zu halten – auf dem Pro-Plan über einen Warm-up-Cron im Minutentakt – und anonyme Seiten über den Edge-Cache auszuliefern.
Kurzfassung für Entscheider
Das Ergebnis in einem Satz: TYPO3 14.3 und die Camino-Distribution laufen als Vercel-Container-Image korrekt, ein normaler Warm Request ist schnell – die Herausforderung ist die Zustandshaltung, nicht PHP.
Daraus sind bewusst zwei Produkte entstanden, weil eine einzelne Konfiguration nicht beide Ziele gleichzeitig abdecken kann:
1. Ein-Klick-Test
Zum Ausprobieren, kostenlos
Nur die TYPO3-App mit temporärer SQLite, optional Blob, ohne Solr, ohne Cron. Zielgruppe: nicht-technische Testende auf dem Hobby-Plan. Anonyme Seiten bekommen automatisch eine 5-Minuten-Edge-Policy.
2. Professionelles Hosting
Für den echten Betrieb
Pro-/Enterprise-App plus externe SQL-DB, Blob/S3, optional Redis, gemanagtes externes Solr sowie geschützter Scheduler und ein Warm-up-Cron im Minutentakt. Zielgruppe: eine betreute Redaktionsseite.
Wofür es taugt
Demos, Evaluierung, Vorschauen und Prototypen. Lese-lastige Seiten mit geringem bis mittlerem Verkehr (externe DB + Blob). Redaktionsseiten, deren Team eine Warm-up-Strategie akzeptiert und überwacht.
Wofür (noch) nicht
Hochkritische Produktion mit hartem Latenz-SLA für den ersten Aufruf. Dafür bleibt ein dauerhaft laufendes TYPO3 (Always-on-Origin) die richtige Wahl – Vercel dient dann als CDN davor.
Cold Starts lagen nach Idle bei rund 10 bis 12 Sekunden, Warm Requests normalerweise unter 0,5 Sekunden. Vercel bietet für diesen Container-Image-Pfad derzeit keine Mindest-Instanz-Einstellung – regelmäßiges Warm-up mildert das Problem, garantiert aber nicht, dass Cold Starts ganz ausbleiben.
Mini-Anleitung: von null zur eigenen TYPO3-Seite bei Vercel
Diese Anleitung setzt nichts voraus – auch kein bestehendes Vercel-Konto. Die Schritte 1 bis 8 ergeben den kostenlosen Ein-Klick-Test, die Schritte 9 bis 12 machen daraus eine dauerhafte Installation. Alles, was Geld kostet, ist mit 💰 markiert.
Phase A: Kostenloser Ein-Klick-Test
1. Kostenloses Vercel-Konto anlegen. Auf vercel.com/signup mit GitHub, GitLab, Bitbucket oder E-Mail registrieren und den Hobby-Plan wählen (0 €/Monat für private, nicht-kommerzielle Projekte). Für den Test genügt Hobby.
2. Einen TYPO3-Verschlüsselungsschlüssel erzeugen (wird beim Deploy eingefügt):
openssl rand -hex 483. Ein starkes Admin-Passwort erzeugen und mit dem Schlüssel im Passwort-Manager speichern – niemals in Git committen:
openssl rand -base64 324. Auf den „Deploy with Vercel"-Button im Repository klicken. Er öffnet Vercels Klon-Ablauf und legt das Repo in Ihrem eigenen GitHub-Konto an – kein manuelles Fork, keine CLI nötig.
5. Git-Konto autorisieren, wenn Vercel danach fragt. So kann Vercel das geklonte Repo erstellen und bei jedem Push automatisch neu deployen.
6. Den öffentlichen Vercel-Blob-Speicher ausgewählt lassen. Der Button legt automatisch einen Blob-Store an – damit bleiben hochgeladene Dateien dauerhaft erhalten (kostenlos im Rahmen der Hobby-Grenzen).
7. Die drei Pflicht-Umgebungsvariablen eintragen:
TYPO3_SETUP_ADMIN_USERNAME=admin
TYPO3_SETUP_ADMIN_PASSWORD=<your-long-random-password>
TYPO3_ENCRYPTION_KEY=<96-random-hex-chars>Es gibt kein Standard-Passwort – der Login ist exakt das, was Sie hier eintragen. DATABASE_URL im Gratis-Modus leer lassen.
8. Auf „Deploy" klicken und warten, bis der Status „Ready" ist. Ein Git-Push ist nicht sofort online – Vercel muss die Container-Images erst bauen und aktivieren. Danach die generierte URL öffnen; das Backend liegt unter /typo3/. Der erste Aufruf kann ein Cold Start sein (ca. 10–12 s), Warm Requests liegen danach im Bereich von Sekundenbruchteilen.
Die Ein-Klick-SQLite-Datenbank ist temporär – ein reiner Smoke Test. Solange keine echte Datenbank angebunden ist, können Seitenänderungen, Datensätze und Backend-Sessions verschwinden oder sich zwischen Instanzen unterscheiden. Legen Sie noch keine Inhalte an, die erhalten bleiben sollen.
Phase B: Dauerhaft machen
9. Externe Datenbank anbinden. Eine Postgres- oder MySQL-kompatible DB nahe fra1 anlegen – kostenlose Optionen sind etwa Neon oder Supabase (Postgres) bzw. TiDB Cloud (MySQL-kompatibel). 💰 Kostenlos im Kontingent, produktive Größen kosten. Als Production-Variable in den Vercel-Projekteinstellungen eintragen:
DATABASE_URL=postgresql://user:password@host/database?sslmode=require10. Die leere Datenbank einmalig initialisieren. Vorübergehend TYPO3_AUTO_SETUP=1 und TYPO3_BOOTSTRAP_EMPTY_DATABASE=1 setzen, deployen, Frontend und Backend-Login prüfen – dann beide wieder auf 0 setzen und erneut deployen. Das entfernt vermeidbare DB-Prüfungen aus jedem Container-Start.
11. (Optional) Die Camino-Demo einspielen – über den geschützten Wartungs-Endpunkt, da es auf Vercel keine Shell gibt:
curl --request POST \
--header "Authorization: Bearer $CRON_SECRET" \
https://your-project.vercel.app/api/maintenance/camino-demo.php12. Eigene Domain verbinden. In den Vercel-Projekteinstellungen unter „Domains" hinzufügen (Standard-Ablauf). 💰 Die Domain-Registrierung selbst ist ein separater Posten; kommerzielle Nutzung erfordert Pro.
Phase C: Professioneller Betrieb (💰 kostenpflichtig)
Der produktive Betrieb braucht Vercel Pro oder Enterprise – das ist der wesentliche Fixkostenblock. Die Standard-Konfiguration (vercel.json) bleibt bewusst Hobby-kompatibel und cron-frei; der Warm-up-Cron im Minutentakt und der 15-Minuten-Scheduler stecken in einem eigenen Pro-Profil (vercel.pro.json), das per Skript ausgerollt wird:
# generate and set the warm-up secret
openssl rand -hex 32
vercel env add CRON_SECRET production
# roll out the Pro config (warmer + scheduler)
VERCEL_SCOPE=<team-slug> scripts/deploy-pro.sh
# always verify: both cron jobs must be listed
vercel crons ls --scope <team-slug>Früher fiel ein normaler Git-Deploy still auf das cron-freie Ein-Klick-Profil zurück. Diese Falle ist inzwischen weitgehend entschärft: Das Vercel-Projekt des Starters ist bewusst nicht mehr Git-verbunden, und ein Push auf main rollt das Pro-Profil (Warmer + Scheduler) automatisch über den CI-Deploy-Job mit deploy-pro.sh aus, sobald das VERCEL_TOKEN-Secret hinterlegt ist. Das manuelle Skript bleibt als Fallback. Prüfen Sie nach jedem Release trotzdem mit vercel crons ls, ob beide Cron-Jobs registriert sind – sonst läuft das Warmhalten unbemerkt nicht.
Grenzen und ehrliche Vorbehalte
Die folgenden Einschränkungen sind in der Projekt-Doku belegt. Wer TYPO3 bei Vercel produktiv einsetzt, sollte sie kennen.
Wann sich Vercel für TYPO3 eignet
| Szenario | Gut geeignet | Besser klassisch hosten |
|---|---|---|
| Demos & Prototypen | Ideal – schnell, günstig, wegwerfbar | unnötig |
| Lese-lastige Kampagnenseite | Gut mit externer DB + Blob + Edge-Cache | möglich |
| Redaktionsseite mit Betreuung | Machbar mit Warm-up-Strategie (Pro-Plan) | oft einfacher |
| Hohe Backend-/Editor-Last | Schwierig – Backend ist nicht edge-cachebar | empfohlen |
| Hartes Latenz-SLA beim Erstaufruf | Nicht empfohlen | Pflicht: Always-on-Origin |
| Immer verfügbare Suche | Nur mit externem Solr | empfohlen |
Kurz gesagt: Für Vorschauen, Evaluierung und lese-lastige Seiten ist ein serverloses TYPO3 eine interessante, günstige Option. Für hochkritische Produktion mit garantierter Erstaufruf-Latenz bleibt ein Always-on-Origin die richtige Architektur – mit Vercel davor als CDN.
Auch für Ämter interessant
Dass ein vollständiges TYPO3 heute bei Vercel läuft, erweitert die Optionen auch im öffentlichen Sektor. Für Vorschau-Umgebungen, Kampagnen-Microsites und lese-lastige Informationsseiten kann eine serverlose Auslieferung mit externer, DSGVO-geprüfter Datenbank die Betriebskosten senken. Kritische Kernportale bleiben dabei weiterhin auf dauerhaft laufender, souveräner Infrastruktur.
Wie ein modernes, agentenfähiges TYPO3 v14 für Verwaltungs-Websites aussieht, beschreiben wir ausführlich in Österreich + TYPO3: Smarte Government-Websites nach deutschem Vorbild.
Fazit
typo3-camino-vercel zeigt zwei Dinge. Erstens läuft ein vollständiges TYPO3 14.3 – Backend inklusive – technisch sauber als serverloses Container-Image. Zweitens steckt der schwierige Teil nicht in PHP, sondern im Zustand: Datenbank, Dateien, Cache, Suche und Cron müssen jeweils bewusst nach außen gelegt werden, und Cold Starts bleiben ohne Always-on-Instanz eine reale Einschränkung.
Als Referenz, wie sich jede Zustandsart eines PHP-CMS serverlos auslagern lässt, ist das Projekt sehr nützlich – und mit der Mini-Anleitung oben steht in wenigen Minuten eine eigene, laufende Instanz. Ob Vercel für ein konkretes Projekt die richtige Wahl ist, hängt vor allem an einer Frage: Wie wichtig ist die Antwortzeit beim allerersten Aufruf, also beim Cold Start?
Links und weitere Informationen
- Repository: github.com/dirnbauer/typo3-camino-vercel
- Live-Demo: typo3-camino-vercel.vercel.app
- Verwandter Artikel: Österreich + TYPO3: Smarte Government-Websites nach deutschem Vorbild
- Beratung: Sie überlegen, TYPO3 zu hosten oder zu modernisieren? Schreiben Sie uns an office@webconsulting.at