Headless hosting where WordPress serves data, not pages.
In a headless build the origin's job is to answer API calls and to tell the frontend when something changed. Almost everything a normal WordPress host optimises is irrelevant here.
Everything a headless build asks of a host.
No theme renders here. What matters is API response time and whether your frontend hears about an edit.
Publishes that reach the frontend
Saving a post fires a webhook carrying the affected paths, so your Next.js or Astro deployment revalidates those routes instead of waiting for a scheduled rebuild or a full redeploy.
API responses answered from memory
REST and GraphQL responses lean entirely on the object cache, because when the response is JSON there is no page cache in front of it to hide a slow query behind.
Previews without a public draft
Preview requests are authenticated with short-lived tokens, so your frontend can render unpublished content without that content being reachable by anybody who guesses the URL.
CORS and origins configured, not guessed
Allowed origins are set at the edge for your production frontend and its preview deployments, which is the setting most headless builds discover is wrong on launch day.
Media served independently of the frontend
Uploads keep serving from the WordPress origin through the edge, so changing frontend framework never means re-hosting the media library.
One backend, several frontends.
Headless setups end up with a production frontend, a preview deployment and a build pipeline all reading the same WordPress. The dashboard is built for that rather than for one site.
- Webhook delivery log per publish
- API response timing by endpoint
- One-click admin login for editors
- Restore any daily backup from the dashboard
A GraphQL query during a static build.
A build hits the API hundreds of times in a few seconds. That burst, rather than a visitor's page load, is the workload the origin actually has to survive.
What we change for a headless build
These are the settings that differ from a standard WordPress site on the same plan. Each follows from the origin answering machines rather than browsers.
| Setting | What we do | Why |
|---|---|---|
| Full-page cache | Disabled at the origin; caching belongs to the frontend | Nothing here renders HTML, so a page cache in front of an API endpoint only adds a layer that then has to be invalidated correctly. |
| Publish hooks | Webhook fired on save carrying the affected paths | Without one the frontend either rebuilds everything on a timer or serves stale content until somebody notices and triggers a deploy. |
| Object cache | Redis, sized for repeated API reads during builds | A static build queries the same taxonomies hundreds of times within a few seconds, and every uncached one of those is a database round trip. |
| Preview requests | Authenticated with short-lived tokens rather than a shared secret | A long-lived preview key ends up committed to a frontend repository, and at that point the drafts are effectively public. |
| CORS policy | Allowed origins configured for production and preview domains | Preview deployments get a fresh hostname on every branch, and a policy written once for production blocks all of them. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Do you support WPGraphQL and the REST API?
How does my frontend know something changed?
Where does the frontend itself run?
Can editors still preview drafts?
Is the admin still fast?
Move your headless backend to a host that knows it is one.
Free migration, invalidation pushed on publish, and previews that never expose a draft.