Managed vs Unmanaged VPS: Which One You Need?

Managed vs unmanaged VPS: di short answer

Choosing between managed vs unmanaged VPS na labour question, no be product question. For unmanaged VPS, na you go handle patching, firewall, backups, monitoring, and reboot for 2am. Managed VPS mean say provider go handle some part of these things for you, but how much dem handle fit change well-well between hosts. The only useful comparison na task list wey each plan go remove from your hand, compared with how much your own hours cost.

No standard definition dey for the word managed. For one host, e mean say dem go patch operating system and human go answer ticket. For another one, e mean say dem install control panel, while everything wey dey above am na your responsibility. For third one, e mean say written service contract dey, with response time attached. Two plans fit carry the same word but differ for every important way, so read the scope document before you check the price. If you never decide wetin you even wan use the machine do, wetin you fit actually do with VPS na the better question to settle first.

Di job wey person must take responsibility for

Every server wey dey run get the same list of work. For unmanaged plan, na you own all the work. For managed plan, you dey pay make dem remove some rows from the list. Go through the list and write one name beside each item.

• Operating system patching, plus the reboots wey kernel updates require.
• Firewall rules, wey you must keep correct as you add or remove services. The ufw firewall basics for a VPS explain the starting ruleset.
• SSH access: key handling, disabling password login, revoking key when person leave, and keeping one way to enter again if you lock yourself out.
• Backups, one offsite copy, and restore wey you don actually perform.
• Monitoring, meaning say you know whether the box dey reachable, disk get enough space, service still dey run, and certificate never expire.
• Log review, plus the response when something for the logs look wrong.
• Service configuration for the web server, database, reverse proxy, and queue if you dey use one.
• Certificate renewal, plus repair when automatic renewal stop working.
• Capacity, meaning say you notice when memory don finish before the out of memory (OOM) killer notice am for you.
• Incident response, meaning say you dey awake and reachable for time wey you no choose.

Most of these tasks na routine, and script fit handle dem. Incident response na the one wey script no fit handle by itself, because person must make decision. Na this be the real product wey managed plan dey sell. Na why the checklist down dey ask mostly about support scope instead of patching.

Wetin managed service usually no include

Na for here buyers dey lose money, so make you understand am well. Managed contract normally cover the operating system and software wey provider install. E stop for the boundary of your application.

Your own code na your responsibility. If your application return 500 error, e no be server fault. Provider go confirm say web server process dey run, then return the ticket to you. This boundary make sense. But na also the biggest difference between wetin buyers expect and wetin dem actually buy.

Problems for application level usually no dey included. Slow database query, plugin wey break after update, cache wey dem configure wrongly, or mail queue wey stop to drain: all of dem dey above the support boundary, even when provider install the software wey dem depend on.

Most data recovery no dey included. Provider backups protect the provider image of the whole server, and dem dey for situations where host hardware fail. Dem rarely work for cases where you delete one row, run bad migration, or corrupt file six weeks ago and notice am today. Ask about the retention window, whether dem fit pull out one file, and who go run the restore.

Software wey you install na your responsibility. If you install Docker, provider generally own the host, while you own everything inside the containers.

Manual edits fit cancel support. Some contracts remove a component from the support scope after customer edit its configuration directly. Ask about this if you plan tune anything.

Price your own time against the monthly delta

Take the two quotes wey dey in front of you and write down the monthly difference. Na that number provider dey charge to remove the rows for the list above. Now put your own number for your side of the trade.

• How much one hour of your time worth, and how many hours per month that list dey take after you automate am?
• How much one hour of downtime dey cost the thing wey dey run for this server?

Ubuntu box wey dey stable, get automatic updates and external monitoring, need very little routine attention. For most months, e no need any. Routine work cheap once script dey handle am. Interruptions na the expensive part, and na interruptions managed plan dey sell. If server dey run hobby project, outage no cost anything, so unmanaged na the obvious answer. If e dey take orders, check well whether support contract really dey shorten outage, because managed provider still need read your ticket, reproduce the fault, and act on am.

The difference still dey increase as server count increase. Managed fees normally dey charge per server, while you write automation once and copy am. The second server cut the effective cost of the script wey you write for the first one by half, so read how to manage multiple Linux servers before you commit to per-server fee. For the basic numbers on both sides of the comparison, what a VPS actually costs per month set the floor, and the VPS versus dedicated server trade-off matter once the workload big enough make the managed premium become rounding error.

Questions wey you suppose ask host before you pay for managed premium

Ask before you pay, and make dem give you the answers for writing. Sales page no be scope document.

1. Wetin dey inside the scope, task by task? Ask for the list, no be brochure.
2. Support cover software wey I install, or na only software wey una install?
3. Una dey apply patches automatically, and una dey reboot for kernel updates without asking me first?
4. Who go responsible if patch wey una apply spoil my application?
5. Una dey take backups? Where una dey store dem, how long una dey keep dem, and who dey perform restore?
6. Una don restore customer server recently, and how long e take?
7. How long ticket response dey take, and e different for 03:00 on Sunday?
8. I go still get root access, and using am go reduce wetin una go support?
9. Una dey charge the fee per server or per account?
10. If I comot, wetin I go carry go? Setup wey dey inside proprietary control panel fit hard to export.

Question 5 dey decide most of the other questions. Host wey answer am precisely dey show say dem don do am before. Vague answer mean say dem never test the restore, and backup wey dem never test na only copy. Question 5 get location side too: where the copies physically dey na legal question as well as technical one, and wetin really matter when you dey pick hosting country explain that.

The middle path: unmanaged plus automation

