Quick Background:

We have a single WordPress instance, with Multisite enabled, hosting three separate blogs. (blog.example.com/blog1, blog.example.com/blog2, blog.example.com/blog3).

This multisite will be load balanced across a web tier of four servers, all accessing the same DB. I understand that blogs.dir will need to be synced across the web tier, so that media is present, no matter which server a client hits.


Can I have a fifth web server (i.e., post.example.com), whose only purpose is to enable editors to login and post new content, for any of the three blogs? This way the load balanced servers are only receivers of uploaded content from post.example.com.

I know the syncing part is possible, but I'm not sure about how to set up WordPress to be accessible from two different sub-domains. Is that possible?

Edit: I should add that an additional goal by setting it up this way, is we hope to gain some security through obscurity, by blocking access to /wp-admin/ on the web tier, so you can only login from the one web server (post), but of course that all depends on the aforementioned question. :)

Mock below:

Mock WordPress Architecture

  • 2
    I'll give this some thought to see if I can come up with an answer to your question as posed. One thing that pops to mind, which would be serious security through obscurity, would be to use a hosts override to point blog.example.com to the "post" server. If you didn't want all your authors to have to edit their hosts file, you could setup a VPN server (something basic, like a pptp server) and have your users connect and route all traffic through VPN. This way, when on VPN, blog.example.com goes one place, and off VPN it goes another place. Commented Oct 3, 2012 at 13:02
  • @MatthewBoynes Thanks for your response! Unfortunately, I'm not able to enforce hosts file updates and/or VPN use. Our editors are local and remote, and are always using different devices.
    – Kai
    Commented Oct 3, 2012 at 18:08

1 Answer 1


Yes, this is possible and a number of news and media agencies work with similar approaches in WordPress.

What's your Editorial Process?
The most important step is understanding your editorial process and how much control you need to have of content before it goes live.
- for example, consider these 3 points:
1. Do you need 3rd party approvals for images?
2. Do you or your client have to sign-off copy / images / video / layout before content is published?
3. Do you Editors get to work on different weeks or issues and are planning content to go live weeks in advance...

If you answered Yes to any of these, then a single DB shared between your Pre-Live / Staging server and your Live server is not 'possible'. Why you ask? because a new post has to be published before it can be seen by non-users or 3rd parties who you don't want to give logins too. (BTW ... anything is possible with time, money and skills to customise user roles and access levels).

So back to the WordPress Scalable Solution

DOMAIN A (what your customers & visitors go to ) will need to be pointed to an HTTP Load Balancer.

The Load Balancer will direct the customer traffic to one of several web servers. These slave servers are kept in LSYNC with a MASTER server.

Ideally, there should be 2 separate DB servers (for load balancing read / write requests and scale). You can expect lots of READ traffic from visitors, but you want to make sure that WRITE traffic from new posts, etc doesn't interupt with your READ requests.

DOMAIN A can also be pointed to an HTTPS Load Balancer which is configured to
1. only allow traffic from your Office IP address and 2. FORCE SSL connection for Admin / Login.

This is an easy change to the wp-config.php file.

Here is a diagram of what we built (with some support from Rackspace) Rackspace Scaled WordPress

In the end we got HyperDB setup to manage the multiple DB servers and requests. This was also easy as it's mostly a plugin with a long configuration script.

W3TC W3 Total Cache
We also got HyperDB and W3TC setup .. this took a lot of load of the DB Servers too

The main reason we used W3TC was to off load all the static content to Rackspace. The Content Delivery Network setup in W3TC is also very easy :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.