Kann ein klassisches, zustandsbehaftetes PHP-CMS auf einer serverlosen Plattform laufen, die eigentlich für JAMstack und Edge-Funktionen gebaut wurde? Die kurze Antwort: Ja – ein vollständiges TYPO3 14.3 inklusive Backend läuft als Container-Image bei Vercel. Die ehrliche Antwort ist etwas länger, und genau darum geht es in diesem Artikel.
typo3-camino-vercel ist ein Community-Starter (kein offizielles TYPO3-Paket), der die offizielle TYPO3-Camino-Distribution als PHP-8.4-Container bei Vercel betreibt. Die Live-Demo ist ein mehrsprachiger Camino-de-Compostela-Reiseführer – Frontend, Backend, Suche und Visual Editor, alles echt.
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, kein Headless, kein statischer Export.
Die Herausforderung
Ein zustandsbehaftetes CMS auf zustandsloser Infrastruktur.
Kurzfassung
Product-Manager-Summary: zwei Produkte, klare Grenzen.
Mini-Anleitung
Von null zur eigenen Seite – ohne bestehendes Vercel-Konto.
Grenzen
Kalte 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
Wichtig zum Verständnis: Das ist kein statischer Export und nicht headless. Es ist echtes, vollständiges TYPO3 – mit Backend – das als langlebig gedachtes Container-Image auf Vercels serverloser Container-Plattform (Fluid Compute) läuft.
Die entscheidende Einsicht des Projekts formuliert die Doku selbst sinngemäß so: Das Schwierige ist nicht die PHP-Kompatibilität, sondern ein zustandsbehaftetes CMS (und eine JVM-Suchmaschine) an ein zustandsloses, auf null skalierendes Funktionsmodell anzupassen. PHP 8.4 läuft problemlos. Die Arbeit steckt woanders.
TYPO3 14.3.4
Offizielle Camino-Distribution
Feste Version, kein Fork des Cores. Frontend, Backend, Redaktion – alles vorhanden.
PHP 8.4 + nginx
Alpine-Linux-Container
PHP-FPM und nginx statt Apache/mod_php. Das Image wurde bewusst schlank gebaut.
Vercel Container Images
Region fra1 (Frankfurt)
Fluid Compute, Performance-CPU. Skaliert auf null, wenn niemand die Seite besucht.
Visual Editor + 5 Sprachen
Visual Editor von „kanti" (anders und sehr)
Inline-Bearbeitung im Frontend, strikte Übersetzungen in EN, DE, ES, ZH und HU.
Die zentrale Herausforderung: Zustand
Ein CMS setzt dauerhaften lokalen Zustand voraus: Datenbank, Dateien, Cache, Suchindex, Cron-Jobs. Vercel gibt einem stattdessen einen flüchtigen, auf null skalierenden Container. Es gibt keinen generischen „Persistenz einschalten"-Schalter – jede Art von Zustand wird mit einem anderen externen Baustein gelöst.
| Baustein | Umsetzung bei Vercel |
|---|---|
| Datenbank | Externe, dauerhafte SQL-DB über DATABASE_URL (Postgres/MySQL). SQLite nur als Rauchtest. |
| 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 beta + 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 löst nicht, wo die Daten liegen – es zwingt einen dazu, jede Zustandsart bewusst nach außen zu legen. Genau diese Entkopplung macht das Projekt zu einer ehrlichen Referenz: Man sieht Baustein für Baustein, 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 |
Interessant ist, was nicht geholfen hat: Redis, mehr CPU und PHP-JIT haben den Cold Start nicht beseitigt. Selbst eine Verkleinerung des App-Images um 53 Prozent hat die rund zwölf Sekunden Aktivierungszeit kaum bewegt. Wirksam war am Ende vor allem eines: die Anwendung warm halten (ein Warm-up-Cron alle drei Minuten auf dem Pro-Plan) plus Edge-Caching für anonyme Seiten.
Kurzfassung für Entscheider
Die Kernaussage des Projekts, 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.
Aus dieser Erkenntnis sind bewusst zwei Produkte entstanden, weil eine einzige Konfiguration nicht beide Ziele bedient:
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 3-Minuten-Warmer. 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 laufender TYPO3-Ursprung die richtige Wahl – Vercel dient dann als CDN/Auslieferung 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 ist deshalb eine Mitigation, keine Garantie für null Cold Starts.
Mini-Anleitung: von null zur eigenen TYPO3-Seite bei Vercel
Diese Anleitung führt von null los – ohne 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 ist so vorverdrahtet, dass ein Blob-Store angelegt wird – das macht hochgeladene Dateien dauerhaft (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 ist womöglich ein Cold Start (ca. 10–12 s), Warm Requests liegen dann im Sekundenbruchteil-Bereich.
Die Ein-Klick-SQLite-Datenbank ist temporär – ein reiner Rauchtest. Seitenänderungen, Datensätze und Backend-Sessions können verschwinden oder sich zwischen Instanzen unterscheiden, solange keine echte Datenbank angebunden ist. Noch keine Inhalte anlegen, 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. Der 3-Minuten-Warmer plus 15-Minuten-Scheduler wird nicht per Git deployt (die Git-Konfiguration ist bewusst Hobby-kompatibel und cron-frei), sondern über ein Skript:
# 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>Ein normaler Git-Deploy fällt still auf das cron-freie Ein-Klick-Profil zurück. Nach jedem solchen Deploy muss das Pro-Profil über deploy-pro.sh neu gesetzt und mit vercel crons ls verifiziert werden – sonst ist das Warmhalten unbemerkt inaktiv.
Grenzen und ehrliche Vorbehalte
Kein Marketing, sondern die aus der Doku belegten Einschränkungen. Wer TYPO3 bei Vercel produktiv einsetzt, muss 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 Pro-Aufwärmstrategie | oft ruhiger |
| Hohe Backend-/Editor-Last | Schwierig – Backend ist nicht edge-cachebar | empfohlen |
| Hartes Latenz-SLA beim Erstaufruf | Nicht empfohlen | Pflicht: Always-on-Ursprung |
| Immer verfügbare Suche | Nur mit externem Solr | empfohlen |
Kurz gesagt: Für Vorschauen, Evaluierung und lese-lastige Seiten ist ein serverloses TYPO3 eine reizvolle, günstige Option. Für hochkritische Produktion mit garantierter Erstaufruf-Latenz bleibt ein Always-on-Ursprung die richtige Architektur – mit Vercel davor als reine Auslieferungsschicht.
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 – während kritische Kernportale weiter auf dauerhaft laufender, souveräner Infrastruktur bleiben.
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 beweist zweierlei: Erstens läuft ein vollständiges TYPO3 14.3 – Backend inklusive – technisch sauber als serverloses Container-Image. Zweitens, und ehrlicher: Der schwierige Teil ist nicht PHP, sondern der 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 man jede Zustandsart eines PHP-CMS serverlos auslagert, ist das Projekt ausgesprochen wertvoll – und die Mini-Anleitung oben bringt jede und jeden in wenigen Minuten zu einer eigenen, laufenden Instanz. Ob Vercel für ein bestimmtes Projekt die richtige Wahl ist, hängt an genau einer Frage: Wie sehr schmerzt der erste 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