Most technical readers want neither extreme. Dem want unmanaged plan wey give routine work to machine, while dem keep their own attention for things wey machine no fit judge. Set am up for the first day. The first ten minutes on a new VPS na practical starting point for anybody wey choose unmanaged, and hardening SSH access suppose dey part of 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 suppose don contain APT::Periodic::Update-Package-Lists "1"; and APT::Periodic::Unattended-Upgrade "1"; now. If file no dey, or 0 dey for any of the lines, nothing go run and nobody go tell you.

Test am without changing the system. Note say the package na unattended-upgrades, but the command dey singular:

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

The output go list every package wey e consider, then end with line like No packages found that can be upgraded unattended when nothing dey pending. Real runs dey written to /var/log/unattended-upgrades/unattended-upgrades.log, so check there instead of guessing.

Kernel update no change anything until machine reboot, because na the kernel wey load during boot time dey run. File /var/run/reboot-required go appear when reboot dey pending. You fit monitor that file, or make machine handle am for /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" dey hold reboot when person dey logged in. This safer for machine wey you dey use interactively, but e no useful for one wey nobody dey log into. The full unattended upgrades setup on Ubuntu explain blocklist syntax and email options well.

Monitoring that runs somewhere else

Monitor wey dey run for the server no fit tell you say server don go down, because e don go down too. Put the check for second host or external service. Uptime Kuma for status monitoring na the usual self-hosted answer, and e suppose dey for different machine from the one wey e dey monitor.

Monitor four things at minimum: whether server dey reachable, disk usage, whether application dey answer for its real port, and certificate expiry. Disk na the one wey dey catch people. Log file or database wey dey grow small every day fit bring the box down when nothing else predict am, and first sign often na service wey no fit write and then exits.

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

Also add heartbeat. Timer for the server go call URL after each successful backup or health check, and monitor go alert when that call stop to arrive. Silent server go then produce alert by itself, something pull-only check no fit do when na network path break.

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 go print created restic repository <id> at sftp:... one time. If you run am against repository wey already exist, e go fail instead of overwriting am. Na this behaviour you want. Keep copy of that passphrase somewhere outside the server: repository no readable without am, and no recovery path dey.

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 suppose list the run wey you just make, with today's date. restic check go verify repository structure and print no errors were found. Now do the part wey most people dey skip:

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

The file wey you expect either dey there or e no dey, and finding out now na ten minutes. Then put the run on timer so e no 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 go show the next run and the time wey remain. Empty result mean say you enable the service instead of the timer, and na the commonest mistake for here. Persistent=true go run missed job after next boot, so machine wey dey off overnight still go get backup. Restic backups on a VPS go deeper into repository layout and retention, while systemd services and timers explain the unit files line by line.

What automation does not buy you

Automation no buy judgement for you. Automatic reboot for 02:00 go happen whether your application return cleanly or not, so confirm say every service fit start by itself, then reboot on purpose while you dey awake:

systemctl is-enabled nginx docker
sudo reboot

Unattended upgrade fit also install package wey break your application, and nothing for the pipeline go know say e happen. Na your monitor go catch am, and na why monitor no optional once updates become automatic. Machine go handle routine work. The incident still na your responsibility.

When managed plan worth the money

Make we fair to managed option. Four situations fit make am the correct choice.

• Nobody for the team dey run Linux, and hiring person no dey part of the plan.
• Compliance requirement name one party wey dey responsible for patching, and that party no fit be you.
• The stack na one wey the host specialise in, so their support don see your kind failure before.
• The person wey for do the work otherwise na your most expensive employee, and one hour of their time cost pass one month of the premium.

Managed plan no automatically more secure. Managed providers fit patch faster than owner wey no dey pay attention, and that one na real benefit. Dem also often install control panel, wey be big network-facing application with login page and vulnerability history of its own. That fit be reasonable trade-off, but e still be trade-off.

The decision always come down to the same list. Write the ten tasks down, mark who owns each one under every quote, then compare the difference with wetin one hour of your attention worth. Most technical readers wey do this end up unmanaged, with the routine handed to a timer. That answer make sense; e no be only because e cheap.

FAQ

Wetin be difference between managed and unmanaged VPS?

Unmanaged VPS go give you the machine and nothing more, so na you go handle patching, firewall, backups, monitoring, and reboot after kernel update. Managed VPS go shift part of this work to the provider, usually the operating system layer and the software wey dem install for you. Each provider dey define the exact boundary differently, so ask dem to write the scope task by task before you compare two prices.

Managed VPS mean say I no need my own backups?

No. Provider backups usually protect the provider image of the whole server and dey useful when host fail. Dem rarely help if you delete file, run bad migration, or corrupt data weeks ago and notice am today. Ask how long dem dey keep snapshots, whether dem fit restore one file, and who go perform the restore. Then keep your own offsite copy with tool like restic, and test am with restic restore latest --target /tmp/restore-check so you go know say e dey work.

Managed VPS more secure than unmanaged one?

No be by itself. Managed plan dey patch faster than owner wey never log in, and this really reduce risk. Many managed plans still install control panel, and panel na big network-facing application with its own login page and history of vulnerabilities. Unmanaged box wey get automatic security updates, closed firewall, key-only SSH, and nothing extra wey dey listen, na smaller target than managed box wey dey run panel.

I fit start unmanaged and switch to managed later?

Usually yes, but e rarely be just one checkbox. Providers commonly audit or rebuild server before dem take responsibility for am, because dem no go support configuration wey dem no fit see. Ask wetin onboarding involve, whether e need reinstall, and whether anything wey you configure yourself go remain outside scope afterwards.

I go keep root access for managed VPS?

For most managed VPS plans, yes, but root access and support scope dey affect each other. Some providers go reduce or cancel support for component wey you edit by hand, and some fit rebuild from their own template if ticket go deep enough. Get this rule for writing before you tune anything, and keep your configuration files for version control so rebuild go cost one hour instead of one weekend.