“Managed” and “unmanaged” are among the most loosely used words in hosting. One provider’s managed plan includes round-the-clock monitoring and OS patching; another’s means they replace failed hardware and nothing else. The labels are less useful than a plain list of who does what.

Think in Responsibilities, Not Labels

Every server has the same layers of work, from the physical machine up to the application. Hosting models differ in where the provider’s responsibility stops and yours starts. In practice the useful question is: when something breaks at 3 a.m. in layer X, whose phone rings?

The layers, roughly from bottom to top:

1. Physical hardware, power and network connectivity.
2. Virtualization or the hypervisor, if any.
3. Operating system installation and updates.
4. Security configuration: firewall, access control, hardening.
5. Backups and restores.
6. Monitoring and alerting.
7. Application runtime and databases: web server, database engine, language runtimes.
8. Your own application and data.

An unmanaged plan typically gives you a working machine or virtual machine with network access and a console. Everything from layer three upward is yours. A managed plan moves the line up, sometimes through layer six or seven. Fully managed application platforms move it nearly to the top, at the cost of control.

What Unmanaged Really Means

Unmanaged hosting is not “no support.” Providers still handle their datacenter, hardware failures and network. What you give up is anyone watching your operating system. Specifically, you are responsible for:

• Applying security updates and deciding when to reboot.
• Configuring and testing backups, then actually testing restores.
• Setting up monitoring, and responding to it.
• Hardening SSH, firewalls and services.
• Diagnosing performance problems and capacity planning.

None of this is exotic work, but it is continuous. The most common failure with unmanaged servers is not a hard technical problem; it is that nobody was assigned to do the routine work, and months of missed patches pile up.

What Managed Can and Cannot Cover

Managed plans vary widely, so read the service description closely. Questions worth asking before you sign:

• Which operating systems and software versions do you patch, and on what schedule?
• Do you apply updates automatically, or do you coordinate with me?
• What do you monitor, and what is the response commitment when an alert fires?
• Are backups included, how often, where are they stored, and who performs restore tests?
• Do I get root access, or is it restricted? Can I install my own software?
• What is explicitly excluded, such as application code, database tuning or custom configuration?

A frequent surprise is that managed support covers the server but not your application. If your site is slow because of an unindexed query, a managed operating system will not fix that.

Comparing the Two Approaches

Factor	Unmanaged	Managed
Control	Full access and flexibility	Often limited by provider policy
Required skills in-house	Linux administration, security, backup practice	Less, mostly application-level
Patching and monitoring	You	Provider, within scope
Cost structure	Lower service fee, higher staff time	Higher fee, less staff time
Risk of neglect	High if no owner is assigned	Lower, but verify scope
Flexibility to migrate	Usually easier, standard setups	Can involve provider-specific tooling
Best fit	Teams with sysadmin capacity	Small teams without it

The Real Cost Comparison

The honest comparison is not the monthly fee but the monthly fee plus the cost of your time and your risk. An unmanaged server at a lower price is only cheaper if someone competent has time to run it. If your administrator is also your developer and your support person, the cheap server is quietly expensive.

Conversely, a managed plan is not insurance against everything. If you pay for management but never read the scope, you may discover during an incident that restores, or the specific software you run, were never covered.

A Realistic Example

A small agency runs a handful of client sites on one server. They start unmanaged because it is cheap and one developer knows Linux. A year later that developer leaves, and nobody has applied updates for months, backups write to the same disk and have never been restored. The agency does not necessarily need to give up the unmanaged server; they could document the routine, schedule it and assign an owner. Or they could move to a managed plan whose scope explicitly covers patching and backup verification. What they cannot do is leave the responsibility unassigned, which is what actually went wrong.

A Middle Path

The binary is a false one. Many teams use unmanaged infrastructure with managed pieces: a managed database service, managed DNS, a managed backup product, a managed load balancer. This lets you keep control of the parts you understand and hand off the parts where mistakes are costly, such as database durability.

Whichever you choose, write down the responsibility split. A short document listing each layer and the owner, whether provider or named person, will expose gaps faster than any vendor brochure.

Frequently Asked Questions

Does managed hosting mean I don’t need a sysadmin? Not necessarily. It reduces the work, but someone on your side still needs to manage your application, review what the provider does and handle anything outside the plan’s scope.

Can I get root access on managed hosting? It depends on the provider and plan. Some give full root, some restrict it to protect their management tooling. Confirm before committing if you need custom software.

Is unmanaged hosting less secure? Not inherently, but it is only as secure as the effort put into it. A well-maintained unmanaged server can be very secure; a neglected one is a liability.

Who is responsible for backups on a managed plan? Check the contract. Backup frequency, retention, location and restore testing vary, and some plans include snapshots but not application-consistent database backups.

Can I switch from unmanaged to managed later? Usually yes, though migrations take planning. Keeping your setup standard and documented makes either direction easier.

Next Step

Draw the eight layers above on a page for your current server, and write the name of the responsible party beside each. Any layer with a blank or a shrug is your next priority, whether you fix it with process or with a different hosting plan.