Managing a WordPress based SaaS System

TL;DR We are building a SaaS for digital signage for the WordPress community. Our platform is based on WordPress of course. There are interesting challenges in the building of a major system, such as a SaaS product, with WordPress as the base. We have implemented our own WordPress Site Management LifeCycle to manage these challenges. Containers and Kubernetes are key support pillars of this architecture.


We are building a SaaS for digital signage for the WordPress community. Our platform is based on WordPress of course. There are interesting challenges in building a WordPress-based enterprise system, such as a SaaS product. This is the first in a series of articles where we will discuss our WordPress architecture and how we handle the challenges.

A WordPress site to support a SaaS may have complexities and custom development not typical of a website. For example, our WP portal provides functions to create digital signage assets, act as an SSO (single sign-on) and authentication provider, and manage real-time events in the digital signage network. With this complexity, site lifecycle management becomes extremely important. This first article discusses the site development lifecycle that we use, and how we use Kubernetes to help us with that management.

If this is of interest to the community, the next article could discuss the use of WordPress as a management portal for business functions. In other articles, we could dive into some of the interesting challenges we have encountered and how we resolved them. Let us know…

The Current Landscape

Many WP professionals and agencies host their sites on public clouds such as AWS, Google, Azure, and Digital Ocean. Our main application resides on the Digital Ocean cloud with other functions in AWS and in Google Cloud.

  • It is easier on the cloud to structure workflows to requirements.
  • You can be more responsive to clients’ needs, given direct access to the infrastructure, such as servers, certificates, DNS, and networking.
  • As a SaaS, you require the flexibility and pricing options that cloud providers provide.

At the same time, there are real challenges in managing a WordPress site, particularly a complex site with business functionality:

  • Particularly thanks to the new WordPress Full Site Editing functions, it is getting easier to make changes to the site using WP tools and features rather than using custom coding. Changes will go directly into the database of that instance. If the site changes are done on the production site, then the production DB contains all the changes.
  • The same goes for user-generated content such as eCommerce transactions, comments, and uploads. Changes between staging and production have to be merged at the point of deployment.
  • However, custom enterprise development might take weeks or months. And the custom work needs to be tested against a proper version of the production instance.
  • There is a need to provide a secure and robust environment to all clients. This includes certificate management, web application firewalls, proper isolation between sites, scalability, and resource allocation.
  • In an enterprise or SaaS environment, there are data security concerns with using clones of production sites for UAT and development. For example, if the production site has PII (Personal Identifiable Information), the data must be scrubbed as part of the process of being cloned, as PII information cannot be leaked into the testing environments.

A WordPress Site Management LifeCycle

A Site Management Lifecycle that supports the above activities is critical to delivering a robust user experience. The following diagram is our lifecycle management workflow to satisfy the above requirements. It includes:

  • Scripted two-way transitions between production and staging.
  • Management of custom development through Git and into staging, (Gitflow for git branch management)
  • Scripted merging of user-generated content and custom work from Git.
  • Consumption of WP and 3rd party updates.

The yellow arrows indicate the usual sources of external input into the lifecycle:

  • The original site as developed by the team.
  • WordPress updates, and updates from 3rd parties
  • User-generated content such as comments, purchase activities, forums, etc.

The activities in blue are the regular maintenance activities. In a sophisticated operation, these may be handled by CI/CD tools such as Jenkins or Argo. These are the activities we will be focusing on in this article.

Docker Containers

To cope with some of these challenges, many WP professionals have moved on to using containers to manage WP instances. Containers offer an easy way to package an instance, run it anywhere, and provide nice isolation between sites. We use containers extensively in our architecture. Our WordPress instances are bundled in containers. Our player agents running on Raspberry Pi’s are bundled in multi-platform containers. This is done for the benefit of our lifecycle pipelines. This is also for easy management by our partners who might deploy our portal in their own cloud or integrate our application into customer applications.

Container deployments need to be managed. There are several options. Docker provides the basic Docker Compose tool and the more advanced Swarm. Most enterprises and Saas operations have moved to a Google tool, Kubernetes, for the management of multi-server container deployments. AWS, Google Cloud, Azure, Digital Ocean all provide Kubernetes clouds. Our containers initially ran on Google GKE and are currently running on Digital Ocean’s K8s cloud (A major benefit of Kubernetes and containers is the portability of application deployments across different provider clouds).

What is Kubernetes?

What is Kubernetes? Kubernetes is an open-source container management platform developed by Google. It came from their experience in managing thousands of servers and applications, but it is a good platform even if you only have a few applications.

Here are some introductory Kubernetes resources.

The job of Kubernetes (K8s) is to take a group of virtual machines (K8s calls them nodes) and expose them to you as if it was a single cluster. Just tell Kubernetes what you want, and it will follow through. For example, normally you would say, “Run client A’s and client B’s website on server X and client C’s website on server Y.” With Kubernetes however, you can say, “Deploy A, B, and C sites”. Kubernetes will find the right node with the right resources for each site, deploy, and keep them all up.

What if your application crashes? No problem, Kubernetes can restart it for you. What if a node crashes? Kubernetes will move your site to another node and restart it. The load balancer will automatically point to the new location. The K8s cert-manager will install and automatically renew (free) SSL certificates for your sites.  All these tools make sure all your applications run smoothly with minimal effort. 

