Managed VPS or managed website? The responsibility gap that matters

A managed VPS and a managed website solve different problems. One can keep the server environment maintained while the other keeps the application itself working. Sometimes a provider offers both. Often it does not.

That difference becomes important when a client website fails. If nobody knows whether the fault belongs to the network, operating system, web runtime, application code or a third-party integration, “managed” is not a useful incident plan.

The practical question is not “Is this hosting managed?” It is:

Which named party is responsible for each layer, during normal maintenance and when something goes wrong?

Start with six layers

Use the following model before comparing providers or prices.

The layers are connected, but that does not make them interchangeable. A provider can maintain the operating system while the agency remains responsible for a plugin that breaks after an update. An agency can repair code while a failed database service first needs attention from its named owner: the provider only if that component is included in the applicable service schedule. Some faults need both parties.

The UK National Cyber Security Centre describes cloud security and availability as a shared responsibility whose allocation depends on the service and the provider's implementation. It also notes that a managed service provider can become a third participant because it may retain privileged access. Microsoft's public cloud model makes the same underlying point: moving from infrastructure services towards more managed platforms transfers some operating-system and runtime work, while the customer still retains responsibilities such as data, identities, configuration and application controls.

These models are not your contract. They are prompts to make the contract and operating handover explicit.

What a managed VPS may cover

A managed VPS commonly starts below the application layer. Depending on the actual service schedule, it may include work such as:

• maintaining a supported operating system;
• applying agreed security updates;
• configuring named web or database services;
• monitoring selected platform signals;
• investigating faults within the managed server components;
• maintaining an agreed backup or recovery mechanism;
• providing a support and escalation route.

The word may matters. “Managed” has no single scope that you can safely infer from the label. A provider's own documentation can describe managed hosting as including server and application administration, while another offer called managed may stop at the operating system. Even support hours, restore work and certificate management can differ by plan.

Before buying, require a written list of included components, excluded components, support conditions and customer duties. If a task matters to your client relationship, do not rely on a sales-page adjective.

What managed website care adds

Website or application care sits above the server platform. For a WordPress site, it can involve:

• updating WordPress core, plugins and themes;
• checking compatibility before and after changes;
• testing forms, checkout, login and integrations;
• diagnosing plugin, theme and custom-code faults;
• maintaining application-specific caching and scheduled tasks;
• validating content and business configuration;
• coordinating changes with the website owner.

WordPress's own documentation tells site operators to keep plugins and themes updated and to maintain a current backup before updating. It also notes that automatic updates can fail or be disabled by the server, hosting provider or another plugin. That is a useful example of the boundary: the platform and application affect each other, yet someone still needs to own the application decision and functional test.

A managed VPS does not automatically make the provider your WordPress maintainer. Conversely, a website-care supplier may update WordPress without owning the underlying VPS. If you need both, name both.

Three failure examples

1. The site returns a server error

The provider can check the VPS and components included in its service schedule. It checks the web or database service only if those components are included; otherwise it supplies evidence from its agreed layer and hands the runtime issue to the named owner. The application owner can check logs, recent deployments, plugins and database queries. The incident needs a handover rule: who investigates first, what evidence is exchanged and when the issue transfers or becomes joint work?

2. A plugin update breaks checkout

The server can be healthy while the business function is broken. The application owner normally needs to reproduce the fault, assess compatibility and decide whether to roll back. A platform backup may help recovery, but it does not make the provider responsible for the plugin or for confirming that orders work correctly.

3. The database service will not start

If the database engine is inside the managed platform scope, the provider may own service recovery. The application owner still needs to validate data integrity and application behaviour. “The process is running” and “the website is usable” are two different acceptance checks.

Write a one-page responsibility schedule

For each layer, record:

1. the responsible party;
2. the named components in scope;
3. routine maintenance work;
4. monitoring and alert ownership;
5. incident triage and escalation;
6. change approval;
7. backup and restore responsibilities;
8. the evidence that closes a change or incident;
9. explicit exclusions;
10. the fallback when ownership is unclear.

Use task verbs rather than broad nouns. “Operating-system security updates are applied by the provider” is clearer than “security included”. “The agency tests WordPress, plugins, forms and checkout after a platform change” is clearer than “application support excluded”.

A better buying test

Ask both your provider and your own team to read the schedule, then give them the same scenario:

A client reports that checkout returns an error after last night's maintenance. Who investigates first, what does each party check, and who tells the client what happens next?

If the answers disagree, the service boundary is not ready. Resolve that before onboarding, not during the incident.

Where Novasean currently draws the line

Novasean's current responsibility page distinguishes the Managed OS catalogue from application work retained by your team. It lists scheduled operating-system updates, monitoring set-up, up to one hour of OS administration per month and server backups, with backup and recovery arrangements agreed during onboarding. Application code, content, business decisions, application changes and functional checks remain with your team unless a separate agreement says otherwise. The Managed VPS page says new orders are temporarily paused and exact tasks and applicable terms must be confirmed before a new order. The agency portfolio enquiry has a separate proposed scope; it is not a VPS plan or accepted service commitment.

That is a status statement, not a complete service promise. Use the same discipline with any provider: compare the written responsibility schedule that applies to your exact service, not the product name alone.

Sources

• NCSC: cloud security shared responsibility model — official guidance; responsibilities vary by service and implementation.
• Microsoft: shared responsibility in the cloud — official provider model illustrating how responsibilities change between IaaS, PaaS and SaaS.
• DigitalOcean: what is managed hosting? — a provider-specific description, used as an example rather than a universal definition.
• WordPress: plugin and theme auto-updates — official application documentation illustrating application update and recovery work.
• Novasean: platform and application responsibilities and Managed VPS information — live status inspected on 2 October 2026.

Next: Review Novasean's current responsibility boundary.