Managed vs unmanaged VPS: which do you need?

Managed vs unmanaged VPS: the short answer

Choosing between a managed vs unmanaged VPS is a labour question, not a product question. Unmanaged means you own patching, the firewall, backups, monitoring, and the reboot at 2am. Managed means the provider does some part of that for you, and the size of that part changes enormously between hosts. The only useful comparison is the list of tasks each plan takes off your hands, priced against your own hours.

There is no standard definition of the word managed. One host means the operating system gets patched and a human answers a ticket. Another means a control panel was installed and everything above it is yours. A third means a written service contract with a response time attached. Two plans carrying the same word can differ in every way that matters, so read the scope document before you read the price. If you are still deciding what the machine is even for, what you can actually do with a VPS is the better question to settle first.

The tasks somebody has to own

Every running server carries the same list of jobs. On an unmanaged plan that list is yours. On a managed plan you are paying to have rows removed from it. Go down the list and write a name next to each one.

• Operating system patching, and the reboots that kernel updates require.
• Firewall rules, kept correct as you add and remove services. The ufw firewall basics for a VPS cover the starting ruleset.
• SSH access: key handling, password login disabled, a key revoked when someone leaves, and a way back in when you lock yourself out.
• Backups, an offsite copy, and a restore you have actually performed.
• Monitoring, which means knowing the box is reachable, the disk has room, the service is still running, and the certificate has not expired.
• Log review, and the response when something in those logs looks wrong.
• Service configuration for the web server, the database, the reverse proxy, and the queue if you run one.
• Certificate renewal, and the repair when automatic renewal stops working.
• Capacity, which means noticing that memory is exhausted before the out of memory (OOM) killer notices for you.
• Incident response, which means being awake and reachable at an hour you do not choose.

Most of those are routine and can be handed to a script. Incident response is the one that cannot, because it needs a person who can decide something. That is the real product a managed plan sells, which is why the checklist further down spends most of its questions on support scope rather than on patching.

What managed usually does not include

This is where buyers get burned, so be exact about it. A managed contract normally covers the operating system and the software the provider installed. It stops at the edge of your application.

Your own code is yours. A 500 error from your application is not a server fault. The provider will confirm that the web server process is running and hand the ticket back. That is a fair boundary. It is also the largest gap between what buyers expect and what they bought.

Application-level problems are usually out of scope. A slow database query, a plugin that broke on update, a cache configured wrong, a mail queue that stopped draining: these sit above the line even when the provider installed the software underneath them.

Most data recovery is out of scope. Provider backups protect the provider's image of the whole server, and they exist for the case where the host hardware fails. They are rarely built for the case where you deleted a row, ran a bad migration, or corrupted a file six weeks ago and noticed today. Ask what the retention window is, whether a single file can be pulled out, and who runs the restore.

Software you installed is yours. Install Docker and the provider generally owns the host while you own everything inside the containers.

Hand edits can void support. Some contracts drop a component out of scope once a customer has edited its configuration directly. Ask about this if you plan to tune anything.

Price your own time against the monthly delta

Take the two quotes in front of you and write down the monthly difference. That number is what the provider charges to remove rows from the list above. Now put a number on your side of the trade.

• What is an hour of your time worth, and how many hours per month does that list take once it is automated?
• What does one hour of downtime cost the thing running on this server?

A steady state Ubuntu box with automatic updates and external monitoring needs very little routine attention. Most months it needs none. Routine work is cheap once a script owns it. Interrupts are the expensive part, and interrupts are what a managed plan sells. If the server runs a hobby project, an outage costs nothing and unmanaged is the obvious answer. If it takes orders, look hard at whether a support contract actually shortens an outage, because a managed provider still has to read your ticket, reproduce the fault, and act on it.

The delta also scales with server count. Managed fees are usually charged per server, while automation is written once and copied. The second server halves the effective cost of the script you wrote for the first, so read how to manage multiple Linux servers before committing to a per-server fee. For the base numbers on either side of the comparison, what a VPS actually costs per month sets the floor, and the VPS versus dedicated server trade-off matters once the workload is big enough that the managed premium is rounding error.

Questions to ask a host before paying the managed premium

Ask before you pay, and ask for the answers in writing. A sales page is not a scope document.

1. What is in scope, task by task? Ask for the list, not the brochure.
2. Does support cover software I install, or only software you installed?
3. Do you patch automatically, and do you reboot for kernel updates without asking me first?
4. Who is responsible if a patch you applied breaks my application?
5. Do you take backups? Where are they stored, how long are they kept, and who performs a restore?
6. Have you restored a customer server recently, and how long did it take?
7. What is the ticket response time, and is it different at 03:00 on a Sunday?
8. Do I keep root access, and does using it reduce what you will support?
9. Is the fee charged per server or per account?
10. If I leave, what do I take with me? A setup that lives inside a proprietary control panel can be hard to export.

Question 5 decides most of the others. A host that answers it precisely is telling you they have done it before. A vague answer means the restore has never been tested, and an untested backup is only a copy. Question 5 also has a location half: where the copies physically sit is a legal question as much as a technical one, and what actually matters when you pick a hosting country goes through that.

The middle path: unmanaged plus automation

Most technical readers want neither extreme. They want an unmanaged plan with the routine work given to the machine, and their own attention kept for the things a machine cannot judge. Set it up on the first day. The first ten minutes on a new VPS is the practical starting point for anyone choosing unmanaged, and hardening SSH access belongs in that same first session.

Automatic security updates

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

