A managed VPS means somebody else keeps the operating system patched, the firewall sane and the backups running, while you look after your own applications. An unmanaged VPS, which most hosts label self-managed, hands you the whole machine and every one of those jobs. The decision is a budget question about your hours and your skills.
Feature lists will not settle it, because both sides of the comparison ship the same server. Same CPU and memory, same root password. What differs is who gets the alert at two in the morning, and who is expected to know what to do with it before the site has been down long enough for a customer to notice.
Managed vs Unmanaged VPS: What Each Side Owns
The line falls at the operating system. Below it sits everything that keeps a Linux box alive and reachable: kernel and package updates, the firewall, service supervision, certificates, backups. Above it sits your code, your database schema, your CMS and its plugins, your content.
On a self-managed VPS you own both halves. On a managed VPS the host takes the lower half and leaves the upper half with you, which is why a managed plan does not save you from a WordPress plugin that opens a hole in your own site. That distinction catches people out more than any other, and it is worth stating plainly before you spend money on the assumption that managed means somebody is watching your application.
The Jobs That Land on You
Here is the actual work of running an unmanaged box. None of it is difficult. All of it is recurring, and the failure mode of every item is that nothing appears to be wrong for months.
Security updates come first. Somebody has to apply them, and somebody has to know which ones need a restart afterward. On Debian and Ubuntu that means either sitting down with apt list --upgradable on a schedule you actually keep, or configuring unattended upgrades and then verifying that they are running, which is the step people skip. A kernel update does nothing until the machine reboots, and the needrestart package exists because half the services still running against a patched library have no idea they should be restarted.
Firewall rules are next, and they are easier to set than to keep. A fresh VPS usually arrives with whatever ports its distribution opens by default and nothing in front of them. Deciding what stays reachable takes five minutes with ufw or nftables. Remembering to close the port you opened for one afternoon of debugging, six weeks ago, is the hard part.
Then backups, which nobody sets up on a server they just built. Later the box is real and carrying something, and a backup means installing restic or borg, giving it somewhere off the machine to write to, and then restoring from it once while nothing is on fire. A backup you have never restored is a hypothesis.
Service supervision is quieter and catches people worse. MySQL gets killed by the out of memory killer at three in the morning. Was the unit configured to come back? Did anything tell you it had gone? systemctl edit and a Restart=on-failure line take a minute, and that minute only gets spent by somebody who has thought about the question in advance.
Full disks take down more small servers than attacks do. A verbose application log with no logrotate entry fills a partition eventually, and the symptom is not a message about disk space, it is a database that will not start.
Certificates round it out. Renewal is automated now and certbot handles it well, but the timer still has to be enabled and the renewal hook still has to reload the web server. An expired certificate stops every visitor at the door. It always happens on a weekend.
That is the routine list. It leaves out the interesting problems, the ones where a service will not start and the answer is somewhere in journalctl -xe, because those are unpredictable by definition and they are the ones that cost you an entire evening.
Put a Number on Your Own Hours
Skip the feature grid. Do the arithmetic.
Take what an hour of your time is worth, whether that is your billing rate or what you would pay somebody else to cover the same hour. Estimate the routine maintenance: patching, checking that backups ran, glancing at logs. Then add the part that people leave out of the estimate, which is the incident. Not many per year, but each one arrives without warning and takes exactly as long as it takes, usually on the evening you had planned something else.
Now compare that total against the difference in monthly price between a managed plan and a self-managed one. For most people running one or two business sites the managed premium loses the routine comparison and wins the incident comparison, and the incident comparison is the one that matters, because the routine hours were survivable and the four hour outage on a Saturday was not.
There is a second cost that never shows up in the arithmetic. Deferred maintenance on a server you administer yourself accumulates quietly: the distribution goes end of life, the PHP version stops receiving security fixes, the upgrade path gets longer every month you leave it. On a managed plan somebody else is holding that clock. That is the strongest argument for paying the premium, stronger than the hourly comparison, and it is the one I would make to anybody whose server is not the thing they work on daily.
What Does "Managed" Actually Cover?
Coverage varies enormously between providers, and the word "managed" is doing very different work on different order pages. Some plans mean the host patches the operating system and nothing else. Some include monitoring with somebody responding to it. Some cover the web server and database configuration. Some are effectively a retainer for an administrator who will do what you ask.
You cannot infer which one you bought from the plan name, and the moment you find out is otherwise the moment you need it. So ask before you order, in writing, through the support channel you would use in an emergency. Four questions get you most of the way:
- Who applies operating system and kernel updates, and does a reboot for a kernel update happen automatically or wait for my approval?
- Are backups included, where are they stored, how far back do they go, and do I restore them myself or open a ticket?
- If a service stops at three in the morning, does anything notice, and does anybody act on it?
- If I break the server myself with a bad configuration change, is fixing it in scope?
Question four separates the real answers from the marketing ones. A host that will untangle a configuration change you made yourself is selling a different product from one that reinstalls the operating system and wishes you luck, and the gap in price between those two is usually smaller than the gap in what they are worth to you. Everybody covers the tidy case. What you are buying is coverage of the untidy one.
If You Have Never Administered a Server, Read This Part
There is a version of this decision that is not about money. If you have not run a Linux server before, a self-managed VPS is an excellent way to learn and a poor place to keep something that earns you money. Both statements are true at once. Keep them on separate machines.
Build the learning box. Break it, rebuild it, and do that until a fresh server with a firewall, a web server, automatic updates and a working restore takes you an hour instead of a day. Then decide about the production one, from a position where you know exactly what you would be taking on. The people who get hurt are the ones who chose unmanaged to save money, discovered the workload afterward, and ended up with neither the skills nor the budget.
The Two Options, Side by Side
Read the middle rows first. The hardware and the application are identical on both sides, so the only rows that should move your decision are the ones describing work somebody has to perform every week whether or not anybody remembers to schedule it.
| Managed VPS | Self-managed VPS | |
|---|---|---|
| OS and kernel updates | Host applies them | Yours, including the reboot |
| Firewall | Configured for you, usually to a standard policy | Yours to design and maintain |
| Backups | Commonly included, scope varies | You install, schedule and test them |
| Service failures | Somebody may notice, ask first | You notice, or your visitors do |
| Your application | Yours either way | Yours either way |
| Root access | Normally yours, sometimes shared | Yours alone |
| Cost | Higher monthly, lower time | Lower monthly, unbounded time |
| Suits | Anybody whose server is not their job | People who administer Linux already |
Which One to Order
| If this is you | Take |
|---|---|
| Small business owner, one site, no sysadmin on staff | Managed |
| Agency running client sites, no dedicated ops person | Managed |
| Developer comfortable in a shell, personal or side projects | Self-managed |
| Team with somebody who already administers Linux servers | Self-managed |
| Learning deliberately, nothing on the box that earns money | Self-managed |
| Running something unusual: custom kernel, VPN, container host | Self-managed, and expect the work |
One note to end on, because it is the most common misunderstanding about managed plans. Root access is normally still yours. Managed does not mean locked down, and it does not turn the server into shared hosting with extra steps: you can still install and compile what you like, and edit any configuration file on the machine. What changes is that somebody else has a baseline they maintain, and configuration changes you make outside it may take you outside what they will support. Ask how that works before you start rebuilding their nginx configuration.
If you are still deciding whether a VPS is the right tier at all, start earlier than this page. The signs that a site has outgrown shared hosting settle that question, and the VPS hosting definition covers what the tier actually is.
If the tier is settled and management level was the open question, one choice remains underneath it, and it has a cleaner answer: OpenVZ or KVM turns on whether your software needs its own kernel. BestPaidHosting lists its VPS plans by virtualization type, so answer the management question first and the plan pages will read more easily when you get to them.