Web Hosting vs Managed Hosting: Where the Gap Bites

This page explains the practical difference between web hosting and managed hosting, maps every operational task that sits between a hosting plan and a working website, and shows who owns each one under each model. It is written for IT managers, digital leads and marketing managers who are not sure what their current provider is actually responsible for.

The question behind the question: who patches the application?

Most hosting comparisons are specification comparisons. vCPU count, RAM, NVMe storage, bandwidth allowance, data centre location. Those numbers matter, but they are not what separates a hosting plan from a managed service, and they are almost never the reason a website fails.

The real question is narrower and more awkward. When a CVE is published against your CMS core, a Composer package three levels deep in your dependency tree, or the OpenSSL build on your operating system, who reads the advisory, decides whether your installation is affected, tests the patch against your theme and custom modules, deploys it, and verifies the site still works afterwards? If you cannot name a company and a contract clause, the honest answer is that nobody does it, and it is being done late or not at all.

That gap is where unmanaged hosting bites. Not on day one. Usually somewhere between month nine and year three.

What a hosting plan actually sells you

Unmanaged hosting sells compute, storage, network and power. The provider's obligation ends at the boundary of the thing they can see from their side, which is the server, not the website running on it.

Shared, VPS and cloud instances

On shared hosting, the provider patches the operating system and the web server because those are shared with hundreds of other tenants, and an unpatched kernel is their risk, not just yours. They do not touch your application. You typically have no root access, limited control over PHP extensions, and no ability to tune a web application firewall for your specific traffic.

On a VPS or a cloud instance (an EC2 instance, a droplet, a Compute Engine VM), the provider's obligation drops further. They guarantee the hypervisor, the virtual network and the block storage. Everything from the operating system upward is yours: apt or yum updates, kernel reboots, MySQL version upgrades, PHP end-of-life migrations, Nginx configuration, TLS cipher suites, fail2ban, log rotation, disk space monitoring. AWS and Azure publish this explicitly as a shared responsibility model, and the line sits a long way below your website.

Where "we keep the server up" legally ends

Read the SLA of an unmanaged plan and you will usually find the uptime commitment applies to network availability and host power, measured at the hypervisor. A server that responds to ICMP while PHP-FPM has exhausted its worker pool and every page returns a 502 is, under that definition, up. A server where the database has filled the disk with binary logs and MySQL has stopped accepting writes is up. A server serving a defaced homepage is up.

Credits are typically a percentage of the monthly fee for the affected period, which on a modest plan is a few dollars. That is not a risk transfer. It is a rounding error against the cost of a lead generation site being offline for a working day.

What managed hosting adds on top

Managed hosting moves the responsibility boundary up the stack so it sits above your application rather than below your operating system. Three areas carry most of the value.

Platform and dependency patching

This is the work that nobody volunteers for. WordPress core and plugin releases, Silverstripe recipe updates, Drupal security advisories on their published Wednesday cadence, Composer and npm transitive dependencies, PHP minor and major version moves before a branch reaches end of security support, MySQL and PostgreSQL engine upgrades.

Done properly, each patch is applied to a staging environment first, run against the site's critical paths, and deployed through a repeatable pipeline with a tagged rollback point. Done improperly, it is a one-click update in production on a Friday afternoon that white-screens a payment form nobody tests until Monday. The difference is process, not tooling, and it requires development capability rather than system administration alone. Ongoing managed services scope is where that capability is defined or quietly omitted.

Backup restore testing, not backup existence

Nearly every host takes backups. Far fewer can tell you the last time one was restored into a working environment and verified. A backup that captures the file system but not a consistent database dump, or captures the database but excludes the uploads directory, is discovered to be useless at exactly the moment it is needed.

A managed arrangement should state a recovery point objective (how much data you can afford to lose, which drives backup frequency) and a recovery time objective (how long a full restore takes), and should prove both with a periodic test restore rather than a line in a brochure.

WAF tuning, certificate lifecycle and DNS

A web application firewall left on default OWASP Core Rule Set settings will block legitimate form submissions containing SQL-like words, apostrophes in surnames, or long rich text fields from your own CMS editors. Tuning rules against real traffic, setting rate limits that protect login and search endpoints without throttling a campaign spike, and maintaining bot rules is ongoing work. So is configuring an edge layer properly rather than just switching the proxy on.

Certificates are a recurring failure point because they are invisible until they are not. Let's Encrypt certificates last 90 days, and ACME renewal fails silently when a redirect rule blocks the HTTP-01 challenge path or a DNS provider API token expires. Add CAA records, HSTS preload decisions, and SPF, DKIM and DMARC alignment for transactional mail, and you have a set of expiring assets that need an owner.

Responsibility matrix: shared hosting vs VPS vs managed hosting vs management only

The table below is the practical version of the question. Read down the rows and name the company that owns each one today.

Rows three through thirteen are the ones that decide whether your website survives its third year. On shared hosting most of them have no owner at all. On a self-managed VPS they are all yours, which is fine if you employ a system administrator and a developer who can be reached at 2am, and a problem if you do not.

The two-vendor gap and how blame gets distributed

The common arrangement is a hosting company for infrastructure and a web agency for the build. It works until something ambiguous breaks.