That file should now hold APT::Periodic::Update-Package-Lists "1"; and APT::Periodic::Unattended-Upgrade "1";. A missing file, or a 0 on either line, means nothing runs and you will not be told.

Test it without changing the system. Note that the package is unattended-upgrades while the command is singular:

sudo unattended-upgrade --dry-run --debug

The output lists every package it considered and finishes with a line such as No packages found that can be upgraded unattended when nothing is pending. Real runs are written to /var/log/unattended-upgrades/unattended-upgrades.log, so check there rather than guessing.

A kernel update changes nothing until the machine reboots, because the running kernel is the one loaded at boot time. The file /var/run/reboot-required appears when a reboot is pending. Either watch for that file, or let the machine handle it in /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" holds the reboot back while someone is logged in, which is safer on a box you use interactively and useless on one nobody logs into. The full unattended upgrades setup on Ubuntu covers the blocklist syntax and the email options.

Monitoring that runs somewhere else

A monitor running on the server cannot tell you the server is down, because it is down too. Put the check on a second host or on an external service. Uptime Kuma for status monitoring is the usual self-hosted answer, and it belongs on a different machine from the one it watches.

Watch four things at minimum: reachability, disk usage, whether the application answers on its real port, and certificate expiry. Disk is the one that catches people. A log file or a database that grows a little every day takes the box down at a moment nothing else predicts, and the first symptom is often a service that cannot write and exits.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Also add a heartbeat. A timer on the server calls a URL after each successful backup or health check, and the monitor alerts when that call stops arriving. A silent server then produces an alert on its own, which a pull-only check cannot do when the network path is the thing that broke.

Backups you have restored at least once

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init prints created restic repository <id> at sftp:... once. Running it against a repository that already exists fails instead of overwriting, which is the behaviour you want. Keep a copy of that passphrase somewhere off the server: the repository is unreadable without it, and there is no recovery path.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots should list the run you just made with today's date. restic check verifies the repository structure and prints no errors were found. Now do the part most people skip:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

The file you expected is either there or it is not, and finding out now costs ten minutes. Then put the run on a timer so it does not depend on you. Write /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

And /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers shows the next run and the time left. An empty result means you enabled the service instead of the timer, which is the most common mistake here. Persistent=true runs a missed job after the next boot, so a machine that was off overnight still gets its backup. Restic backups on a VPS goes deeper on repository layout and retention, and systemd services and timers explains the unit files line by line.

What automation does not buy you

It does not buy judgement. An automatic reboot at 02:00 happens whether or not your application comes back cleanly, so confirm every service starts on its own and then reboot on purpose while you are awake:

systemctl is-enabled nginx docker
sudo reboot

An unattended upgrade can also install a package that breaks your application, and nothing in the pipeline knows that happened. Your monitor is what catches it, which is why the monitor is not optional once the updates are automatic. The machine covers the routine. The incident is still yours.

When managed is worth the money

Be fair to the managed side. Four situations make it the right purchase.

• Nobody on the team runs Linux, and hiring somebody is not the plan.
• A compliance requirement names a party responsible for patching, and that party cannot be you.
• The stack is one the host specialises in, so their support has seen your failure before.
• The person who would otherwise do the work is your most expensive employee, and one of their hours costs more than a month of the premium.

Managed is not automatically more secure. Managed plans do patch faster than an inattentive owner, and that is a real gain. They also often install a control panel, which is a large network facing application with a login page and a vulnerability history of its own. That can be a reasonable trade, and it is still a trade.

The decision comes down to the same list every time. Write the ten tasks down, mark who owns each one under each quote, then compare the gap to what an hour of your attention is worth. Most technical readers who do that end up unmanaged with the routine handed to a timer, and that is a defensible answer rather than a cheap one.

FAQ

What is the difference between a managed and an unmanaged VPS?

An unmanaged VPS gives you the machine and nothing else, so you own patching, the firewall, backups, monitoring, and the reboot after a kernel update. A managed VPS moves part of that work to the provider, usually the operating system layer and the software they installed for you. The exact boundary is set by each provider rather than by the word itself, so ask for the task by task scope in writing before you compare two prices.

Does a managed VPS mean I do not need my own backups?

No. Provider backups usually protect the provider's image of the whole server and exist for the case where the host fails. They rarely help when you deleted a file, ran a bad migration, or corrupted data weeks ago and noticed today. Ask how long snapshots are kept, whether a single file can be restored, and who performs the restore. Then keep your own offsite copy with a tool such as restic, and test it with restic restore latest --target /tmp/restore-check so you know it works.

Is a managed VPS more secure than an unmanaged one?

Not by itself. A managed plan patches faster than an owner who never logs in, which genuinely reduces risk. Many managed plans also install a control panel, and a panel is a large network facing application with its own login page and its own history of vulnerabilities. An unmanaged box with automatic security updates, a closed firewall, key only SSH, and nothing extra listening is a smaller target than a managed box running a panel.

Can I start unmanaged and switch to managed later?

Usually yes, though it is rarely a checkbox. Providers commonly audit or rebuild a server before they take responsibility for it, because they will not support a configuration they cannot see. Ask what onboarding involves, whether it needs a reinstall, and whether anything you configured yourself stays out of scope afterwards.

Do I keep root access on a managed VPS?

On most managed VPS plans you do, but root access and support scope interact. Some providers reduce or void support for a component you edited by hand, and some will rebuild from their own template if a ticket goes deep enough. Get that rule in writing before you tune anything, and keep your configuration files in version control so a rebuild costs an hour instead of a weekend.