What's New✨

We’ve made some tweaks to the site domains UI. It should now be more obvious that changes to the domains are queued in a batch and only applied to the server when you click the Save button. As you add, update, and delete domains, no changes are made to the server until you click the Save button. This allows you to make many changes quickly and process them in one batch, minimizing Nginx reloads and SSL certificate regeneration and downtime.

For more details, check out the Managing Site Domains doc.

We’ve added a new custom server endpoint to the API allowing you to provide the IP address and credentials for a server you’ve already set up with one of the latest two LTS versions of Ubuntu. SpinupWP will connect to the server, provision it, and add it to your SpinupWP account.

We’ve updated the API’s servers endpoint to support the provisioning of servers at Vultr, Akamai/Linode, and Hetzner. Previously you couldn’t provision a server at these providers via the API at all. Only DigitalOcean was supported.

And because it’s not always easy to find server regions and sizes metadata in each provider’s docs, we’ve also added a convenient new server providers endpoint to get the server regions and sizes metadata that we use in our UI.

You can now transfer ownership of an account to another user.

Previously you had to contact support for this. See the Account User Roles doc for more details.

SpinupWP now supports Cloudflare R2 as a backup storage provider.

For details about how to set it up, check out the Cloudflare R2 Storage Provider doc.

You can now configure your backups to be sent to another server via SFTP:

You’ll need to provide all the connection information to the server. You have the option of using password or public key authentication. You can also configure a separate filesystem path for the backups of each site:

For details, check out the SFTP backup storage doc.

Newly deployed servers will now have MySQL 8.4 instead of MySQL 8.0. Existing servers will remain on MySQL 8.0. If you want to upgrade to MySQL 8.4, we recommend deploying a new server and moving your sites over to it. There’s no rush however, as MySQL 8.0 will continue to receive security updates for another year, reaching end-of-life on April 30th, 2026.

SpinupWP now supports Hetzner Object Storage as a backup storage provider.

For details about how to set it up, check out the Hetzner Storage Provider doc.

There have been a few things we’ve wanted to improve with Todos since launching it 18 months ago but other things took priority. For one thing, users restricted to specific servers and sites in an account would still see the todos for all servers and sites. Similarly, if you turned off notifications for a server or site, you would still see it in your todos. Both of these issues have been fixed.

In addition, some customers suggested that after they dealt with some todos, it would be really nice if there was a button to get SpinupWP to check the todos again and refresh the list. I’m happy to report that there’s now a Refresh button on the Todos screen.

You can now enable/disable a site’s cron from your SpinupWP dashboard:

When cron is enabled, you can select the interval, the number of minutes between cron runs for the site. For new sites, the interval is set to 5 minutes by default.

As part of this update, Linux cron schedules are now random for each site so that all crons aren’t scheduled to run at the exact same time, which can cause CPU spikes. We’ve also implemented a lock to prevent the Linux cron from running when the previous cron run is still running. To upgrade the Linux cron of a site with these improvements, simply toggle your cron off and then back on again.

Check out our Managing Site Cron Jobs doc for more details.

SpinupWP now supports Vultr Object Storage as a backup storage provider.

For details about how to set it up, check out the Vultr Storage Provider doc.

When cloning a site, you will now see a checkbox on the Database tab labelled “Run find and replace on the database.” Unchecking this allows you to skip running the find and replace against the database and presents you with WP-CLI commands if you’d like to run them by SSHing into the server.

This option is handy if you have a large database that times out when trying to clone or if you’d rather perform the find and replace with a WordPress plugin instead.

As part of this project, we split out the following steps of the clone process into separate tasks:

1. Copy the files and database
2. Run find and replace against database

If the copy task succeeds but the find and replace task fails, you’ll be notified that only the find and replace failed and you’ll be provided with the WP-CLI commands so you can run them without having to do the copy again.