The site slows to eight seconds on category pages. The host shows CPU at 30 percent and says the server is healthy. The agency says the code has not changed since the last release. Both are telling the truth. The actual cause is an unindexed join that only degrades past a certain row count, which is a development problem visible only through infrastructure telemetry that the developer cannot see and the host does not read.

Or a deployment fails because the host upgraded PHP from 8.1 to 8.3 on a maintenance window nobody forwarded to the agency. Or a WAF rule introduced in a managed ruleset update starts blocking the CMS preview endpoint. In each case there is a correct answer and no single party responsible for finding it, so the client becomes the integrator and pays for the time in both directions. The alternative is a single provider who holds one SLA covering both the server and the application, so there is nobody to hand the ticket to.

Signals you have outgrown unmanaged hosting

• You cannot name the PHP, Node or database version your production site runs, or when that version reaches end of security support.
• Plugin or module updates are deferred because the last one broke something, so the installation is now several major versions behind.
• Your most recent restore test was the last time you had an actual outage.
• Monitoring consists of a free ping check on the homepage, which returns 200 even when checkout, search or form submission is failing.
• A security questionnaire, penetration test or UpGuard rating has surfaced findings such as missing security headers, weak TLS configuration or exposed admin paths, and nobody owns remediation.
• The person who originally configured the server has left, and the credentials live in a spreadsheet.
• After-hours incidents depend on a developer's goodwill rather than a response time you have paid for.

Any two of those together is enough. Public sector and regulated organisations usually find the compliance trigger arrives first, because a questionnaire asks for evidence of patch cadence and backup testing that an unmanaged arrangement simply cannot produce.

What changes operationally when you move

The transition itself is the part people fear and it is largely procedural. An infrastructure audit establishes what is actually running, which is rarely what the documentation says. Dependencies are inventoried, end-of-life components flagged, and anything that will block a clean rebuild is identified before a single byte moves. The cutover is then rehearsed on a staging environment with DNS TTLs dropped in advance, so the switch between hosts happens without downtime rather than during a declared outage window.

After cutover, the day to day looks different in ways that are easy to measure. Patching runs on a published cadence with staging validation. Vulnerability scanning and CVE monitoring is matched to your installed package versions rather than generic alerts. Backups run every six hours with tested restores. Monitoring checks real transactions, not just the homepage, and alerts a person rather than an inbox. Incidents get a written root cause. None of that is exotic. It is just work that has to belong to somebody.

Frequently Asked Questions

What is managed hosting?

Managed hosting is a service where the provider is responsible for the server and the software running on it, including operating system patching, runtime and database upgrades, CMS and dependency updates, backups, security monitoring and incident response. Unmanaged hosting supplies compute, storage and network only, and stops at the operating system boundary or below it. The practical test is whether your provider will apply a CMS security patch for you, with staging validation and a rollback plan.

What is the difference between web hosting and managed hosting?

Web hosting sells infrastructure capacity and guarantees that the server is powered, networked and reachable. Managed hosting adds ownership of everything above that line: patching, configuration, backups with tested restores, firewall tuning, certificate renewal, monitoring and response. The difference shows up in the SLA, where an unmanaged plan measures uptime at the hypervisor and a managed plan measures whether your website is actually serving correct pages.

Does managed hosting include security monitoring?

It should, but the term is used loosely, so ask what is specifically covered. A genuine security component includes CVE monitoring matched to your installed package and plugin versions, a tuned web application firewall rather than default rules, file integrity and login monitoring, certificate and DNS record management, and a defined response process when something is detected. If the provider cannot describe how a published advisory becomes a deployed patch on your site, the monitoring is cosmetic.

Is managed hosting worth it for a small website?

It depends on what the website does rather than how large it is. A brochure site with no forms, no logins and no revenue attached can reasonably run on unmanaged hosting with an annual tidy up. A site that generates leads, takes payments, holds personal data or carries a brand that cannot be seen defaced justifies the managed model, because the cost of a single extended outage or breach usually exceeds several years of the difference in fee.

Can I keep my existing AWS or Azure account and still get managed services?

Yes. A management-only arrangement leaves the cloud account, billing relationship and committed spend with you, while the provider takes responsibility for patching, monitoring, backups, security configuration and incident response inside that environment. This is common for organisations with procurement agreements, cloud credits or internal policies requiring infrastructure to sit in their own tenancy.

How do I work out what my current host is responsible for?

Read the service agreement rather than the marketing page, and look for three things: how uptime is defined and measured, whether application-layer software is explicitly in or out of scope, and what the response time commitment is outside business hours. Then run the responsibility matrix above against your own arrangement and name a company for each row. Any row where the answer is nobody is an unmanaged risk you are currently carrying.

Talk to UnDigital about managed hosting

UnDigital runs managed hosting for enterprise websites across WordPress, Silverstripe, Drupal, Craft, Statamic, headless stacks and custom applications, under three models: hosting plus management, hosting only, or management only on your existing AWS or Azure infrastructure. We are both the infrastructure provider and the development team, which removes the vendor gap entirely.

Every engagement starts with an infrastructure audit rather than a quote, because the only useful conversation begins with what is actually running. If you want to sanity check the market first, our guide on what to look for in managed website hosting in Australia sets out the questions worth asking any provider, including us.