MODX Revolution is a PHP CMS with tons of functionality out of the box. It also has a lot of flexibility. Like most PHP CMSes, it uses a relational database to store data and puts file uploads on the filesystem.

I recently had the chance to take a MODX system from running on one web server to running on multiple web servers, and wanted to detail how to do that. I did this on AWS and have a strong preference for managed services, so will provide references to those, but you can use whatever specific solution makes sense.

However, first off, consider if you can avoid doing so. Building out a multi server application isn’t rocket science, but can introduce new complexities to your application architecture. If you can get by with vertically scaling your system (faster CPU, more RAM) and/or leveraging HTTP caching and a CDN like AWS Cloudfront or Cloudflare. Here’s a list of caching options with MODX. Think about the expected usage and run some load tests.

If you determine that you want to run MODX in a multi server configuration, either for performance or redundancy, then you need to think about these components: the database, the MODX web application, uploaded files, and the MODX cache.

Let’s start with the easiest one. Scaling a relational database horizontally is difficult and typically requires application changes. Instead, use a different database server. If the database is present on the web server, you need to move it off and have it run on its own machine. I highly suggest using a managed database service like AWS RDS. Configure your MODX application to connect to the remote database server.

The MODX web application can be easily scaled horizontally. You just need to create a number of servers and have a system for distributing the code that underlys your application (you’ll be best served by some kind of automated deployment solution like puppet or capistrano). MODX content is stored in the database, so when each server connects to the same database, if text content changes, all the servers should have access to the change. You will also need to put these servers behind a load balancer like an ELB, or, if you don’t want that additional cost and complexity, configure DNS to round robin between the servers. One nice thing about a load balancer is that you can swap out servers behind it with no downtime for your end users.

Uploaded files need to be distributed between all the hosts. I’ve already covered the options here but you don’t want everyone to upload files to each of the servers. Instead, choose a primary with a different address (primary.example.com) and have the files uploaded there and distributued to all the other servers which will answer to a different address, like www.example.com.

MODX caches many pieces of the application to the filesystem of the web server. This needs to be pushed to a distributed system. If you don’t, the caches will get out of sync with each other (yes, even with the remotes plugin) and you’ll see some very weird behavior. Luckily, it is easy to set up a memcached instance and point the MODX cache system to that server. If you are looking for a hands off memcached cluster, Elasticache was easy to setup and run.

Lastly, don’t forget to make sure that any other custom software processes (whether files uploaded via FTP or data processing jobs) are examined and either isolated to one server or scaled horizontally.

Following these instructions will let your MODX application or website scale horizontally, increase redundancy and allow you to serve far more users than you could without doing so.