WordPress deserves to run without a server.
WordPress runs a large part of the web, and nearly all of it still runs on a server someone has to rent, size, patch and watch. Serverless platforms took that work away from almost every other kind of site. HostlessWP brings it to the WordPress you already have, without asking you to give up the plugins, theme and database that make it yours.
The server problem
A typical WordPress site is a stack of software on a machine: an operating system, a web server, PHP-FPM, often a cache, and WordPress on top. Every layer needs updates, and every layer can be the one that breaks.
- It is sized for the worst hour. The server waits mostly idle, and you pay for it all day so that it survives the busiest moment. When a post goes viral or a sale starts, it may still not be enough.
- It needs a caretaker. Security patches for the OS and PHP, renewed certificates, full disks, a stuck PHP worker at 3 a.m. Someone has to notice and fix it.
- It is an attack surface. An open SSH port, an outdated PHP version or a forgotten admin tool on the same machine are common ways in.
- Moving is painful. Changing host means copying files, exporting the database, fixing paths and hoping nothing was missed.
Managed WordPress hosting hides some of this behind a monthly fee, but there is still a server, and its limits are still yours.
Why not static or headless?
The usual ways to get WordPress off a server each give up something WordPress is good at.
Static export
Fast, but frozen
Plugins like Simply Static turn the site into HTML files. Anything that runs at request time is gone: checkout, carts, comments, search, forms, member areas, logins. Every edit means a new export.
Headless
Flexible, but a rewrite
WordPress stays as a back end and a new front end is built in another framework. Your theme stops mattering, many plugins lose their front-end features, and you now maintain two applications.
HostlessWP
The whole WordPress
Real PHP runs on every request, inside a Worker. Themes, plugins, the admin and every dynamic feature keep working because nothing about WordPress changed, only where it runs.
What serverless gives a WordPress site
No server to maintain
There is no operating system, web server or PHP install of yours to patch. Cloudflare runs the platform; hostlesswp ships PHP 8.3 with each deploy.
Scales with each request
Workers start instances as requests arrive and stop them when traffic falls. There is no machine to outgrow and nothing running for nobody.
Cloudflare's network in front
Theme files, media and cached pages for logged-out visitors are answered without starting PHP, with Cloudflare's DDoS protection and TLS included.
Deploys you can repeat
The running site is built from your source site on every deploy. The same command that moved it can rebuild it at any time.
Free for small sites
A blog, a portfolio or a small business site can run on Cloudflare without a monthly bill. Everything hostlesswp uses has a free tier.
| Service | Free plan | What it covers |
|---|---|---|
| Workers | 100,000 requests a day | Every page view that reaches PHP, plus media requests when the bucket has no public address. Theme files and other static assets are free and unlimited. |
| Hyperdrive | 100,000 queries a day | Database queries from PHP. Cached pages for logged-out visitors use none. |
| Workers KV | 1,000 writes a day | The page cache. When writes run out, pages are rendered by PHP for the rest of the day. |
| R2 | 10 GB storage | Your media library, with no fee for traffic out of R2. |
You still need a MySQL database somewhere, as you do today; managed databases with a free tier work too. When a site outgrows the free limits, Workers Paid is $5 a month. Limits as published by Cloudflare in October 2026. How far they go in page views.
No server to break into, no files to infect
Most hacked WordPress sites are hacked the same few ways: a weak server, or a backdoor written into PHP files that keeps coming back. On Workers neither has anywhere to live.
No server, no SSH
There is no machine with an open SSH port, an FTP account, an outdated PHP or a control panel to get into. The only way in is through WordPress itself.
Code is read-only
Plugins, themes and core come from the deploy and live in memory. Editing or installing code from the admin is turned off, and a file written by an attacker disappears with the instance. The next request starts from the clean deploy.
Uploads are never code
PHP files are never stored in the media bucket, never served from it and never loaded back into PHP. A malicious upload cannot become a web shell.
What still matters: a stolen admin password or a vulnerable plugin can still change what is in your database (posts, users, settings). Keep plugins updated on the source site, use strong passwords, and back up the database.
No disk to lose
On a single server, one failed disk can take the site and every image with it, and backups are often missing or months old. HostlessWP has no single disk.
Code
Stored by Cloudflare with each deployed version, and rebuilt from your source site whenever you run the command.
Media
In object storage, which keeps several copies across machines. Cloudflare R2 is designed for 99.999999999% durability.
Database
Where it is today. On a managed database, backups and failover are the provider's job; on your own server, keep backing it up.
What stays yours
- Your database stays where it is. HostlessWP never copies it. The Worker connects to it through Cloudflare Hyperdrive, over SSL or a Cloudflare Tunnel.
- Your Cloudflare account, your bucket. The Worker, its secrets and your media live in accounts you own. There is no HostlessWP service in the middle.
- Plain WordPress. Core is not modified. The runtime is a drop-in, a must-use plugin and the Worker around them. The site you run on Workers is the site you started with.
- Easy to leave. Point your domain back to your old host and you are done. Nothing to migrate back, because the data never left.
- Open source. GPL-2.0-or-later, the same license as WordPress. Read it, change it, run it yourself.
Side by side
| Server hosting | Static export | Headless | HostlessWP | |
|---|---|---|---|---|
| Your theme and plugins | Yes | Front end only | Theme replaced | Yes, top 30 tested |
| Checkout, logins, comments, search | Yes | No | Rebuilt by hand | Yes |
| Server to patch | Yes | No | Yes, for WordPress | No |
| Handles traffic spikes | Up to its size | Yes | Front end yes | Yes, your database is the limit |
| Cost for a small site | Monthly plan | Free hosting | Two things to host | Free plan |
| Backdoors in PHP files | Persist | No PHP | Persist on the back end | Cannot persist |
| A failed disk | Site and media at risk | No disk | Back end at risk | No disk |
| Effort to switch | Migration | Export after every change | A new project | One command |
Also compared: EmDash, Cloudflare's new CMS, and ServerlessWP on Vercel, Netlify or Lambda.
Good to know
What we learned building and testing it, so you can decide with the full picture.
Distance to the database matters most
WordPress runs its queries one after another, so hostlesswp places the Worker next to your database. In our tests that made pages about 6 times faster than running near the visitor.
Memory per instance is 128 MB
Each Worker instance has 128 MB. WooCommerce with the common plugins fits; very heavy combinations (Elementor plus WooCommerce plus a form builder, for example) can go over it.
Code changes go through deploys
A Worker has no lasting disk, so plugins and themes are installed on the source site and shipped with npx hostlesswp deploy. Content and media change in the admin as usual.
Who it is for
A good fit
Today- Blogs, business sites and documentationContent sites with the common plugins
- Small and medium WooCommerce storesCheckout tested end to end
- Agencies with many small client sitesNo server per client to patch
- Sites that get sudden trafficLaunches, campaigns, a post that takes off
- Anyone tired of looking after a server
Not yet
Wait a bit- Multisite networks
- Sites that need Redis or Memcached
- Plugins that write to disk or run long background jobs
- Very heavy plugin stacks that do not fit 128 MB
Beyond WordPress, in theory
Nothing about running PHP in a Worker is specific to WordPress. php-wasm is a complete PHP 8.3, and the pieces around it (the lazy file system for code, the database bridge, media in object storage, the clock fix) solve problems every PHP application has on Workers.
So other PHP projects could run the same way: forums, wikis, small CMSs, custom PHP sites. Today the tooling is built and tested for WordPress only. The database bridge speaks mysqli and WordPress's $wpdb, not PDO yet, and the setup reads wp-config.php. If you want to try another PHP application, open an issue; we would like to hear which one.
What comes next
- Direct database connection. In our tests a direct connection from the Worker answered a query in about 2 ms against about 33 ms through Hyperdrive, and rendered the WooCommerce home page in 0.19 s. It needs a TLS fix before it ships.
- Faster cold starts. Starting PHP on a fresh instance takes seconds today. The page cache already hides this from logged-out visitors; we want it gone for the admin and checkout too.
- Email. A tested path for sending mail through an HTTP API.
- More plugins tested. Beyond the top 30, with results published on the compatibility page. Tested one yourself? Pull requests with results are welcome.
See it with your own eyes
The demo is a real WordPress with WooCommerce on Workers. Log in as an administrator and try anything.