Managed OS, managed runtime and application support are different services

Two providers can both sell “managed hosting” and take responsibility for very different work. One might patch the operating system. Another might also manage the web server and database. A third may maintain WordPress itself.

None of those definitions is automatically wrong. The problem starts when the buyer and provider attach different meanings to the same word.

Use three layers to make the difference visible: managed OS, managed runtime and application support.

1. Managed operating system

The operating system is the software layer that controls the virtual machine and runs system services. A managed-OS service may include agreed tasks such as:

• maintaining a supported Linux distribution;
• applying security updates;
• managing baseline user and service configuration;
• maintaining package repositories;
• checking disk, memory and system-service health;
• investigating faults within the guest operating system;
• coordinating reboots or major-version changes.

It does not automatically include every piece of software installed on that system. Ask which packages and configurations are part of the managed baseline, who may install additional software and what happens when a customer change conflicts with that baseline.

An infrastructure service normally leaves more work with the customer than a platform service. Microsoft's shared-responsibility matrix, for example, shows customers managing operating systems and applications in IaaS, while the provider manages more of the operating-system and runtime layer in PaaS. That is an illustrative cloud model, not a definition of your hosting contract, but it demonstrates why the service layer matters.

2. Managed runtime

The runtime sits between the operating system and the application. For a PHP website, it can include the web server, PHP-FPM, selected PHP extensions, the database engine, process settings and certificate handling. For another application it might include Node.js, Java, Python, a container runtime or a managed database.

A managed-runtime service may include:

• supported versions and lifecycle planning;
• installation and baseline configuration;
• security and maintenance updates;
• service monitoring and restart;
• agreed performance settings;
• certificate renewal for named sites;
• fault investigation within those components.

The important word is named. “PHP supported” does not tell you which versions, extensions or settings are available. “Database managed” does not tell you whether the provider repairs queries, changes schemas or tunes application-specific indexes.

Ask where runtime management ends. If your agency changes a configuration file, does the provider still support it? Are custom modules allowed? Who tests compatibility before a major-version upgrade? Which logs and metrics are available to the application owner?

3. Application support

The application is the code and configuration that delivers the business function. For WordPress, it includes core, plugins, themes, custom code, content and integrations. For a bespoke service, it includes the deployed code, dependencies, data model and connections to other systems.

Application support can include:

• updating application components;
• compatibility testing;
• troubleshooting code and dependency faults;
• functional testing of forms, checkout, login and integrations;
• deployment and rollback;
• performance analysis inside the application;
• content or business-configuration assistance.

WordPress documentation recommends keeping core, plugins and themes current, making a backup before a core update and having a rollback route before enabling plugin or theme auto-updates. It notes that server, installation or plugin conditions can prevent automatic updates. Our recommendation is that the application owner also checks important site functions after a change. This is exactly where boundaries blur: a platform condition can affect an application task, but that does not assign ownership by itself.

If you expect your hosting provider to diagnose a plugin conflict or verify checkout after an update, application support must be explicit.

A fourth layer: business ownership

Technical management does not replace business decisions. Someone still owns:

• which change is acceptable;
• which data may be processed;
• user and client permissions;
• content and product correctness;
• release timing;
• client communication;
• final acceptance after recovery.

For an agency, that owner is often the agency or end client. A provider can report that a database process is healthy; it cannot infer that the recovered orders, prices or customer records are correct without application and business validation.

Compare services with a task matrix

Replace broad feature labels with concrete tasks:

“Usually” and “often” are prompts, not promises. Replace every cell with the answer from the service you are actually buying.

What to put in the service schedule

For each managed layer, record:

1. named components and supported versions;
2. included maintenance and incident tasks;
3. monitoring and alert response;
4. change and approval rules;
5. customer access and permitted customisation;
6. backup and recovery boundaries;
7. evidence and acceptance checks;
8. support hours and escalation;
9. explicit exclusions;
10. the price or charging basis that applies.

This schedule should also say what happens when the provider believes the fault is in the application, and when the agency believes it is in the platform. A joint diagnostic step is better than an ownership gap.

Choose the layer that removes real work

A managed service is valuable when it takes responsibility for work your team would otherwise need to perform or coordinate. Start with recent examples:

• Which operating-system or runtime tasks interrupted delivery work?
• Which application tasks still require your own expertise?
• Which incidents moved slowly because ownership was unclear?
• Which changes need provider access and which need client approval?

Then buy the narrowest service that reliably removes the right work. More management is not automatically better if it removes control your team needs. Less management is not automatically cheaper if your team must absorb recurring platform work.

Novasean's current status

Novasean's live Managed VPS page lists VM Start, VM Grow and VM Scale with the Managed OS option included in the displayed catalogue amounts. That option lists scheduled operating-system updates, monitoring set-up, up to one hour of OS administration per month and server backups; the backup schedule, retention and recovery arrangements are agreed during onboarding. New VPS orders are temporarily paused, and exact tasks, terms and availability must be confirmed before any new order. The current responsibility page leaves application code, content, changes and functional checks with the customer's team unless separately agreed. It does not present managed runtime or application support as part of the current Managed OS catalogue.

That public status is appropriately narrower than a complete managed-service claim. Any future order should be assessed against its exact schedule and effective agreement.

Sources

• NCSC: cloud security shared responsibility model — official guidance on service-dependent responsibility allocation.
• Microsoft: shared responsibility in the cloud — illustrative provider model for IaaS, PaaS and SaaS layers.
• WordPress: updating WordPress and plugin/theme auto-updates — official application-maintenance guidance.
• Novasean: Managed VPS information and responsibilities — live status inspected on 2 October 2026.

Next: Compare platform and application responsibilities.