Setting Up Scalable WordPress Installs On Microsoft Azure

Today, Microsoft announced it was creating what it’s calling “a Scalable CMS solution with WordPress.”

In short, it’s a quick installer that

  • spins up an instance of a standard-tier Azure website,
  • adds a MySQL database (and MySQL DB server, if you don’t already have one),
  • creates an Azure Storage container to hold the wp-content folder (and allows you to create an Azure Storage account if you don’t have one)
  • puts a default WordPress install on that site, and
  • adds a special plugin that communicates with the Azure Storage account.

Much of the code I produce for my day job runs on Azure (both IaaS and Websites), and most of my employers’ websites run on WordPress. (None of those sites are hosted on Azure, however.)

Since a lot of my code does something to a WordPress site, and most of the code I write runs on Azure, you can imagine my joy at having a quick and easy way to spin up and manage WordPress test installs on Azure.

So I went ahead and set up an instance. Here’s a walkthrough, as well as my experience.

Setting Up Scalable WordPress In The New Azure Portal

To get to the quick installer, you need to use the new Azure management portal at The current portal, at, will let you see and manage your site (and storage) once it’s up and running, but doesn’t have access to the quick installer.

The new Microsoft Azure portal. The button for gallery installs in on the lower left-hand side of the screen, highlighted by the red box.
The new Microsoft Azure portal. The button for gallery installs in on the lower left-hand side of the screen, highlighted by the red box.

Click on that button and a new menu, titled “Gallery,” will appear to the right. In that menu, click “Web” and another menu will open to the right.

On the Web menu, click on the blue WordPress logo icon, and a new menu will come up, labeled “Scalable WordPress.”

At the bottom of that menu is a blue Create button; click it, and you’re ready to configure your site.

Unfortunately, Azure Portal has two versions of the WordPress quick installer, and one of them is broken.

To get to the correct installer, under the Gallery menu, click “Web.” Then, click the “Scalable WordPress” icon.

You’ll know if you’re clicking on the correct installer by the color of the WordPress icon. The blue-icon installer is working. The gray-icon installer, which is reached from the Home submenu and labeled simply “WordPress,” is broken.

Configure The Install

Once you’ve clicked the button to create, a new menu comes up, titled “Scalable WordPress.”

If you see the title “Website & MySQL,” you’ve clicked on the broken installer, and won’t be able to complete this install. Go back and start again, making sure you click the installer with the blue WordPress icon.

Configuring things here can be a little tricky, so read through this section slowly, and twice, before creating your choices.

The Scalable WordPress install menu in the Microsoft Azure portal.
The Scalable WordPress install menu in the Microsoft Azure portal.
Resource Group: In Azure, a “resource group” — a.k.a. an “affinity group” — is a way to group together cloud resources.

This grouping makes sure that when your services (website server, database server and storage account) are created, they are put as close together as possible (and thus cost less to operate).

In cloud computing, even when resources are located in the same network center, the way that network center is set up could have the effect of making two services, located on hardware that is physically quite close to each other, act as though they are very, very far apart.

In other words, just because the machine that holds your webserver is across the hall from the machine that holds your database server, and two racks away from the machine that holds your storage files, that doesn’t mean they’re connected in a way that ensures speedy and efficient communication.

In fact, they may be set up in a way that intentionally treats them as though they were on other parts of the planet.

By specifying a resource (affinity) group for our three services, we’re telling Azure, “Hey, these three services are all part of the same solution. So they need to be able to easily and quickly communicate.”

Microsoft, in turn, will ensure that services in the same affinity (resource) group are hosted on hardware that’s set up to require as little network hopping and bandwidth as possible.

So the first thing we want to do is go ahead a pick a name for our resource (affinity) group. I’ll call mine wp-affinity-group.

I’m using “affinity group,” rather than “resource group,” because in the older Azure management portal, they’re called “affinity groups.”


After you’ve named your resource group, you’ll see four configuration sections: website, database, storage and subscription.

Let’s start with subscription first, which is the last choice on the list.

In Windows Azure, it’s possible to have several subscriptions. If you only have one subscription, this will be filled out for you. If you have more than one subscription, you’ll need to choose, from the menu, which subscription you want to have billed for this site.


