When to Upgrade to a KVM VPS

Trigger 1: you need root

If installation or operation requires system packages, service configuration or operating-system changes that are outside the managed panel, KVM is the appropriate tier.

Trigger 2: you need persistent system services

Some applications need workers, queues, custom runtimes or daemons that remain running independently of web requests. When the managed service does not explicitly support that process model, move to KVM rather than trying to force it into cron or a web request.

Trigger 3: sustained resource pressure

Use evidence: repeated CPU saturation, memory constraints, process limits or timeouts under legitimate workload after application optimization. The entry shared CPU allowance starts around 5% and varies by plan.

• Separate bot/attack traffic from customer workload.
• Profile database queries before upgrading.
• Cache expensive repeated work where safe.
• If the workload is inherently sustained, size a VPS from measured demand.

Trigger 4: isolation/control requirements

Projects that require their own operating-system configuration, network/service controls or a predictable dedicated virtual resource envelope belong more naturally on KVM.

What is not a trigger

Needing a single application capability is not automatically a VPS trigger. GreatHosts CP can expose NodeJS, Redis, Memcached, Varnish and Supervisor as included capabilities or add-ons that can be ordered when the selected shared plan does not include them. Exhaust that simpler path before accepting the operational burden of a VPS.

• A site being generated by AI is not a VPS trigger.
• Needing NodeJS, Redis, Memcached, Varnish or Supervisor is not by itself a VPS trigger when the capability can be added to the managed plan.
• A temporary traffic spike is not enough evidence by itself.
• Preference for a familiar control panel is a configuration choice, not a resource requirement.

Migration checklist

Treat the move as a controlled change.

• Capture current files, databases, DNS records and application configuration.
• Document PHP/Python/runtime versions and cron jobs.
• Build the KVM environment before changing DNS.
• Test via a temporary hostname/hosts-file method where appropriate.
• Lower DNS TTL ahead of the cutover if you control it.
• Keep the previous environment intact until validation is complete.

After migration

Monitor application errors, response times, CPU, memory, disk and database behavior. Root access means the server now has more ways to be misconfigured; patching and service security become part of the operating model.

Services related to this guide