WordPress hosting for sites moving off SpinupWP.
SpinupWP's page cache lives in Nginx, and the rules that decide when it clears live in a plugin talking to it. Copy the site without them and every page is either stale or uncached.
What actually has to move.
The database and uploads are straightforward. The caching behaviour is the part that made the site fast, and it is not inside the install.
Page cache behaviour reproduced, not re-invented
SpinupWP caches in Nginx and exempts logged-in users, carts and query strings. Those exemptions have to exist here on day one or the site breaks in ways that look random.
Purge rules that fire on the right events
A page cache is only as good as its invalidation. Publishing a post has to clear the archive, the home page and the feed, not only the post's own URL.
Cron that stays off visitor traffic
SpinupWP runs WP-Cron from system cron. Reverting to the WordPress default at migration is how scheduled posts and backups quietly become unreliable.
Object cache, if there was one
SpinupWP offers Redis but does not require it. Whether the site had one changes its query profile enough that assuming either way is a mistake.
Server administration handed back
SpinupWP automates provisioning on your DigitalOcean or Hetzner account. The automation is excellent and the account, the bill and the responsibility remain yours.
Match the caching before switching DNS.
A site that was fast on SpinupWP and slow here almost always has one cause: the exemptions came across and the purge rules did not, or the reverse.
- Cache exemptions inventoried and reproduced
- Purge events mapped to the same triggers
- System cron recreated on our scheduler
- Restore any daily backup from the dashboard
A cached page and the moment it is not.
Both hosts serve a cache hit in single-digit milliseconds. The difference is entirely in how often the cache is right, and what happens on a miss.
What we change moving off SpinupWP
These differ from a standard WordPress site on the same plan, and each follows from a cache that lived in the web server rather than in WordPress.
| Setting | What we do | Why |
|---|---|---|
| Page cache exemptions | Read from the existing Nginx configuration and reproduced explicitly | SpinupWP's exemptions for logged-in users, carts and query strings are in the web server, so a files-and-database migration leaves a site caching pages it must never cache. |
| Purge triggers | Mapped event by event rather than defaulted to purge-everything | Invalidation is what makes a page cache trustworthy, and a migration that falls back to clearing the whole cache on every save gives up most of the hit rate the site had. |
| Cron execution | Kept on a real scheduler, matching the setup already in place | SpinupWP disables WP-Cron in favour of system cron, so restoring the WordPress default during a migration makes scheduled publishing unreliable for the first time. |
| Object cache presence | Established from the old server rather than assumed | Redis is optional on SpinupWP, and whether it was running changes the query profile enough that guessing produces either a regression or wasted memory. |
| Infrastructure account | Closed out on your side after cutover is verified | SpinupWP provisions into your own cloud account, so the servers keep billing you until somebody deliberately turns them off. |
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.
Will my site still be as fast?
What happens to my DigitalOcean or Hetzner servers?
Do I need to keep the SpinupWP plugin?
Will scheduled posts keep working?
Was I using Redis on SpinupWP?
Move off SpinupWP without losing the caching that made it fast.
Free migration, exemptions and purge rules reproduced, and no cloud account left running.