How do you release changes to your WordPress-based WaaS with confidence? 

If you’re using Managed WP Hosting with single installs, it becomes a tedious process. Are you going to push that one change to 250 different sites, one by one? 

If you’re using Multisite, you’re still pushing to that one single installation that hosts all your customers. If your release pipeline doesn’t test this one small thing, and you push regardless, you might as well just turn off the production server.

The best solution: have a separate environment to release your changes to. 

This allows you to not only test your changes locally and in your release pipeline, but also in production, without risking outages. 

After you’ve tested your changes and see their effects in the exact environment your tenants work in, you can confidently move your tenants to your newly created environment with the shiny new feature. 


“Wait, what is a tenant?”

Let’s put it this way: WPCS has built a big apartment building – in space obviously, making sure we stay on brand. 

Your ‘WordPress product’ acts as an entire floor. Your prototype is the blueprint of each apartment on that floor. Each time you sell a website, this customer becomes a “Tenant” on your floor. 

Each tenant receives a new apartment, based on your prototype. This means that a Tenant is your customer’s WordPress website.


The concepts that make WPCS revolutionary (and provide 100% confident development)

  1. Product: Anyone can create website products using WPCS, no coding required. You can think of your website as a product that your factory produces. 
  2. Version: Your first step on the platform is to create a version. The version is the prototype of the product you develop and sell. You’ll create new versions as you develop your product and create new prototypes.
  3. Snapshot: When you make a snapshot, you’re basically sending over the blueprints of the current state of your version to the factory.

    When you make a tenant (a customer website) this is always based on a snapshot that you have deployed.

    If you deploy a snapshot, all existing tenants will automatically receive the updated functionalities, such as plugins, themes, and the language files. Existing tenants’ settings are not updated when a snapshot is deployed, as the tenants’ databases remain intact throughout their lifecycle.

  4. Tenant: As stated above, a tenant is an actual product, generated for your customer. The tenant is always based on a snapshot. 

That’s it. Those are the 4 must-know concepts. 

Here’s how to use them:


Deploy with confidence in your WordPress-based WaaS

First off, here’s how the WPCS concepts are related:

Tenants are always based on a snapshot, deployed from a version of your product. 

Because WPCS leverages multi-tenancy, minor updates (e.g. new page templates) deployed in your snapshot become available to your existing tenants. The content in the database remains untouched, as you don’t want to erase all the images or copy on the front-end. 

Newly created tenants will automatically have the latest functionalities/templates/pages in their WordPress installation, when you deploy them based on your latest snapshot. 

This flow is best for deploying small changes to your website product. 

However, what’s the best way to create significant changes to your product? 


Zero risk in your WaaS development process 

Let’s say you want to make significant changes to your website product. You, for example, want to enable your customers to sell products via their website, so you decide to make WooCommerce available to your customers. 

This is a large feature that needs to integrate with a lot of other components of your product. The risk of bringing down one or more websites on a few hundred websites is not insignificant. 

How do you safely make these changes available?

First, create a new version in the Console and give it a name, like ‘v2’. In the version’s Snapshot Editor (click the Editor button), add the WooCommerce plugin. After it has been installed successfully, head back to the Console and Deploy the snapshot.

Now, head to a tenant you want to upgrade with WooCommerce. Create a manual backup, and give it a name “woo commerce added”. Then, you’ll find the Move to version button under the Actions dropdown in the upper right corner. 

Click it and select the ‘v2’ version, the one you just now created. After the move is complete, you’ll find that you can activate WooCommerce in the tenant. 

Run a few safety checks to see if the changes didn’t break anything after activation. When no errors occur, make these changes over a subset of your customers. Create backups and test accordingly. 

When the changes won’t affect any of the sample size, you can be confident to execute the changes over all your customers. 


NOTE
If you install WooCommerce in the snapshot, it is not activated in the tenant. This is because the tenant’s database is kept intact throughout its lifecycle.

Why would you create a new version just to add a plugin? Couldn’t you just add the plugin in the Snapshot Editor of ‘v1’ and deploy that snapshot? Yes, you could – for a while. When you’re working with 10, 20 or 1000 websites, you don’t want to make changes to the whole product without safety measures. 

WPCS Versions are that safety measure. You can test out your changes before moving all your tenants over. Found the exception to the rule? That one tenant that has a certain setting that you didn’t anticipate? Simply move it back and fix the problem with confidence.


Thesis: the perfect setup for WaaS

Are you curious to learn more about how Versions, Snapshots, and confident development using WPCS fits with our thesis on the perfect WaaS setup?

