Can a classic, stateful PHP CMS run on a serverless platform that was actually built for JAMstack and edge functions? The short answer: yes – a complete TYPO3 14.3, backend included, runs as a container image on Vercel. The honest answer is a bit longer, and that is exactly what this article is about.
typo3-camino-vercel is a community starter (not an official TYPO3 package) that runs the official TYPO3 Camino distribution as a PHP 8.4 container on Vercel. The live demo is a multilingual Camino de Compostela travel guide – frontend, backend, search and Visual Editor, all real.
Live demo: typo3-camino-vercel.vercel.app
A complete TYPO3 14.3 with the Camino distribution, five languages (EN, DE, ES, ZH, HU), Solr search and Visual Editor – as a container image on Vercel. The backend lives at /typo3/.
Table of Contents
What it really is
Real full-stack TYPO3, not headless, not a static export.
The challenge
A stateful CMS on stateless infrastructure.
Summary
Product-manager summary: two products, clear limits.
Mini-guide
From zero to your own site – without an existing Vercel account.
Limits
Cold starts, upload limit, no cron daemon, no mail server.
When it fits
A clear recommendation on what the platform is good for – and what not.
What Camino-on-Vercel really is
Important for understanding: this is not a static export and not headless. It is real, complete TYPO3 – with a backend – running as a long-lived container image on Vercel's serverless container platform (Fluid Compute).
The project's key insight is captured by its own documentation, roughly: The hard part is not PHP compatibility, but adapting a stateful CMS (and a JVM search engine) to a stateless, scale-to-zero function model. PHP 8.4 runs without issue. The work lies elsewhere.
TYPO3 14.3.4
Official Camino distribution
Fixed version, not a fork of the Core. Frontend, backend, editing – all present.
PHP 8.4 + nginx
Alpine Linux container
PHP-FPM and nginx instead of Apache/mod_php. The image was deliberately built lean.
Vercel Container Images
Region fra1 (Frankfurt)
Fluid Compute, Performance CPU. Scales to zero when nobody visits the site.
Visual Editor + 5 languages
Visual Editor by kanti (anders und sehr)
Inline editing in the frontend, strict translations in EN, DE, ES, ZH and HU.
The central challenge: State
A CMS assumes persistent local state: database, files, cache, search index, cron jobs. Vercel instead gives you an ephemeral, scale-to-zero container. There is no generic 'turn on persistence' switch – every kind of state is solved with a different external building block.
| Building block | Implementation on Vercel |
|---|---|
| Database | External, persistent SQL database via DATABASE_URL (Postgres/MySQL). SQLite only as a smoke test. |
| Files (FAL) | A dedicated FAL driver for Vercel Blob (or S3-compatible). Demo images are baked into the image. |
| Cache | Optionally Redis via redis:// or rediss:// for a shared cache across instances. |
| Search | EXT:solr 14 beta + Apache Solr 10 (demo only). In production: external, managed Solr. |
| Jobs / Cron | Protected Vercel Cron endpoints. No cron daemon in the image; split long jobs into short batches. |
| HTML caching | Anonymous, cookie-free GET responses get an edge TTL – Vercel responds without PHP. |
Vercel doesn't solve where the data lives – it forces you to deliberately move every kind of state outside. It is exactly this decoupling that makes the project an honest reference: you see, building block by building block, what a serverless TYPO3 actually needs.
Cold vs. warm: the numbers
After being idle, the container first has to spin back up – which costs noticeable time. Once it is warm, TYPO3 responds in fractions of a second.
| State | Response time (median) |
|---|---|
| Cold start (after idle) | ≈ 10–12 s |
| Warm request – frontend | 0.14 s |
| Warm request – backend | 0.26 s |
| Search (warm) | 0.37 s |
What is interesting is what did not help: Redis, more CPU and PHP JIT did not eliminate the cold start. Even shrinking the app image by 53 percent barely moved the roughly twelve seconds of activation time. In the end, one thing above all proved effective: keeping the application warm on a regular basis (a warm-up cron every three minutes on the Pro plan) plus edge caching for anonymous pages.
Executive summary
The project's core message, in one sentence: TYPO3 14.3 and the Camino distribution run correctly as a Vercel container image, a normal warm request is fast – the challenge is state management, not PHP.
From this insight, two products were deliberately created, because a single configuration cannot serve both goals:
1. One-click test
For trying out, free of charge
Just the TYPO3 app with temporary SQLite, optionally Blob, no Solr, no cron. Target audience: non-technical testers on the Hobby plan. Anonymous pages automatically get a 5-minute edge policy.
2. Professional hosting
For real operation
A Pro/Enterprise app plus external SQL database, Blob/S3, optionally Redis, managed external Solr as well as a protected scheduler and a 3-minute warmer. Target audience: a maintained editorial site.
What it is good for
Demos, evaluation, previews and prototypes. Read-heavy sites with low to medium traffic (external DB + Blob). Editorial sites whose team accepts and monitors a warm-up strategy.
What it is not (yet) good for
Highly critical production with a hard latency SLA for the first request. For that, a permanently running TYPO3 origin remains the right choice – with Vercel serving as the CDN/delivery layer in front.
After being idle, cold responses came in at around 10 to 12 seconds, warm ones usually under half a second. Vercel currently offers no minimum-instance setting for this container-image path – so regular warming is a mitigation, not a guarantee of zero cold starts.
Mini-guide: from zero to your own TYPO3 site on Vercel
This guide starts from scratch – without an existing Vercel account. Steps 1 to 8 give you the free one-click test, steps 9 to 12 turn it into a permanent installation. Everything that costs money is marked with 💰.
Phase A: Free one-click test
1. Create a free Vercel account. Sign up at vercel.com/signup with GitHub, GitLab, Bitbucket or email and choose the Hobby plan (€0/month for private, non-commercial projects). Hobby is enough for the test.
2. Generate a TYPO3 encryption key (to be entered during deployment):
openssl rand -hex 483. Generate a strong admin password and store it together with the key in your password manager – never commit it to Git:
openssl rand -base64 324. Click the "Deploy with Vercel" button in the repository. It opens Vercel's clone flow and creates the repo in your own GitHub account – no manual fork, no CLI required.
5. Authorize your Git account when Vercel asks. This lets Vercel create the cloned repo and automatically redeploy on every push.
6. Leave the public Vercel Blob storage selected. The button is pre-wired to create a Blob store – this makes uploaded files persistent (free within the Hobby limits).
7. Enter the three required environment variables:
TYPO3_SETUP_ADMIN_USERNAME=admin
TYPO3_SETUP_ADMIN_PASSWORD=<your-own-long-random-password>
TYPO3_ENCRYPTION_KEY=<96-random-hex-characters>There is no default password – the login is exactly what you enter here. Leave DATABASE_URL empty in free mode.
8. Click "Deploy" and wait until the status is "Ready". A Git push is not online immediately – Vercel first has to build and activate the container images. Then open the generated URL; the backend lives at /typo3/. The first request may cold-start (approx. 10–12 s), warm requests are then in the sub-second range.
The one-click SQLite database is temporary – purely a smoke test. Page changes, records and backend sessions can disappear or differ between instances as long as no real database is connected. Do not yet create any content that should be preserved.
Phase B: Make it permanent
9. Connect an external database. Create a Postgres- or MySQL-compatible database near fra1 – free options include Neon or Supabase (Postgres) or TiDB Cloud (MySQL-compatible). 💰 Free within the quota, production sizes cost money. Enter it as a Production variable in the Vercel project settings:
DATABASE_URL=postgresql://user:password@host/database?sslmode=require10. Initialize the empty database once. Temporarily set TYPO3_AUTO_SETUP=1 and TYPO3_BOOTSTRAP_EMPTY_DATABASE=1, deploy, check the frontend and backend login – then set both back to 0 and deploy again. This removes avoidable DB checks from every container start.
11. (Optional) Load the Camino demo – via the protected maintenance endpoint, since there is no shell on Vercel:
curl --request POST \
--header "Authorization: Bearer $CRON_SECRET" \
https://your-project.vercel.app/api/maintenance/camino-demo.php12. Connect your own domain. Add it in the Vercel project settings under "Domains" (standard flow). 💰 The domain registration itself is a separate cost item; commercial use requires Pro.
Phase C: Professional operation (💰 paid)
Production operation requires Vercel Pro or Enterprise – that is the main fixed-cost item. The 3-minute warmer plus 15-minute scheduler is not deployed via Git (the Git configuration is deliberately Hobby-compatible and cron-free), but via a script:
# Generate and set the warm-up secret
openssl rand -hex 32
vercel env add CRON_SECRET production
# Roll out the Pro configuration (warmer + scheduler)
VERCEL_SCOPE=<team-slug> scripts/deploy-pro.sh
# Then ALWAYS check: both cron jobs must be listed
vercel crons ls --scope <team-slug>A normal Git deploy silently falls back to the cron-free one-click profile. After every such deploy, the Pro profile must be re-applied via deploy-pro.sh and verified with vercel crons ls – otherwise the warming is inactive without anyone noticing.
Limits and honest caveats
No marketing, just the limitations documented in the docs. Anyone running TYPO3 on Vercel in production needs to know them.
When Vercel fits TYPO3
| Scenario | A good fit | Better hosted classically |
|---|---|---|
| Demos & prototypes | Ideal – fast, cheap, disposable | unnecessary |
| Read-heavy campaign site | Good with external DB + Blob + edge cache | possible |
| Editorial site with maintenance | Feasible with a Pro warm-up strategy | often calmer |
| High backend/editor load | Difficult – the backend is not edge-cacheable | recommended |
| Hard latency SLA on first request | Not recommended | Mandatory: always-on origin |
| Always-available search | Only with external Solr | recommended |
In short: for previews, evaluation and read-heavy sites, a serverless TYPO3 is an appealing, inexpensive option. For highly critical production with guaranteed first-request latency, an always-on origin remains the right architecture – with Vercel in front as a pure delivery layer.
Also of interest to public authorities
The fact that a complete TYPO3 now runs on Vercel broadens the options in the public sector too. For preview environments, campaign microsites and read-heavy information pages, serverless delivery with an external, GDPR-vetted database can lower operating costs – while critical core portals stay on permanently running, sovereign infrastructure.
We describe in detail what a modern, agent-capable TYPO3 v14 for government websites looks like in Austria + TYPO3: Smart government websites following the German model.
Conclusion
typo3-camino-vercel proves two things: first, a complete TYPO3 14.3 – backend included – runs cleanly as a serverless container image from a technical standpoint. Second, and more honestly: the hard part is not PHP but state. Database, files, cache, search and cron each have to be deliberately moved outside, and without an always-on instance, cold starts remain a real limitation.
As a reference for how to offload every kind of state of a PHP CMS in a serverless way, the project is exceptionally valuable – and the mini-guide above gets anyone to their own running instance in a few minutes. Whether Vercel is the right choice for a given project comes down to exactly one question: how much does the first, cold request hurt?
Links and further information
- Repository: github.com/dirnbauer/typo3-camino-vercel
- Live demo: typo3-camino-vercel.vercel.app
- Related article: Austria + TYPO3: Smart government websites following the German model
- Consulting: Considering hosting or modernizing TYPO3? Write to us at office@webconsulting.at