Managed is the most overloaded word in hosting. It can mean somebody patches your operating system, or that a database is fully operated for you, or that you never see a server at all. Those are three different products with three different prices, and searching for managed hosting from a cloud provider returns all three mixed together, usually on pages written by whoever benefits from the confusion.
So this is a responsibility table rather than a recommendation: four hosting models, and for each one, the list of things that are genuinely no longer your problem.
Table of contents
- The four models, and where cloud providers sit
- Who does what: the table people should be shown
- What unmanaged actually costs
- What managed does not cover
- Choosing between them without agonising
- How this fits the rest of the stack
- FAQ
The four models, and where cloud providers sit
Almost every hosting product is one of four shapes.
Unmanaged virtual servers. You get a machine with an operating system and root access. Everything above that is yours. This is what most cloud providers sell as their core compute product, and it is what people mean by a VPS or a droplet or an instance.
Managed servers. Somebody else administers the machine — patching, monitoring, security response, sometimes application-level support. Usually a third party operating on top of a cloud provider’s infrastructure, and priced accordingly.
Managed components. A specific piece is operated for you — a database, a load balancer, object storage, a Kubernetes control plane — while your application still runs on servers you manage. Most cloud providers sell a catalogue of these.
Application platforms. You provide code; the platform builds it, runs it, routes to it and scales it. There is no server in your mental model at all.
The important observation is that a large cloud provider typically sells the first and the third directly, and the second through a partner. So the answer to whether their hosting is managed is genuinely, unhelpfully, that it depends on which product you buy.
Who does what: the table people should be shown
For each task, whose problem is it?
| Task | Unmanaged server | Managed server | Managed component | Application platform |
|---|---|---|---|---|
| Provisioning | You | Provider | Provider | Provider |
| OS patching | You | Provider | Provider | Provider |
| Web server config | You | Provider | N/A | Provider |
| Runtime and dependencies | You | Shared | N/A | You declare, it builds |
| Certificates | You | Provider | Provider | Provider |
| Database backups | You | Provider | Provider | Provider |
| Firewall and hardening | You | Provider | Provider | Provider |
| Scaling | You | Shared | Provider | Provider or automatic |
| Application code | You | You | You | You |
| Schema and queries | You | You | You | You |
| Cost when idle | Full | Full | Full | Often lower |
Two things fall out of this table. The bottom rows never move — your code and your data model are yours in every model, and no amount of managed changes that. And the difference between the first column and the last is not capability, it is how many rows say You.
What unmanaged actually costs
The appeal of an unmanaged server is straightforward: it is the cheapest line item, and you have complete control. Both are true. The cost is in the rows above.
A server you run needs, at minimum: initial hardening, a firewall, unattended security updates configured and verified, a web server and its configuration, certificate issuance and renewal, log rotation before the disk fills, monitoring that tells you before users do, backups stored somewhere other than the machine, and a documented way to rebuild it.
None of these is difficult. Together they are a few days of work up front and a recurring background tax afterwards, and the tax is uneven — nothing for months, then a full day when a certificate renewal silently fails or a kernel update needs a reboot you have to schedule.
The honest way to price an unmanaged server is the monthly fee plus the hours. For someone who enjoys this work or is running many machines, the hours are cheap. For a team of two shipping a product, they are the most expensive hours in the company.
What managed does not cover
The disappointment with managed hosting is nearly always about the boundary, so it is worth stating precisely.
Managed usually stops at the operating system and the stock services on it. It does not usually include:
- Your application. If your code has a memory leak, that is yours. The provider will tell you the process was killed.
- Your database schema and queries. A managed database will be patched, backed up and available, and it will happily run your unindexed query slowly forever.
- Your architecture. Nobody is going to tell you that the reason the site is slow is that it makes forty database calls per page.
- Custom software you installed. Once you compile something from source onto a managed server, that piece is usually explicitly outside the support boundary.
Read the boundary before buying, because managed sounds like somebody is looking after your website and generally means somebody is looking after the server your website is on.
Choosing between them without agonising
A short version that covers most cases:
- You need a specific operating system, kernel modules, unusual software, or per-account isolation for clients. Unmanaged server. You need the control, so take the tax knowingly.
- You have a server-shaped workload and no interest in administering it, and the budget is comfortable. Managed server.
- Your application is ordinary — a web service, a database, some storage — and you want it running rather than hosted. Application platform. This is most projects, and it is the option people skip because it is not what hosting comparison sites are optimised to sell.
- You are somewhere in between and mostly want the database to stop being your problem. Managed components on top of servers you already have. This is the highest-value single change most self-managed setups can make, because the database is where the irreversible failures live.
The one genuinely poor choice is an unmanaged server bought because it was the cheapest line, by someone who has no intention of doing the work in column one. That server exists in enormous numbers, unpatched, and it is the reason this distinction is worth caring about.
How this fits the rest of the stack
The useful exercise is to take the table and mark which rows you actually want to own. Most people find the answer is the bottom two — the code and the data model — and that everything above them was accepted by default rather than chosen.
Pricing it honestly means counting all the pieces rather than one, which is what the RunxBuild hosting calculator is for: the service, the database, the storage and the bandwidth as separate lines. RunxBuild sits in the application-platform column — deploy from a repository, get build logs, a live route, environment variables, custom domains, runtime logs and rollback, with managed MySQL and Postgres beside it and autoscaling between plans you choose. The rows that stay yours are your code and your schema, which are the rows that should be.
Useful related references:
- Managed services and cloud hosting, compared
- Database management services, and what managed removes
- What a managed app actually gives you
- Deploying services on RunxBuild
- Autoscaling between plans
FAQ
Does DigitalOcean offer managed hosting?
It sells unmanaged virtual servers directly, along with a catalogue of managed components such as databases and load balancers. Fully managed server administration is generally offered through a partner rather than as part of the core compute product, which is why the answer depends on which product you buy.
What is the difference between managed and unmanaged hosting?
On unmanaged hosting you get a machine with root access and everything above the operating system is yours: patching, firewall, certificates, backups, monitoring. On managed hosting a provider handles the server administration, usually stopping at the operating system and stock services rather than covering your application.
Is managed hosting worth the extra cost?
It depends on what your hours are worth. An unmanaged server is cheaper as a line item and carries a recurring tax of patching, certificate renewals, backup verification and incident response. For a small team shipping a product, those are usually the most expensive hours available.
What does managed hosting not include?
Your application code, your database schema and queries, your architecture, and usually anything you compiled or installed outside the standard package set. Managed generally means the server is looked after, not that your website is.
Do I need a server at all?
Often not. If the workload is an ordinary web service with a database and some storage, an application platform runs it from a repository without a server in your mental model, and the only rows that remain yours are your code and your data model.