We're always adding new features and improvements to SpinupWP.
See below for the latest enhancements and email us if there’s a feature you'd
like to see next.
Previously there was a field in the Storage Settings tab labeled “Retention Period (Days)”, requiring you to specify the number of days a backup would be retained before SpinupWP would delete it from your storage provider. You could set it to a high number but there was no way to disable it.
We’ve moved this backup retention setting to the Backup Settings tab and added a toggle so that you can turn it on or off. This is particularly useful for those who wish to manage backup retention using their storage provider’s lifecycle rules.
SpinupWP now supports PHP 8.2. WP CLI has been updated on all customer servers from version 2.6.0 to 2.7.1, introducing PHP 8.2 compatibility.
When creating a new site or updating existing sites to use PHP 8.2, you can now select PHP 8.2 via the SpinupWP dashboard:
From a site’s dashboard, select “Settings” from the left menu.
Select PHP 8.2 from the drop-down menu.
WordPress core 6.1 is compatible with PHP 8.2. That being said, you may run into minor issues so we recommend testing on staging before switching any of your production sites to PHP 8.2.
If you’d prefer not to be charged every month for SpinupWP, you can now purchase between $20 and $1,000 of account credit. This is particularly useful for customers who have difficulty with their credit card company’s rules for recurring payments. To add credit, visit the billing settings screen in your account.
All customers on the Team plan can now start monitoring a site with the flip of a switch:
When the site goes down, team members who have been selected to receive monitoring alerts will receive an email. Slack integration is coming soon. For more details, check out the Site Monitoring doc.
We’ve shipped an update to our API allowing you to provision a server. Only DigitalOcean is supported in this first release, but we plan to offer other providers in the near future. We’ve also updated the PHP SDK with this new endpoint.
Prior to today, access permissions in SpinupWP were painfully basic. Every team member would have access to all of the team’s servers and would be limited by their role: User or Admin. A team member with the User role could manage sites, databases, and their own SSH keys on all of the team’s servers while an Admin had full access to all of the team’s servers.
Today, we’ve renamed the User role to Site Admin, the Admin role to Team Admin, and we’ve introduced a new role: Server Admin. A team member with the Server Admin role is able to update servers, manage sudo users, manage server settings, and restart services like Nginx and MySQL in addition to all the things a Site Admin can do. The capabilities of the Site Admin and Team Admin roles remain the same.
You also now have the ability to limit team member access to specific servers for Site Admin and Server Admin roles.
Check out the Team Roles doc for full details including instructions on how to update your Personal account to a Team account.
When spinning up a new server, you used to have the choice between MySQL and MariaDB. As of today, MariaDB is no longer an option. MariaDB will continue to work on existing servers with SpinupWP.
It’s only been a few months since Ubuntu 22.04 LTS shipped and even less since most server providers started offering it, so we’re very happy to officially support it in SpinupWP as of today. We’ve tested on DigitalOcean, AWS EC2, Vultr, Linode, and Google Cloud. We would have tested AWS Lightsail, but it doesn’t offer a 22.04 LTS option yet.
If you’re looking to upgrade your existing servers from Ubuntu 18.04 LTS or 20.04 LTS to Ubuntu 22.04 LTS, you should definitely check out our recommendations first.
Newly provisioned servers will now use Redis 7.0. Existing servers will not be updated to Redis 7.0 by SpinupWP. If you want to upgrade Redis on an existing server, you will need to do it manually.
SpinupWP has always installed and configured MySQL or MariaDB when spinning up a new server. Starting today, you have the option to provide connection information for an external database server instead.
Choosing this option will skip the installation of MySQL or MariaDB and use that external database server for all your sites on the web server.
When a web server is struggling to handle traffic to a site, most folks reach for the “upgrade server” lever first. Increasing CPU and memory (scaling vertically) is the quickest and easiest thing to do. However, at some point you’ll max out the CPU and memory limits. Then what?
Load balancing is often the next lever folks reach for, but the first step in scaling horizontally is to move MySQL/MariaDB onto a separate database server. Having a separate database server also makes moving sites between servers a lot easier because you don’t have to move the database. This benefit is a good reason to move MySQL/MariaDB to a separate database server well before maxing out CPU and memory limits on a single server.
In fact, we ran deliciousbrains.com (WordPress + WooCommerce) with an external database (DigitalOcean Managed Database – MySQL 8) since August 2020 and it worked great.
We’re also working on two more docs with step-by-step instructions for creating a managed database on DigitalOcean and Amazon Lightsail, and then adding it to SpinupWP as an external database. Stay tuned for those.
A command line interface is one of SpinupWP’s most frequently requested features. The wait is finally over!
Visit the SpinupWP CLI project on GitHub for complete installation and usage instructions. The first step is to require the package globally via Composer:
composer global require spinupwp/spinupwp-cli
Make sure the /vendor/bin directory in your global Composer home directory is in your system’s PATH. This could be ~/.composer/ or ~/.config/composer/, depending on your operating system. You can use the composer config --global home command to check this location.
Once you’ve finished installation, you’ll have access to the spinupwp command:
