According to Eric Mann, WordPress hosting is stale. WordPress hosting has been pretty much the same for the last decade, and your options are fairly limited to one of two possibilities:
- Shared hosting, where your site lives on a server with dozens (if not hundreds) of others.
- Virtual Private Server hosting, where you get a dedicated virtual private server. This has always been the more expensive option.
In addition, large publishers (think news organizations, magazines and the like) have had the option to carry the expense of dedicated servers. These bare metal boxes have been out of reach for most if not all smaller WordPress sites, because of their cost.
The design of WordPress also ensures that it mostly remains stagnant in terms of hosting. Even companies like WP Engine and SiteGround run individual copies of WordPress core on virtual or shared servers.
Meanwhile, technology has marched onward, and there are better ways to manage and run WordPress sites in 2024.
Warning: Technical Discussion Ahead
I’ll be blunt: the discussion we’re about to have is deeply technical and gets into the weeds and specifics of how WordPress works, and how WPConcierge hosts websites.
If you’re not technical, or don’t care about how WordPress operates internally, you may want to skip this post.
But if you are technical, this post will be for you.
Why am I sharing this? Because I believe we can do better, as a community and as a managed WordPress hosting world.
The Design of WordPress
The WordPress content management system consists of a series of pieces, each one playing a role:
- WordPress core – this is all the files that power the CMS at its heart, and in general are not modified by the end user.
- WordPress Content – usually stored in the wp-content directory, this is the part of WordPress modified by users. This contains the media directory (storing images and documents), as well as the plugin directory (storing the site’s plugins) and other stateful content.
- WordPress Database – This is where the bulk of the content is stored for posts, pages and metadata composed of characters (images are not stored in the database).
- A cache – WordPress supports object caching on a per-request basis, and offers extensibility for caching into key-value stores like Redis or Memcached.
- A front-end web server. This acts as the proxy to the PHP backend, serves static files, and takes care of other tasks like terminating TLS connections and composing HTTP responses.
Each of these pieces is vital to the WordPress application, but not all of them need to be run on the same server. In fact, most of them can be run in separate containers, or on separate services, for improved scalability.
The foundations of WPConcierge
We built WPConcierge on Docker containers, running in the cloud. This was an intentional decision, made to streamline the WordPress application. Our goal was to reduce cost and offer a premium service that nobody else does.
We start with a Dockerfile that defines the WordPress image. We create a custom version of the wp-config.php file that uses environment variables to declare credentials and other configuration-specific items. The Docker image is generic and contains just the WordPress core.
These WordPress images could be run by any developer creating a development enviornment. Just run `docker compose up` on a docker-compose.yml file and you have WordPress.
Some may ask why we didn’t elect to go with the official image from Docker Hub. The reason for this is simple: we wanted control over the entire enviornment, start to finish.
Customizing WordPress for each site
Of course, a generic WordPress installation isn’t very useful. In order to effectively manage a client’s WordPress project, we need to customize the container for them.
Our custom wp-config.php file is a start: it offers us the ability to inject variables into WordPress through the environment. But the uniqueness of a WordPress site is contained in two things: the contents of the /wp-content directory, and the database.
For our clients, we use a flexible storage model that attaches a volume directly to the /var/www/wpconcierge.com/wp-content directory. Their content is stored in this virtual volume, and the design is such that we can have as many containers running as we want. This allows us to scale WordPress to meet traffic demands.
Then, we use a set of powerful database servers to provide our customers with quick access to their data.
Finally, we put all the client’s secrets into a secure environment, encrypted with its own key. This protects the client’s database password and other credentials as well as WordPress salts from prying eyes.
After all this we spin up the container and register the container into our target groups for our load balancer. This allows us to distribute our traffic to the running containers equally.
Making WordPress fast(er)
We still need to tune WordPress for optimal performance. For sites that don’t change often (and most don’t), we can leverage a content delivery network (CDN).
Our CDN points to the load balancer, which points to the containers that are running. If our WordPress install is a multi-container application due to traffic needs, we can balance that traffic across endpoints.
We leverage several behaviors on the CDN to differentiate between traffic going to static assets (like the media directory) versus traffic heading for dynamic endpoints (like the REST API and WP CRON). This allows us to optimize the cache for different scenarios.
Most sites that we manage, even if they are reasonably large sites, can be loaded in under one second. This is a fantastic load time for sites that previously took two or more seconds to load. And we’re often faster than even one second!
Making WordPress safe(r)
One of the challenges of running a WordPress website is the attack surface WordPress provides. Between attacks against core, against PHP, and against the MySQL database, there are numerous pitfalls in running WordPress.
We take several tacks when dealing with threats to WordPress.
First and foremost, we us a read-only file system for the core container, meaning the core files can’t be overwritten by malicious actors.
In addition, we patch WordPress the same day that a core update comes out. Since patching the sites is as simple as pushing a new container version containing the update, we’re relatively quick.
We also place a web application firewall (WAF) in front of all our sites that provide bot detection, rate limiting, and other checks to weed out bad actors and malicious attacks.
In the event that one of our sites is breached, we can simpyl spin up a new WordPress container to replace core. And since we take daily backups of all client sites, we can easily restore a site if one gets compromised.
Plus, the isolated nature of each WordPress install prevents the intrusion of one site from affecting the others. Even if the containers reside on the same physical hardware, they’re not in the same network – a fact that makes Dockerizing WordPress an ideal solution.
Deploying WordPress tooling
As an open source project, WordPress offers a lot of tooling that can make the lives of administrators easier. The WP-CLI project is one such tool. And we’re able to deploy it, at scale, for each site that we manage.
We build a separate container for WP-CLI, which contains the core content management system. Then, we define the volume for the client’s content, and we also provide the secrets to the container so it can connect to the database. As far as WP-CLI is concerned, it’s working with a traditionally-hosted WordPress website!
We can run tasks, like backups, through the WP-CLI tools. We can also do things like upgrade the WordPress database, install and upgrade plugins, and more. And, because WP-CLI provides useful information about the state of the site, we can collect data, too.
The best part is that once the WP-CLI container is done running, it exits, which saves resources. And, because it runs in its own container, there’s no performance impact to the site.
How we scale WordPress
The biggest advantage in using container hosting for WordPress is that it can automatically scale.
Based on rules we have defined, which include traffic numbers and CPU usage, we have configured all our sites to scale. As traffic numbers increase and demands on the containers goes up, we detect those changes and provide more resources. When the traffic subsides, we scale down.
The best part of all this is that we do it for no additional cost to our customer – it’s built into the cost of their plan.
WordPress scales horizontally very well. We would rather provide five containers with 2 vCPUs and 2 GB of RAM than one container with 10 vCPUs and 10 GB of RAM. It’s just more effective, plus it’s easier to control the capacity of each site with granularity.
Room for improvement
Of course, we aren’t perfect – we have huge opportunities for additional performance and scaling wins:
- Making use of an object cache that caches data to Redis or MemoryDB;
- Replacing the WPDB object with one capable of reading from one database and writing to another;
- Reducing filesystem I/O and dependence on phyiscal files existing;
- Using S3-compatible storage for media files like images and documents;
- Proxying MySQL-specific requests from WordPress to permit use of alternative databases (like PostgreSQL)
- Automatically minifying and combining Javascript and CSS files to reduce total number of requests made;
Over time, we have a roadmap to address each and every one of these performance opportunities. It’s our goal to be the best and fastest WordPress managed hosting provider the world.
Conclusion
Many WordPress hosting companies still sell hosting the old-fashioned way, focusing on cores, RAM and storage space. Some may offer a CDN, fewer offer a WAF, and almost none offer the scalability and performance of containers.
If you’re ready to move into 2024 with your hosting of WordPress, reach out to us today. We can’t wait to show you what WordPress is capable of!
