The difference between managed and unmanaged VPS hosting is not how much RAM or CPU you get. It is who keeps the server usable after it is switched on.
With an unmanaged VPS, the provider normally runs the physical infrastructure and virtualisation platform while you operate the server itself. With a managed VPS, the provider takes responsibility for an agreed part of the server layer. The important words are an agreed part. “Managed” is not a universal promise that every update, backup, application problem or 2am incident belongs to the host.
Your buying decision should therefore start with a written responsibility map, not the label on the pricing card. If you are still deciding whether you need a VPS at all, settle the shared hosting versus VPS question first. Once a VPS is the right tier, use this guide to decide who should run it.
Managed vs unmanaged VPS hosting: the practical difference
An unmanaged or self-managed VPS gives you control and responsibility together. You receive a virtual machine, an operating system choice or image, network connectivity and administrative access. Your team then configures the guest operating system, web server, firewall, runtime, database, users, monitoring, backups and recovery process.
A managed VPS moves some of that server work to the provider. Depending on the service, management may include initial setup, supported operating-system updates, server hardening, control-panel maintenance, service monitoring and help diagnosing server faults. It may also exclude your website code, WordPress plugins, custom software, data, third-party integrations and changes made outside the supported configuration.
Neither option removes shared responsibility. The provider still owns the physical host, network and virtualisation layer within its service. Your business still owns its data, user access, application decisions, supplier coordination and recovery priorities. Management changes the line between those layers; it does not erase the line.
VPS responsibility matrix: who handles what?
This matrix describes common patterns, not the Allanux offer or a promise from any provider. Use the final column as a scope checklist and get the answer in writing before you buy.
| Task or layer | Unmanaged VPS: typical owner | Managed VPS: typical owner | What to confirm |
|---|---|---|---|
| Physical hardware, data-centre network and virtualisation platform | Provider | Provider | What the infrastructure status page and service terms actually cover |
| Initial operating-system deployment | Provider image; customer configures it | Often provider within supported options | Supported operating systems, base image, rebuild process and handover state |
| Operating-system and security patches | Customer | Often provider for the supported server stack | Patch scope, schedule, reboots, maintenance windows and excluded packages |
| Firewall, SSH access and server hardening | Customer | Provider or shared, depending on the service | Initial hardening, ongoing review, allowed ports, root policy and who approves changes |
| Web server, PHP/runtime, database and control panel | Customer | Often provider only for listed supported components | Exact versions, licences, update ownership and whether custom modules remain supported |
| Website, CMS, plugins, themes, custom code and content | Customer or developer | Usually customer or developer | Whether application maintenance is separate from server management |
| Monitoring | Customer configures service and application alerts | Provider may monitor defined server services | What is monitored, how often, who receives alerts and whether the provider acts or only notifies |
| Backups | Customer chooses, configures and checks them | Provider may supply a defined backup service | Files, databases, frequency, retention, location, exclusions, encryption, restore access and fees |
| Restore testing and recovery decisions | Customer | Usually shared | Who runs a test, chooses a clean restore point, approves data loss and verifies the application afterwards |
| Incident diagnosis and response | Customer leads above the infrastructure layer | Provider handles the contracted server scope; customer leads business and application decisions | Severity definitions, contact path, evidence, containment authority, response expectations and exclusions |
| Migration and cutover | Customer or hired specialist | May be included once or sold separately | Files, databases, email, DNS, testing, rollback and who controls the final switch |
| Root or administrator access | Customer | Varies by provider and management model | Whether root is supplied, what changes are allowed and which changes fall outside support |
The biggest buying mistake is leaving a row as “probably the host”. If the service description, support policy and order confirmation do not assign it, treat it as unassigned until someone confirms otherwise.
What you take on with an unmanaged VPS
Unmanaged hosting is not simply the cheaper version of the same service. It replaces a provider-managed operating function with your own people, tools and process.
Build and harden the server
Your team needs to create users, protect administrative access, configure the firewall, install the web stack, secure services and remove anything the workload does not need. A control panel can simplify routine administration, but it does not decide your security model or become an on-call systems administrator.
Patch without breaking production
Operating-system, web-server, runtime, database and control-panel updates need an owner. That owner must know what is exposed, watch security notices, schedule changes, handle reboots and verify that the application still works afterwards. Delaying every update is risky; applying every change blindly is not a maintenance plan either.
Monitor the service and respond to alerts
A graph is not monitoring unless someone sees the alert and knows what to do. Decide who watches CPU, memory, disk, failed services, certificate expiry, backup jobs and application health. Then define escalation: who can restart a service, block traffic, roll back a release or call the provider when the fault is below your server.
Own backup and recovery
Choose what is backed up, how often, where copies live and how long they are kept. Then restore a representative copy in a safe place and test the website or application. A completed backup job proves that a copy was written; a restore test is what tells you whether the copy can support recovery.
Carry the incident queue
If the server is compromised, overloaded or misconfigured, your team leads diagnosis above the provider's infrastructure boundary. That includes preserving useful evidence, deciding whether to isolate or rebuild, selecting a clean recovery point, rotating credentials and checking the application before normal traffic returns.
This workload can be a good fit for a capable development or infrastructure team. It is a poor fit when “we know Linux” really means one person can sometimes log in, nobody carries after-hours alerts and the restore process exists only in someone's memory.
What a managed VPS may cover — and where it often stops
Managed VPS hosting buys access to an operating function, not unlimited technical labour. A strong service has a clear supported stack, defined maintenance work and an escalation route. A weak one relies on the word “managed” and leaves the customer to discover the exclusions during an incident.
Server management is not automatically website maintenance
The provider may patch the operating system, web server, database service and control panel while your developer still owns WordPress core, plugins, themes, custom code, checkout faults and third-party integrations. If a website breaks after an application update, that can sit outside a server-management agreement even when the VPS itself is healthy.
Monitoring does not always mean remediation
One provider may monitor whether the virtual machine and core services respond, then act when they fail. Another may monitor only the underlying platform. A third may send an alert but wait for you to open a ticket. Ask what signal triggers action, what the first action is and who is contacted.
Backups and restores are separate questions
“Backups included” does not answer whether the database is captured consistently, how much history is retained, whether copies sit outside the live server, who can request a restore or how long a restore normally takes. It also does not assign post-restore application testing. Get the whole recovery chain, not one checkbox.
Root access can change the support boundary
Some managed services provide root access; others restrict it to protect a standard configuration. Where root is available, custom repositories, security tools, kernels, services or control-panel changes may be excluded from management. That is not automatically good or bad. It is a trade-off between freedom and a supportable baseline.
South African providers currently use different models across self-managed VPS, managed cPanel and fully managed server offers. Compare the written task boundary, support hours and escalation route—not just the monthly Rand price or the word on the card. The broader shared, VPS and dedicated hosting comparison can help if your real uncertainty is still the server tier rather than who manages it.
Questions to ask a VPS provider before you buy
Send these questions before checkout and keep the answers with the account. They are more useful than a feature list when something goes wrong.
- Which operating system, control panel, web server, runtime and database components do you install and maintain?
- Who applies security patches, how are reboots handled and can we agree on a maintenance window?
- What hardening is done at setup, and what ongoing security work is included?
- What do you monitor on our VPS, what triggers action and do you remediate or only notify?
- What exactly is backed up, how often, for how long and where are copies stored?
- Who can request a restore, is restore work included and how do we test it before an emergency?
- Do you support our CMS or application, or only the server beneath it?
- Will we have root access, and which custom changes move the server outside your supported configuration?
- What migration work is included: files, databases, email, DNS, testing and rollback?
- What happens when the server is compromised or a core service fails outside business hours?
- Which support channels, hours, severity levels and escalation paths apply to this plan?
- If we leave, what handover, backup export, credentials and configuration records can we take with us?
If the answer is “contact support when it happens”, ask again. You need to know what support is authorised and equipped to do before the incident, not while the website is already down.
Which option fits your team?
Choose unmanaged when you already have the operating capability
An unmanaged VPS can be the right choice when your team regularly administers Linux or Windows servers, automates configuration, runs useful monitoring, maintains tested backups and has someone available to respond. It also suits workloads that need a custom stack or root-level freedom a managed baseline would restrict.
Do not choose it only because the monthly server price is lower. Add the time for maintenance, licences, monitoring, backup storage, incident response and the person covering leave or after-hours faults. The fair comparison is total operating cost and risk, not one invoice line.
Choose managed when server operations are not your business
A managed VPS usually fits a revenue-producing website, ecommerce store or client-hosting environment where the business needs dedicated resources but does not employ a systems administrator. It gives the server layer a named operator and support path, provided the contract covers the tasks you actually need.
You still need an application owner. The person who understands the website, deployment, database changes, plugins, integrations and customer journey may be your developer or maintenance partner rather than the VPS provider.
Use a split model when the skills live with different suppliers
Many small businesses need a managed server plus a separate developer or website maintainer. That is a sensible model when the handoff is explicit: the provider keeps the supported server stack healthy; the developer maintains the application; the business owns access, data priorities and incident decisions.
If you are still choosing across shared, WordPress and VPS plans, use the business hosting guide for South Africa to settle the platform first. Do not pay for server control your team cannot operate, and do not buy management that stops below the layer where your failures usually happen.
