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.
The database and uploads are straightforward. The caching behaviour is the part that made the site fast, and it is not inside the install.
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.
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.
SpinupWP runs WP-Cron from system cron. Reverting to the WordPress default at migration is how scheduled posts and backups quietly become unreliable.
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.
SpinupWP automates provisioning on your DigitalOcean or Hetzner account. The automation is excellent and the account, the bill and the responsibility remain yours.
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.
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.
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. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, exemptions and purge rules reproduced, and no cloud account left running.