When you build a WordPress based SaaS, updating your customer sites is one of the most critical tasks on your plate.
There are a number of reasons that you will need to update sites after they are deployed:
- You want to add new functionality
- Plugins and Themes that you used have critical security-related updates
- It’s best practice to always keep your plugin and themes updated since many updates include security fixes even if they are not explicitly mentioned in the plugin/theme update notes
This article covers updates related to existing plugins and themes on your site. Adding new functionality is a more involved process and we’ll cover that in more detail in a future article.
Updating a SaaS that is based on WordPress Multisite (eg: using WPULTIMO) is simple – you just update your themes and plugins using the normal WordPress update process and all sites are automatically updated.
Of course this has ramifications – if a plugin/theme is a bad update then all your customers are immediately affected. This is the drawback of using Multisite for your SaaS. But, it does make updates super simple.
Individual Sites – Standard Updates
Then, you can update sites in batches. Or, if you’re an optimist, select all sites for updates.
Individual Sites – Custom Updates
Some admins create their own custom update process using a sequence similar to the following:
- Update a master site (which can be the template site(s) or a different site)
- Copy the updated plugin and theme files to each individual site using a custom copy script (single server) and or sFTP logins (sites located on multiple servers)
Creating a custom process can help save on bandwidth as well as customize how fast sites are updated, the order in which the updates occur etc.
Usually only larger businesses with a successful business model will create a custom update process.
As with everything related to multitenancy, updates require a very structured process.
Template sites are first updated and tested. Updates are then committed to the template site(s) GIT repo(s) and a new version created.
The new version is then pushed out to the existing tenants.
Each vendor has their own update tools so how this is done varies. OpenSaaS allows the admin to select servers or site groups for updating or you can update individual tenants.
In OpenSaaS, if tenants reside on multiple servers, version copies are first pushed to each server and then tenants are updated from those copies.
A WP multisite based SaaS is the easiest to update and the easiest on which to make mistakes.
Individual sites provide more update flexibility but require more work and monitoring.
Multitenant configurations require a more structured approach and straddles the line between the risk of Multisite and the effort required for individual sites.
Because the update process is drastically different between each configuration, how they are handled should be part of the decision making process when deciding which architecture you will use for your WordPress based SaaS.
Request a Demo
Want to see OpenSaas.io in action? Request a demo - just pick a time from our calendar.