[ guide ]

Managed vs unmanaged VPS: what you actually get and when it is worth paying

Published

A virtual private server (VPS) is cheap and powerful, and the price on the order page is only part of the cost. The real question is who keeps it secure, backed up and running. This guide explains what you get with an unmanaged server, what “managed” can mean, and how to decide.

What an unmanaged VPS includes

With an unmanaged VPS the provider is responsible for everything below the operating system:

  • the physical hardware, power, cooling and the virtualisation layer;
  • network connectivity and usually some protection against network-level attacks;
  • a web console or rescue system to reach the machine when SSH does not work;
  • operating system images to install from;
  • often, as paid extras, snapshots or backups of the whole virtual disk.

Everything inside the operating system is yours:

  • installing security updates and planning major upgrades;
  • the firewall, SSH access, users and keys;
  • the web server, TLS certificates, databases and application runtimes;
  • backups of your data that you have actually restored at least once;
  • monitoring, and noticing when something breaks at 3 a.m.;
  • responding to security incidents and to abuse reports about your server.

Provider snapshots are useful, but they are not a backup strategy on their own: they usually live with the same provider, restore the whole disk rather than a single database, and are only as good as their schedule.

What “managed” can mean

There is no standard definition. Offers labelled “managed” usually fall into one of three groups:

Level Typically included Typically not included
Panel-managed A control panel, operating system updates, basic monitoring Your applications, custom software, anything outside the panel
System-managed Operating system and core services (web server, database) kept updated and monitored, backups Application-specific work, deployments, code-level issues
Fully managed Setup tailored to your stack, updates, backups with restore tests, monitoring, changes on request, help with incidents Writing your application code

Two offers with the same label can differ completely. What counts is what is written in the agreement.

Questions to ask before paying for management

Updates

  • Which updates are applied automatically, and who decides on major upgrades?
  • What happens when an upgrade breaks something?

Backups

  • What exactly is backed up (files, databases, mail, configuration), how often, and where is it stored?
  • How long are backups kept, and when was a restore last tested?
  • How quickly can a single database or file be restored, and do you pay extra for it?

Monitoring and response

  • What is monitored, and who receives the alerts?
  • How do you report a problem, and what response can you expect? Is that written down?

Access and control

  • Do you keep root or administrator access? Can you install your own software?
  • Is the server in your account with the provider or in theirs?

Scope

  • Is your application covered (for example a PHP version upgrade, a Node.js service, Docker containers)?
  • What counts as extra work, and how is it charged?

Leaving

  • Can you take the server, data and documentation with you if you move on?
  • Is the setup documented well enough for someone else to take over?

Clear answers to these are worth more than a long feature list.

Thinking about cost

The management fee is easiest to judge against the time it replaces. Estimate, honestly, how many hours a month routine care takes on your servers: updates, checking backups, renewing things, small fixes and questions. Add the rare large events: an operating system upgrade, a migration, a compromised plugin, a full disk on a Friday evening. Multiply by what that time is worth to you, and compare.

Then add what the fee cannot easily show: the cost of an outage for your business or your client, and the cost of a breach, including the time spent finding out what happened.

When an unmanaged VPS makes sense

  • Learning, side projects and test environments.
  • Your team includes someone with operations experience and time set aside for it.
  • Workloads that can be rebuilt from scratch automatically and keep no important data on the server.
  • You need full control and accept full responsibility.

When managed makes sense

  • The site or application is business-critical and nobody in-house owns its infrastructure.
  • Agencies hosting many client sites that need consistent, documented setups.
  • You run your own mail server, where small configuration mistakes hurt deliverability.
  • Customers or regulations expect documented backup, update and access procedures.

A middle ground: your server, managed by someone else

Management does not have to come from the company that rents you the hardware. You can rent the server in your own account with a provider that fits your budget and location, and have an independent administrator run it. You keep ownership and the ability to switch either side, and the person maintaining it knows your setup instead of a generic image. This is the model we work with at h4me.

Whichever way you choose, write down who is responsible for what. Most hosting trouble starts in the gap between “I thought the provider did that” and “we never offered that”.

Tell us what you need.

Describe your project, stack and timeline. We reply with questions or a proposal.

Discuss your project