WordPress Cloud Hosting: Shifter Goes Serverless

WordPress Cloud Hosting: A Paradigm Shift in Traditional Hosting

Shifter is a serverless hosting solution for WordPress. It brings serverless technology to one of the most widely used CMS platforms. Here’s how we did it.

It’s not you, WordPress. It’s everything else.

Over the past 10 years, WordPress has become one of the most successful Open Source projects. Today, one in four websites are powered by WordPress, with no signs of slowing down. WordPress has evolved from a blogging platform into a full content management system. Developers are always discovering new, creative ways to extend and leverage the power of WordPress, from mobile applications to serve the highest trafficked media outlets. There’s not much that WordPress can’t do.

Revisiting Traditional Hosting

First, let’s take a step back and think about where serverless architecture fits in the topic of hosting.

WordPress Cloud hosting is difficult. WordPress is built to serve casual bloggers, enterprise applications, and all users between. However, the same reasons that make it great also make it difficult for both users and hosts. 

Despite the progress made since its release, how we host WordPress has not changed. Deploying, scaling, and security are just more comprehensive versions of what we did 10 years ago.

Now, with WordPress cloud hosting infrastructures just a click away, it’s almost our duty to do more. We revisited the basic needs of hosting to both improve it and to think about it in a completely new way.

Static site generators are a growing trend because they excel at scaling and security while keeping it simple. However, these products tend to fall short in terms of the features and ease of use that you might expect from a full-featured CMS. So, how can we get the best of both worlds? How can we get everything you’d expect from WordPress with the power of static site technology?

WordPress cloud hosting: going Serverless

In many ways, we view our path to serverless hosting as a parallel to the community that realizes a need for the WP REST API.

With the API, developers can abstract the CMS from view. Separating these two functions introduces a whole new set of options. You can now use WordPress to power native applications, Javascript web apps, and more.

We realized that WordPress cloud hosting is no different. Why should we limit ourselves to the monolithic architecture that we grew up with? Why bundle everything into one unhappy server that will always be trying to keep up? To move toward the future, we had to abstract WordPress from the server, which meant going on serverless architecture.

The concept of serverless architecture is about building separate services. On AWS, these services are Lambda, API Gateway, DynamoDB, and Cognito. The tasks of these functions were once performed on servers with various middleware. Because AWS can now deliver these services on-demand or à la carte, there is no need for servers.

Serverless Lifecycle: Creating, Generating, Delivering

Create. Generate. Deliver. This is the life cycle that every website follows, including traditionally hosted websites. With Shifter, we break it down using various microservices in each step.

Creating: Docker

WordPress Cloud Hosting is powered by Docker. This container technology offers a complete filesystem to run everything including WordPress itself. It can quickly boot and varnish. Use it when you need it and delete it when you don’t. Shifter takes advantage of this feature by supplying WordPress when you’re editing content and powers it down when you’re not. With Docker, we can run multiple containers on a server and scale up as demand grows. Shared resources and its impact on speed could potentially be a concern, but they aren’t a factor here. The Docker container running WordPress only has to generate the files we need for use later in the process.

Generating: AWS Microservices

Because our goal is to deliver Shifter as a SaaS, we needed to think about cost, maintenance, and human resources. The AWS suite of microservices, such as Lambda and DynamoDB, allow us to build functions as a service. They fire when needed and can run in parallel. This gives us the freedom to scale. Since WordPress is not bound by server resources, it can pass off the heavy lifting. In turn, this reduces latency and computing power and allows each piece to do what it does best. It ultimately processes dynamic PHP content into static HTML files for deployment.

(function loop(){
  var retry_count = 0;
  var process = require('process');
  process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = '0';
  console.log('site_id=' + site_info.id + ', url=' + site_info.url);
  try {
    var req = https.get(site_info.url, function(res) {
      var body = '';
      var status_code = res.statusCode;
      console.log("Got response: %j", status_code);
      if ( status_code == 200 || status_code == 404 ) {
        res.on('data', function(chunk) {
          body += chunk;
        res.on('end', function(res) {
          // replace host name
            parsedUrl.resource + ( parsedUrl.port ? ':' + parsedUrl.port : '' ),
            path.join(wk_folder, 'index.html')
          // S3 sync
            {'folder': wk_folder, 'pathname': pathname, 'statusCode': status_code},
      } else {
        if (retry_count > retry_limit) {
          console.log('https response: %j', res);
          callbackFunc(null, "Request response Error: " + res.statusCode);
        } else {
    req.on('timeout', function() {
      console.log('docker url request timed out');
    req.on('error', function(err) {
      if (retry_count > retry_limit) {
        console.log('Error: %j', err);
        callbackFunc(err, 'Request timed out.');
      } else {
  } catch (err) {
    console.log('Error: %j', err);
    callbackFunc(err, 'Request timed out.');
Code example: Retrieve HTML file from a Docker machine via HTTPS request, and upload that to S3.

Delivering: S3, CloudFront, Global CDN

Next, static files and resources are moved to a global CDN with all of the inherent security, durability, and speed that you expect. CloudFront delivers content by geolocation. It’s also more secure because there is nothing to maintain. Vulnerability plagued by PHP, Apache, etc. are no longer relevant. This also applies to the database. It’s not there, so there is nothing to hack.

Simply put, it’s a super fast worldwide network of pure content.

Challenges of building a SaaS on new technology with a new concept

Our commitment to going serverless has changed everything for us. We now have the opportunity to offer products alongside much larger companies and still be competitive. AWS gives us, a small startup team, the chance to achieve larger goals with fewer resources, funding, and speed while leveraging more from what we have.

We are happy with the progress that we’ve made, and we are pleased with the capabilities that Shifter offers. We are linking serverless with microservices, which means that we are working in a relatively young development model, especially compared to a traditional LAMP. Of course, we’ll face new problems. And, with this development model, we will find a solution. We believe that this is the right path to follow; that it is the future of hosting. We hope that Shifter will be an example of that future and that it will design for these challenges.
Technical issues aside, the biggest challenge that we face is getting people on board with this approach. Since it’s a new concept, it may be less comfortable and more difficult to understand. We’ll try hard to spread this concept through our product, messaging, and communications.


We’ve proven that Kickstarter is more than just a wild concept. Today, we need your help to develop our roadmap and bring more features to Shifter. Enter Kickstarter. We will begin our crowdfunding campaign with the opening day of our WordCamp US this year in Philadelphia. We ask for your support to help realize this product and in return, you’ll receive special offers, awesome rewards, first dibs on cool swag, and more.

Cloud Academy