The Website setup menu for Scalable WordPress in the Microsoft Azure portal.
The Website setup menu for Scalable WordPress in the Microsoft Azure portal.
Next, click on the Website menu, and a new panel will come up, asking for configuration information.

The first thing you’ll be asked to give is the subdomain you want to assign to your site.

Under the URL box, you’ll have three choices: Web hosting plan, Web app settings and data center location.

Under Web hosting plan, you’ll see that plan S1 is chosen by default. S1 is almost certainly good enough for all but the busiest WordPress sites, so leave it at this.

Next, you’ll see that Web app settings is marked as complete. Click on it, and you’ll see that it wants the name of the storage container you’ll use to hold your WordPress files; this is defaulted to wp-content.

You might assume from this that as a result, you can configure your WordPress install to rename wp-content (which is often recommended as a security measure), and then simply change the name of your Azure Storage container in this box to get the same result.

However, that’s not correct. Because Scalable WordPress is cloud-based, the files that are being put into Azure Storage don’t really work like they do on a standard Web server. So what you name the Azure Storage container that holds your files has no effect on the security of your site.

That’s because the physical structure of your WordPress site on Windows Azure isn’t the same as it is on a traditional Web host. It looks to you as though it’s the same, but Azure treats your install as three, distinct parts: The engine that renders the content; the database that holds the content and settings; and the files that you’ve uploaded / are part of your theme.

Thus, what your Azure Storage container is named is meaningless; you can name it anything, and it has no net effect on security. It’s simply convenient to call it wp-content.

The Location option lets you pick the datacenter you want to use.

Wisdom dictates you should choose whatever datacenter is closest to the majority of your visitors. For example, most of this blog’s traffic comes from the United States, with India a close second, followed by Western Europe. Therefore, I would probably want to choose US East 2 (in Virginia) if I were to host this blog on Azure.

However, it’s worth noting that certain datacenters are wildly less expensive to host from, and US East 2 is one of the most expensive. If cost is a concern, you may want to consider a less expensive region to host from.


We can now set up our MySQL database. Click on that menu option.

This is the Scalable WordPress database setup screen for Microsoft Azure.
This is the Scalable WordPress database setup screen for Microsoft Azure.

Chances are, unlike me, you haven’t set up a MySQL database in Microsoft Azure previously; but even if you have, it’s a best practice to create a new MySQL database for each WordPress install. So go ahead and click New MySQL database.

You’ll need to give your database a name, of course, but a user name and password will be provided by Azure.

You’ll also be asked for a level of service. Saturn should more than do it, again, for all but the busiest WordPress sites, so choose that level.

Choose the same region as you selected for your Web server.

Under Terms, you’ll be asked to confirm acceptance for the terms of service and privacy policy of Microsoft’s MySQL vendor.


We can now go ahead and set up the Azure Storage account that will hold our WordPress files. (We touched on this briefly while setting up the webserver.)

Click on Storage.

The Scalable WordPress Storage setup menu in the Microsoft Azure portal.
The Scalable WordPress Storage setup menu in the Microsoft Azure portal.

If you already have an Azure Storage account set up, you can choose to use one of those if you like.

I’m going to assume you’re brand-new to Azure, however, so click on Create a Storage Account.

When you name your Storage account, keep in mind that that name is a URL subdomain used to reach the contents of your container, and thus is publicly exposed to anyone viewing your site. So keep it clean and URL-friendly.

Under the Pricing Tier menu, you’ll be asked to choose which kind of redundancy you want for your files. The default keeps 3 backup copies of your files in the same datacenter you’re in, plus 3 backup copies someplace else on the globe. This is pretty good file redundancy and should suffice for just about everyone.

The locally redundant option should suffice to protect your files in all but a complete meltdown of your datacenter; the read-access backup option isn’t any better than the geo-redundant option, when it comes to brass tacks.

Under Diagnostics, I would simply leave that off.

Theoretically your can store in Azure Storage logs about how your Azure-based site is performing.

This is pretty much meaningless, however, since you’re paying for, and are probably going to get, 99.99 percent uptime; Azure configures everything for you automatically; and you couldn’t fix anything that diagnostics would report to you, anyway. You don’t need diagnostics to tell you if you need to increase your server’s memory or CPU. You can see that right from the Azure Portal metrics.