K8s provides best practice management with an easy way to create deployment definitions, all with yaml definition files. Most importantly, K8s offers tools that help to alleviate the challenges of managing a WP site.

For those interested, we have a section at the end of the post on how to get started with Kubernetes.

Our Solution

At Locol Media, we use Kubernetes to streamline our operations. A unique requirement for us is the potential for other professionals, such as marketing agencies, to run our application in their own clouds. This requirement only makes it more important to create a simple-to-maintain application.

Here is the application we support (this article describes the application) :

As you can see, we have the same challenges as everyone else in the need to manage a significant WordPress environment. 

  • The main site is a WordPress Multisite.
  • We have a blog that is edited and published on the production site.
  • We will have eCommerce functions (woocommerce) on the portal.
  • We have a knowledge base subsite that is edited and published on the production site.
  • We have custom plugins containing our SaaS features that are developed and stored in git.
  • We need staging and development sites to verify our custom code before deployment.

As is common for many enterprise projects, our application also integrates with non-WP services and APIs. Kubernetes creates a simple common pattern for this integration, simplifying the management work.

Here is a physical diagram showing how our microservices work within K8s. The wp_portal deployment contains wp_portal-service, the WordPress environment. The locol-cloud deployment contains cloud-services, our NodeJS-based microservices. We have StatefulSets to provide MySQL and Redis persistent storage.

Note that we leverage Kubernetes not just for the central applications, but also for the digital signage devices at the stores. Specifically, k3s on raspberry pi.

A key SaaS requirement is the management of software releases. We continually enhance our product offerings. Releases must be promoted to production with substantial regression testing, minimal downtime, and provisions for rollback. With K8s, we found a simple and elegant approach to “version” the system. We can timestamp the creation of a WP instance. Later, we can draw from the instance, with any user-generated content included, and generate a new versioned instance. We can make changes such as the domain name to create a staging or development instance. We can apply scripts to protect PII information from the staging/dev instances. We can roll back to the previous instance if necessary. This versioning approach became the core of our release management.

This “versioning” approach streamlines much of the WP lifecycle.

  • For a small upgrade, such as a minor plugin upgrade, we can draw from production (or staging, whichever is appropriate), upgrade, and promote as production. We can roll back if necessary.
  • For a major upgrade, we can “check out” a staging version, testing the upgrade extensively, and when we are happy we can promote that to production.
    • To retain the live customer updates, we simply draw from the production site again, apply the updates that have been tested, and promote. Problems? We roll back.
  • Because we can easily draw a version from production, all the WP content tools can be used without conflicting with custom work developed on a staging server.


When we look at the typical workflow for managing a WP environment and typical challenges, we can sort it out into the following scenarios, each with its challenges:

  • Taking an existing WordPress instance and deploying it into Kubernetes.  
  • Restoring an environment to a different domain name, such as a staging environment or from staging to production, handling data security management, etc.
  • Deploy custom changes that have been tested in a staging environment into production, merging front-end generated content such as uploads, transactions, comments, and blog posts – doing this while having versioning and roll-back capabilities.
  • Leveraging K8s to handle ssl certs, high availability, and performance scaling.

When we looked at internet articles on deploying WordPress in Kubernetes, we found the examples mostly show the creation of a new instance of WordPress into a Kubernetes pod. There is little material available to show how to support the above kinds of scenarios. As a result, we had to create our own set of yaml files to perform these functions.

Given our own experiences with Kubernetes, we felt that sharing our experience with other WordPress professionals would benefit the community as a whole. We are planning to open-source our deployment kit, so stay tuned.

How to get started with Containers and Kubernetes

If you are interested in containers and Kubernetes, here are some resources to get to understand Kubernetes. Most of the material below assumes a basic knowledge of docker containers. If you are starting with a need to understand containers, here is an overview:

Here is an excellent article about the relationship of Kubernetes to Docker containers:

This is how the Kubernetes team answers the question “What is Kubernetes?”:

Here are some cloud-based Kubernetes offerings that we have experience with. They are all robust and can be used for a simple cluster or scale to very complex architecture.

At some point, you could bring up a sample cluster and experiment. You have two basic choices.. Use one of the clouds, or bring up a single node cluster on your own computer. Most of the clouds have tutorials on how to deploy K8s applications with their cloud. If you would like a small system on your lab computer, there are many choices. From my experience (disclaimer: YMMV, and we are not associated with any of these services), one of the simplest small distros to install is K3s Even though k3s is a slim version of k8s, it is still a fairly full-featured system. It can also scale up to a small cluster for edge computing. We at Locol use K3s extensively for our digital signage application. Another choice, if your base OS is Ubuntu, microk8s is also from Canonical. Installation via snap seems straightforward.

Here are more choices:

The good news is that basic K8s items: pods, deployments, services, namespaces, configmaps, are generally implemented vanilla by most of the distros. Your usage of these should be generic across the distros. There might be distro specific treatment of storage classes. For networking, most distros support either an nginx ingress or a traefik ingress, though AWS offers their own load balancer as an ingress controller.

Here are pointers to basic K8s items that you will need to get started on this journey.. Enjoy until our next article.

Leave a Reply