We’ve created a webinar and pdf in which we give a detailed explanation of the core problems, our thesis, and how WPCS creates the perfect setup for scaling WordPress websites using our WordPress multi-tenant cloud platform.

Read our WaaS thesis here.


Continue to discover how WPCS stands out:


Frequently asked questions


When do I deploy a snapshot?

You deploy a snapshot when your current version is ready to serve as a product to sell to new customers. When you deploy a snapshot, you’re sending over the blueprints of your current version to the factory to use when creating tenants (figuratively speaking).

Also, when you deploy a snapshot, all existing tenants automatically receive the updated functionalities. You can keep developing your current version, even while you’re creating tenants based on your snapshot. However, we recommend always creating a new version when you make changes in your product that might alter the website of your tenants. This way you run zero risk is your WordPress development process. 

Being able to create a new version, based on a snapshot of your current version, is an important feature of WPCS: it allows safe development. If you make sure to always develop in a new version and only move tenants from one version to the other after thorough testing, you’re doing it safely!

Once you’ve deployed a snapshot of your first version, you’re in business. You can create as many new tenants based on this snapshot as you please.

When you feel like you’ve created an update to the current version, just deploy a new snapshot. You can use the newly updated snapshot as the new blueprint to create new tenants.


Why do I need different versions?

You create a new version if you want to upgrade your current product in a way that means new functionalities or do maintenance to the product that might cause errors for the existing tenants. 

Maintenance can mean updating plugins, WordPress, or third-party software. It could also mean adding new functionalities like WooCommerce. Anything that substantially alters the product can be safely and efficiently tested by creating a new version. 

Once you’ve finalized your new version, you can test it by moving tenants based on the previous version to the new version. Initall, we recommend doing this with a test tenant. This is how WPCS guarantees the safest and most efficient development process. 


Which themes and plugins can I use?

All of them. You’re only limited by the licensing of specific plugins. 


Can I customize individual tenants?

Absolutely. The WPCS platform is multi-tenant. Meaning, each tenant has it’s complete stand alone WordPress installation. You can modify, optimize, and customize a tenant as you please. 

Keep in mind that altering tenants in such a way that they become removed from your original product might influence the compatibility to a new version. 

Also, you can customize a tenant as you please but your customers cannot. Your customers cannot add plugins themselves. This is to make sure that you keep control of the product and guarantee it doesn’t influence compatibility.


What’s the difference between WPCS and Multisite?

Multisite websites all share the same database. This is convenient when you’re a university or blog platform that wants to share resources. However, it severely limits the scalability, security and availability of your business if you’re using it for WaaS. 

All websites on multisite share the same database, it also limits the use cases. For instance, using multisite for ecommerce is not recommended, as customer data is shared over the entire network. 


What’s the difference between WPCS and Managed WP Hosting?

Managed WP Hosting is a great tool if you want to manage a number of different WordPress websites. It centralizes the hosting and often allows you to manage a number of similar features as one, like plugin updates and backup. It works great if you’re an agency that creates custom websites for different clients and uses WordPress to do so. 

WPCS’ multi-tenant cloud hosting platform is different in the way it standardizes all websites as a single website product, unifies the development process and combines the functionalities of all websites to manage as one. 

The result is a multi-tenant cloud platform, uniquely tailored to facilitate Website as a Service businesses that use WordPress open source.


How is your hosting infrastructure built?

WPCS is a cloud platform that uses Kubernetes’ container orchestration tools to automatically scale and manage highly available digital products to multi-tenancy without ecosystem limitations using AWS cloud services.


What is your approach to backups?

Twice daily, stored for up to a month. You can also create backups of tenants manually, in case you (or your tenant) intends to heavily change their site.


What filesystem access exists?

Right now, the only way to interact with both product versions and the multi-tenancy environments is via the WordPress interface. We are working on providing our customers with FTPS access to their product versions. 

Direct FTPS access for your tenants to their sites is not currently on the roadmap, although we are investigating possibilities.

If you need customizable styling functionalities in your custom (child) theme or custom plugin, we strongly recommend to utilise plugins like simple-custom-css (https://wordpress.org/plugins/simple-custom-css/) instead of using the file system to render out css files. 

Database-based css customization allows for much quicker horizontal scalability, as well as easier cache invalidation during the development process.


What automation or APIs exist for the creation of new tenants?

We have an API that allows for automated tenant creation and deletion, under specific product versions. Read about it here.

Further on the roadmap, we’re looking into providing our customers with incoming and outgoing webhooks to allow for even more customizable integrations.