Can a classic PHP CMS, which requires a database, files, and sessions on the server, run on a serverless platform that was actually built for static sites and edge functions? Yes, it works: a complete TYPO3 14.3, including its backend, runs as a container image on Vercel. In this article, we describe what the setup looks like, where its limits lie, and which projects it is suitable for.
typo3-camino-vercel is a community starter (not an official TYPO3 package) that runs the official TYPO3 Camino distribution as a PHP 8.5 container on Vercel. The live demo is a multilingual Camino de Santiago travel guide – frontend, backend, search, and Visual Editor are fully functional.
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 is located at /typo3/.
Table of Contents
What it really is
True full-stack TYPO3 – neither headless nor statically exported.
The Challenge
A stateful CMS on stateless infrastructure.
Executive Summary
The essentials at a glance: two products, clear limits.
Mini-Guide
From scratch to your own site – without an existing Vercel account.
Limitations
Cold starts, upload limits, no cron daemon, no mail server.
When it fits
Clear recommendation on what the platform is good for – and what it is not.
What Camino-on-Vercel really is
To avoid any misunderstanding: this is neither a static export nor a headless setup. A real, complete TYPO3 – with its backend – runs here as a Dockerfile-based container service on Vercel Services (currently marked as beta by Vercel).
The project documentation summarises the key experience like this: The challenge is not PHP compatibility, but adapting a stateful CMS (including a JVM search engine) to a stateless function model that scales to zero. PHP 8.5 runs without issues; the real effort lies in managing the state.
TYPO3 14.3.5
Official Camino distribution
No core fork. Frontend, backend, editing – everything is included.
PHP 8.5 + nginx
Alpine Linux container
PHP-FPM and nginx instead of Apache/mod_php; the image is kept deliberately lightweight.
Vercel Services (Beta)
Region fra1 (Frankfurt)
Dockerfile-based container service. Scales to zero when no one is visiting the site.
Visual Editor + 5 languages
Community extension friendsoftypo3/visual-editor 1.9
Mainly developed by Matthias Vogel (“Kanti”) from anders und sehr GmbH. Inline editing in the frontend, strict translations in EN, DE, ES, ZH, and HU.
The central challenge: State
A CMS requires persistent local state: database, files, cache, search index, cron jobs. Instead, Vercel provides an ephemeral container that scales down to zero. There is no general "enable persistence" switch – every type of state requires its own external component.
| Component | Implementation on Vercel |
|---|---|
| Database | External, persistent SQL DB via DATABASE_URL (Postgres/MySQL). SQLite is only used as a smoke test. |
| Files (FAL) | Custom FAL driver for Vercel Blob (or S3-compatible). Demo images are baked into the image. |
| Cache | Optional Redis via redis:// or rediss:// for shared cache between instances. |
| Search | EXT:solr 14 (currently Release Candidate) + Apache Solr 10 (demo only). Production: external, managed Solr. |
| Jobs / Cron | Protected Vercel Cron endpoints. No cron daemon in the image; long jobs must be split into short batches. |
| HTML Caching | Anonymous, cookie-free GET responses receive an Edge TTL – Vercel responds without PHP. |
Vercel does not answer the question of where the data lies – the platform forces you to consciously externalise every type of state. This makes it easy to understand, component by component, what a serverless TYPO3 actually requires.
Cold Start vs. Warm Request: the numbers
After being idle, the container must spin up first – which takes a noticeable amount of time. Once warm, TYPO3 responds in a fraction 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 |
Conversely, Redis, more CPU, and PHP-JIT did not eliminate the cold start. Even reducing the app image size by 53 percent had almost no impact on the roughly twelve-second activation time. Ultimately, what helped most was keeping the application warm – on the Pro plan via a warm-up cron running every minute – and serving anonymous pages via the Edge cache.
Executive Summary
The result in a single sentence: TYPO3 14.3 and the Camino distribution run correctly as a Vercel container image, and a normal warm request is fast – the challenge is state management, not PHP.
As a result, two products have been intentionally developed, because a single configuration cannot cover both goals at the same time:
1. One-click test
For trying it out, free of charge
Only the TYPO3 app with temporary SQLite, optional Blob, no Solr, no cron. Target audience: non-technical testers on the Hobby plan. Anonymous pages automatically receive a 5-minute edge policy.
2. Professional hosting
For real-world operations
Pro/Enterprise app plus external SQL DB, Blob/S3, optional Redis, managed external Solr, as well as a protected scheduler and a minute-by-minute warm-up cron. Target audience: managed editorial sites.
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) suitable for
Highly critical production environments with strict latency SLAs for the initial request. For this, a permanently running TYPO3 (always-on origin) remains the right choice – with Vercel serving as the CDN in front of it.
Cold starts after idle were around 10 to 12 seconds, while warm requests were usually under 0.5 seconds. Vercel does not currently offer a minimum-instance setting for this container image path – regular warm-ups mitigate the issue, but do not guarantee that cold starts are eliminated entirely.
Mini-Guide: From Scratch to Your Own TYPO3 Site on Vercel
This guide does not require any prior knowledge – not even an existing Vercel account. Steps 1 to 8 cover the free one-click test, while steps 9 to 12 turn this into a permanent installation. Anything that involves costs is marked with 💰.
Phase A: Free One-Click Test
1. Create a free Vercel account. Register at vercel.com/signup using GitHub, GitLab, Bitbucket, or email, and choose the Hobby plan (€0/month for private, non-commercial projects). The Hobby plan is sufficient for this test.
2. Generate a TYPO3 encryption key (will be added during deployment):
openssl rand -hex 483. Generate a strong admin password and save it 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. This opens Vercel's cloning workflow and creates the repository in your own GitHub account – no manual fork or CLI required.
5. Authorise your Git account if prompted by Vercel. This allows Vercel to create the cloned repository and automatically redeploy it with every push.
6. Leave the public Vercel Blob storage selected. The button automatically creates a Blob store, ensuring that uploaded files are persisted (free within Hobby plan limits).
7. Enter the three required environment variables:
TYPO3_SETUP_ADMIN_USERNAME=admin
TYPO3_SETUP_ADMIN_PASSWORD=<your-long-random-password>
TYPO3_ENCRYPTION_KEY=<96-random-hex-chars>There is no default password – the login is exactly what you enter here. Leave DATABASE_URL blank in free mode.
8. Click 'Deploy' and wait for the status to show 'Ready'. A Git push is not instantly online – Vercel needs to build and activate the container images first. Once done, open the generated URL; the backend is located at /typo3/. The first request might trigger a cold start (approx. 10–12 s); warm requests will follow in a fraction of a second.
The one-click SQLite database is temporary – purely for testing. As long as no real database is connected, page changes, records, and backend sessions may disappear or differ between instances. Do not create any content that you wish to keep.
Phase B: Making It Permanent
9. Connect an external database. Set up a Postgres- or MySQL-compatible database close to fra1 – free options include Neon or Supabase (Postgres) and TiDB Cloud (MySQL-compatible). 💰 Free within their quotas; production tiers will incur costs. Add this as a Production variable in your Vercel project settings:
DATABASE_URL=postgresql://user:password@host/database?sslmode=require10. Initialise the empty database once. Temporarily set TYPO3_AUTO_SETUP=1 and TYPO3_BOOTSTRAP_EMPTY_DATABASE=1, deploy, verify the frontend and backend login, then set both back to 0 and redeploy. This removes avoidable database checks from every container startup.
11. (Optional) Import the Camino demo – via the protected maintenance endpoint, as there is no shell access on Vercel:
curl --request POST \
--header "Authorization: Bearer $CRON_SECRET" \
https://your-project.vercel.app/api/maintenance/camino-demo.php12. Connect a custom domain. Add it in the Vercel project settings under 'Domains' (standard procedure). 💰 Domain registration itself is a separate cost; commercial use requires a Pro plan.
Phase C: Professional Operation (💰 paid)
Production-level operation requires Vercel Pro or Enterprise – this is the primary fixed cost component. The default configuration (vercel.json) remains deliberately Hobby-compatible and cron-free; the minute-by-minute warm-up cron and the 15-minute scheduler are located in a dedicated Pro profile (vercel.pro.json), which is deployed via a script:
# 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>Previously, a normal Git deployment would silently fall back to the cron-free one-click profile. This trap has now been largely mitigated: the starter's Vercel project is intentionally no longer linked to Git, and a push to main automatically deploys the Pro profile (warmer + scheduler) via the CI deployment job with deploy-pro.sh as soon as the VERCEL_TOKEN secret is provided. The manual script remains as a fallback. Nevertheless, after every release, verify with vercel crons ls that both cron jobs are registered – otherwise, the warm-up mechanism will silently fail to run.
Limitations and Honest Caveats
The following limitations are documented in the project. Anyone deploying TYPO3 on Vercel for production should be aware of them.
When Vercel is Suitable for TYPO3
| Scenario | Well-suited | Better hosted classically |
|---|---|---|
| Demos & prototypes | Ideal – fast, affordable, disposable | unnecessary |
| Read-heavy campaign site | Good with external DB + Blob + Edge cache | possible |
| Managed editorial site | Feasible with warm-up strategy (Pro plan) | often simpler |
| High backend/editor load | Difficult – backend is not edge-cacheable | recommended |
| Strict latency SLA on initial request | Not recommended | Required: Always-on origin |
| Always-available search | Only with external Solr | recommended |
In short: for previews, evaluations, and read-heavy websites, serverless TYPO3 is an interesting, budget-friendly option. For highly critical production sites with guaranteed latency on the first request, an always-on origin remains the correct architecture – with Vercel acting as a CDN in front.
Also of Interest to Public Sector Organisations
The fact that a full TYPO3 setup can now run on Vercel expands options in the public sector as well. For preview environments, campaign microsites, and read-heavy informational sites, serverless hosting with an external, GDPR-compliant database can reduce operational costs. Critical core portals, however, will continue to rely on permanently running, sovereign infrastructure.
We describe what a modern, agent-capable TYPO3 v14 for government websites looks like in detail in Austria + TYPO3: Smart Government Websites on the German Model.
Conclusion
typo3-camino-vercel demonstrates two things. Firstly, a full TYPO3 14.3 – backend included – runs flawlessly as a serverless container image from a technical standpoint. Secondly, the difficult part is not PHP, but state: database, files, cache, search, and cron must all be intentionally externalised, and cold starts remain a realistic limitation without an always-on instance.
As a reference on how to offload every type of state from a PHP CMS to a serverless architecture, this project is highly useful – and with the mini-guide above, you can have your own running instance in just a few minutes. Whether Vercel is the right choice for a specific project ultimately depends on one main question: how important is the response time on the very first request, i.e. the cold start?
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 on the German Model
- Consulting: Are you considering hosting or modernising TYPO3? Drop us a line at office@webconsulting.at