WordPress hosting for sites moving off RunCloud.
RunCloud is a control panel on a server you rent and own. Moving is less a migration than a change in who is accountable when the kernel needs patching at two in the morning.
What changes when the panel goes away.
RunCloud configured Nginx, PHP-FPM and cron on your VPS. The configuration comes across; the ownership of the machine does not come with it.
Patching stops being your calendar item
A panel tells you an update is available. Somebody still has to apply it, test it and be awake if it goes wrong. Here that is not a task on your side at all.
Nginx rules read before they are dropped
Custom location blocks, rate limits and rewrite rules accumulate in a panel over years. We read them and reproduce the behaviour rather than assuming the defaults were never touched.
System cron replaced deliberately
RunCloud typically runs wp-cron from system cron. That is the right decision, and it needs to be recreated here rather than silently reverting to visitor-triggered cron.
Database tuning that came from your VPS size
Buffer pool and connection limits on a self-managed box are sized to that box. Carried across unexamined they are either wasteful or a bottleneck.
Multiple sites untangled
Panels encourage several sites on one server sharing PHP workers. Separating them is usually the largest single performance change of the move.
Plan the parts a copy cannot bring.
Files and database are the easy half. The half that breaks sites is everything RunCloud was doing outside the WordPress install.
- Nginx customisations inventoried before the move
- System cron jobs recreated
- SSL and DNS cut over with the TTL lowered first
- Restore any daily backup from the dashboard
Three sites that were sharing one pool.
The common RunCloud setup puts several sites on one VPS sharing PHP workers, so the busiest one sets the response time for all of them.
What we change moving off RunCloud
These differ from a standard WordPress site on the same plan, and each follows from where a panel-managed VPS leaves things.
| Setting | What we do | Why |
|---|---|---|
| Nginx customisations | Inventoried from the panel and reproduced explicitly | Location blocks and rewrite rules added to a panel over several years are invisible in a file-and-database copy, and the site behaves differently the moment they are gone. |
| Cron source | Platform scheduler, with WP-Cron left disabled as it already was | A panel-managed server usually runs wp-cron from system cron, so a migration that quietly re-enables visitor-triggered cron makes scheduled work unreliable for the first time in years. |
| Worker allocation | One pool per site instead of one pool shared by all sites | Several sites on one VPS share a PHP-FPM pool, which means the busiest of them determines how slow the quietest one feels. |
| Database sizing | Re-derived from the workload rather than carried from the old VPS | Buffer pool and connection settings on a self-managed box were sized to that box's memory, so importing them either wastes capacity or throttles the site. |
| Operating system responsibility | Transferred entirely rather than notified | A control panel surfaces the update and still leaves a person accountable for applying it, which is the actual cost of self-management people underestimate. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Do I keep my VPS after moving?
Will my custom Nginx rules survive?
I run several sites on one RunCloud server. Is that fine here?
What happens to my cron jobs?
Is this a downgrade in control?
Move off RunCloud and stop maintaining a server.
Free migration, your Nginx behaviour reproduced, and nobody on your side paged for a kernel update.