Managed Hosting for Sites That Aren't WordPress
The phrase “managed hosting” means something fairly specific in the WordPress world: someone else patches the platform, runs the cache, and handles the server. When you leave WordPress behind, the phrase keeps its marketing appeal and loses its shared meaning.
What replaces it is a different and more concrete constraint — a runtime matrix. And the shape of that constraint is what you should be comparing.
The runtime matrix is the product
Modern managed platforms for non-WordPress workloads publish which runtimes they support, and the list is enumerated rather than open.
One platform’s getting-started documentation states the requirement plainly: you need “a supported runtime (Node.js, PHP, Python, Go, Java, Ruby, or .NET).” Another, built specifically for the Laravel ecosystem, documents “support for Symfony, Next.js, Nuxt, Go, and Python,” with a version table covering PHP 8.2 through 8.5, Node 20/22/24, Go 1.24 and later, and Python 3.10 through 3.13.
That is a materially different promise from “managed WordPress.” It is not “we will handle anything you deploy.” It is “we have built, tested and will support these specific runtimes, at these specific versions.”
Two consequences follow, and both matter more than the feature list:
Version drift is your problem at the edges. If your application needs a runtime version outside the published table, the platform has not agreed to run it. The failure is not subtle — it is a build error — but the point is that the supported matrix is a boundary, and crossing it is not a support ticket, it is a rejection.
“Managed” here means the build and deploy pipeline, not your application. The platform handles build environments, dependency installation, release management and routing. It does not handle your application’s bugs, its database queries, or its scaling behaviour. The responsibility line sits in a different place than in WordPress-managed hosting, and it is drawn by the runtime list.
Static is a separate product, and this is the important distinction
On the same platforms that offer managed compute, static hosting is documented as its own product type, not a subset of the managed runtime offering. One platform documents “Static Sites” as a distinct service alongside its language runtimes, with per-framework build pipelines covering Astro, Hugo, Jekyll, Gatsby and Docusaurus among others.
That is worth pausing on, because it is the cleanest available statement of an architectural fact: a static site does not need a runtime, so it does not need a managed runtime. What it needs is a build step and a distribution network.
Once you see the split, the comparison clarifies:
| Managed WordPress | Managed runtime (PaaS) | Static hosting | |
|---|---|---|---|
| What is managed | The platform + caching + updates | Build, deploy, release, routing | Build + global distribution |
| Constraint | Support scope, visits cap, PHP workers | Enumerated runtime + version matrix | None on the runtime |
| Failure mode | Plugin conflict, cap exceeded | Unsupported runtime, build failure | Build failure |
| Who fixes your code | You | You | You |
Notice that the last row is identical in all three columns. Nothing in the “managed” family fixes your application. The differences are entirely about what surrounds it.
Why the runtime matrix is a hidden cost
A static site has no runtime version to track. A managed PHP application has one, and the platform’s published table is a schedule you do not control.
When a platform drops support for a runtime version, your application does not stop working that day — but you have a deadline you did not set, on a codebase you may not have touched in a year. This is the non-WordPress equivalent of a forced plugin update, except that nobody has built automatic rollback for it.
The realistic mitigation is to know where you sit on the matrix before you choose a platform, and to prefer platforms that publish versions and deprecation timelines rather than a marketing page that says “Node.js supported.”
The Docker escape hatch, and its real cost
Most of these platforms also accept a container image. That looks like it removes the runtime constraint, and in one sense it does — you can bring any runtime you like.
What it does not remove is the maintenance. A runtime matrix is someone else deciding which versions are patched. A container image is you deciding, and it also means you own the base image updates, the security patches, and the CVEs in everything you layered on top.
That trade is legitimate and sometimes correct. It is also exactly the work that “managed” was supposed to remove, which is why platforms offer both and document them as different products.
What to compare instead of features
Five rows, all answerable from official documentation:
| Row | Why it decides the purchase |
|---|---|
| Runtime + version table | Whether your application can deploy at all |
| Deprecation policy for those versions | Whether you have a deadline you control |
| Is static a first-class product, or a runtime hack? | Whether your build pipeline gets real support |
| Responsibility boundary — what does support decline? | What “managed” actually covers |
| The unit you are billed on | Requests, CPU-minutes, or build minutes |
That last row is the one people underestimate. Platforms in this category bill on different meters — some per request, some per CPU-minute, some per build. Two platforms with the same headline price can differ by an order of magnitude on the same site, because they are metering different things. The bandwidth article covers that accounting in detail.
When managed PaaS is the wrong choice
- Your application is static. You are buying a runtime you do not use. Static hosting is the smaller, simpler purchase.
- Your runtime is not on the list. Check before you build your deployment around it. This is the single most common wasted weekend in this category.
- You need a specific kernel-level behaviour — a custom daemon, a particular filesystem layout, raw sockets. A managed platform is the wrong abstraction, and a VPS is the honest answer.
- Your traffic is tiny and steady. A small VPS with a managed control panel may cost less than the convenience premium, provided you actually want to do the operations work.
The category is genuinely useful for the case it was built for: an application that needs to run, on a supported runtime, with deploys and rollouts handled for you. The mistake is assuming “managed” is a bigger version of the same thing across all three columns. It is three different products wearing one adjective.
Written by TestedHost. Every recommendation on this site comes from running the setup described, on a live deployment — not from a vendor spec sheet. Spotted something out of date? Tell us.