What You Still Have to Do on Managed VPS

Every managed VPS has a boundary — a line where the provider's responsibility ends and the user's begins. Most providers draw this line at the OS layer: they patch the kernel, manage the web server stack, monitor for server-level issues. Above that line, the user owns the application, its dependencies, its configuration, its security posture, and its behavior under load. Below the line, the provider handles it. The line is real and worth knowing before something breaks on the wrong side of it.

Application security is user-owned on managed VPS. The provider patches the OS and web server for known vulnerabilities. They don't audit the application code, review plugin configurations, enforce strong credential policies, or monitor for application-layer intrusions. A WordPress installation on a managed VPS with outdated plugins, weak admin passwords, and no web application firewall is not a secure site regardless of how well the OS layer is maintained.

Backup verification is another task that stays with the user, even when the provider runs the backups. Automated backups fail silently more often than most teams assume — disk quota exhaustion, permission errors, backup jobs that complete with errors and report success anyway. A backup that hasn't been tested with a restore isn't a backup; it's a file that looks like a backup. Verifying that restores work, on a schedule, is the user's responsibility whether the backup system is managed or not.

Performance tuning at the application layer is user-owned. The provider may configure PHP-FPM settings and MySQL defaults, but they won't optimize database queries, configure application-level caching, or tune the application's connection pooling for the workload it runs. These have more impact on response time than any infrastructure change, and they require understanding the application — which the provider doesn't have.

Dependency management for application software is user-owned. WordPress plugins, npm packages, Python dependencies, Ruby gems — these aren't managed by the server provider. Security vulnerabilities in application dependencies are the user's responsibility to track and remediate.

The boundary surprise almost always happens during an incident. Something breaks, a support ticket gets opened, and the response is: 'The server is functioning normally. This issue is outside our managed scope.' The user expected the provider to handle it. The scope document said otherwise. Reading the scope document after an incident is the most expensive way to learn what managed VPS covers.

Application-focused managed platforms — Kinsta, WP Engine, Cloudways with stack-level support — manage further into the stack than most managed VPS providers. Application-layer caching, plugin conflict diagnosis, deployment support, and performance consultation are within scope. The boundary is drawn higher. What the user gives up is access to the layers the platform now owns — custom server configurations, non-standard software, OS-level customization. Control and management coverage trade off directly.

Managed VPS sits in the middle: more coverage than unmanaged VPS, less coverage than fully managed application platforms, more configuration access than those platforms provide. The middle position is appropriate when the workload requires some custom infrastructure configuration and the team can handle application-layer operations independently. When either condition is absent, the middle position may be the worst of both worlds — paying for management that doesn't cover what breaks, while retaining configuration access that requires expertise to use.