Complete The Install

Once you’ve configured all four sections of the Scalable WordPress menu, you should see that the Create button has turned blue. Just check it and your site will be spun up.

The “Add to Statboard” checkbox will add a Windows 8-like tile for managing your Scalable WordPress site to the Azure Portal home page.

I strongly recommend leaving this checked, so you can quickly get to its management pane.

If you checked the “Add to Statboard” checkbox when you created your site, you’ll see a tile show up onto your Azure Portal homepage, chugging away as it’s created.

This will take a few minutes to complete. (I made two Scalable WordPress sites today; one took about 5 minutes to set up, the one I was making for this post, about three minutes.)

Once the site is created, the icon will change to a white tile, titled with the subdomain you chose for the site, and a globe icon that says “running.”

Click that tile and you’ll see a dashboard come up with metrics panels. (Of course, your site was just made, so there will be no metrics to show.)

Click the Browse button at the top of that dashboard and you’ll be taken to your Scalable WordPress site.

From there, you’ll need to complete your WordPress install, just as you would any other fresh, standalone WordPress install, by giving your site a title and an admin user.

Update WordPress

Log in to the WordPress Dashboard for your site. You’ll see that you’ve got a basic, default WordPress install:

  • Themes installed: Twenty Twelve, Twenty Thirteen, Twenty Fourteen.
  • Plugins installed: Hello Dolly, Akismet, Jetpack, and Windows Azure Storage for WordPress, which is unique to Azure hosted WordPress, and also required for Scalable WordPress to run.

You’ll also notice that right out of the box, you’ve got 5 updates to perform, including the WordPress core.

There’s no point behind waiting, so go ahead and do these updates, starting with the core.

It is going to take an absurdly long time for the core to update. It took almost four minutes the first time I did an update, and three minutes the second time.

By comparison, when I updated this blog’s core to 4.0, it took my basic-plan, shared DreamHost account about 20 seconds to perform the job. I pay $9 per month to host this blog, about one-tenth of Microsoft Azure’s minimum monthly charge.

After you do the WordPress 4.0 update, you’ll need to log back in to the dashboard and update Akismet, plus the Twenty Twelve, Twenty Thirteen and Twenty Fourteen themes. This process won’t take as long as the core update, but it will take longer than it should, given the price you’re paying for the compute cycles needed.

Initial Impressions: Not Favorable

As previously noted, I set up two Scalable WordPress sites today: One about six hours prior to authoring this blog post, and the other as I was writing this post.

I did notice a marked improvement in speed and performance, after a couple hours, in the site made earlier today.

It wouldn’t surprise me if the process of getting the affinity group to really hum takes some time, which is the cause of the slow updating (which requires communication between website, storage and database). I did perform these tasks within a couple of minutes of the webserver coming online.

So it may be that the entire process of configuring the most efficient routes for my site took a while to complete.

Once the site is up and running, it looks and feels — from the perspective of the Dashboard and visitor experience — exactly like any other WordPress install.

However, it’s my basic impression that there are far less expensive solutions out there for WordPress hosting, including cloud-based hosting, that perform just as well.

In fact, it appears to me that simply using a decent CDN and a Web hosting plan that supports memory caching will probably perform as well, if not better, than Azure does, for about half the price.

And for what that’s worth, if you’re hell-bent on using Azure in some capacity for your WordPress site, my initial impression is that is makes far more sense to use Azure Storage as a CDN, and to host WordPress on some other loud platform, which is both LAMP-based and probably cheaper.

Don’t get me wrong: I really like Windows Azure, especially its IaaS. And the pricing is pretty much right for Storage.

I’m also a big fan of Websites for running standalone PHP and ASP.NET websites, which runs rock-solid and is incredibly flexible.

But for WordPress hosting, Azure hasn’t got things quite right yet; seemingly not infrastructure, definitely not price.

All links in this post on delicious:

1 Comment

  1. I just want to say that I like your posting. In fact I am using your site regularly. Your articles are very effective and i am very thankful to you for sharing this site with knowledgeable content .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!