How to setup WordPress with a local database on Azure App Service on Linux

Azure App Service on Windows is perfectly happy to setup a WordPress site with MySql in-app. It even used to work the same for Linux, unfortunately that functionality was temporarily removed around March 2017 (

Considering the price of £57/month for the most basic Azure MySql database, I decided to try and use MySql in-app with WordPress on Linux.

Warning: This might not work for you, there must have been a reason this functionality was disabled in the first place!

To start with I found the docker images which used to be used. The source for which is available at and the images

I then created a new Web App for Containers and configured the container to point at appsvc/apps:wordpress-0.3.

I then added the following Application settings:

  • DATABASE_HOST = localhost
  • DATABASE_NAME = wordpress
  • DATABASE_USERNAME = [[Database Username]]
  • DATABASE_PASSWORD = [[Database Password]]
  • PHPMYADMIN_USERNAME = [[PhpMyAdmin Username]]
  • PHPMYADMIN_PASSWORD = [[PhpMyAdmin Password]]

After restarting the App Service, you should then be able to visit the site where you should see “Installing WordPress…” text. After a few minutes, once it’s all setup, you should then see the familiar WordPress installation guide.

But what about HTTPS?

So we want our WordPress site to be secure. We can follow the previous post to create and configure the certificate (see here).

We then need to configure WordPress to handle it.

Note: It’s best to do this after finishing the WordPress installation guide, as it overwrites the wp-config.php file.

We’ll start by going to the Kudu SSH terminal (https://[[App Service Name]]

From there we need to install a text editor (as for some very strange reason one isn’t installed by default?!):

Note: You might prefer vim, however I tried it and as it’s an embedded terminal, it didn’t seem to handle the ESC character, rendering you stuck in vim… forever… nightmare!

Now we can edit our wp-config.php file.

You’ll want to make your file look similar to this (namely adding the FORCE_SSL_ADMIN and the following line, and updating the WP_HOME and WP_SITEURL to https):

If you’ve never used nano before then, once you’ve made your changes, press Ctrl + X and type Y to save your changes and exit.

Given you uploaded your certificate, bound it to the domain, and enforced HTTPS only, then after refreshing the site, you should have a fully working and secure WordPress site!

I haven’t dabbled with the backups yet, but plan to in the near future.




How to setup SSL Certificates for Azure App Service Web App on Linux

I have an Azure App Service which hosts a few web apps (all on Linux as you cannot have both Windows and Linux apps on the same App Service Plan, and to be honest the Linux ones just seemed more responsive than the Windows ones).

Azure has yet to embrace the LetsEncrypt movement, so the only options for setting up SSL certificates with your Web App is via Azure App Service Certificates (starting ~£50/year) or manually uploading an otherwise acquired certificate.

There is a helpful guide for setting up LetsEncrypt for Web Apps on Windows ( however this does not work for Web Apps on Linux.

These are the steps I took to configure my sites (massive thanks to for doing most of the ground work!).

Generating the certificate

To generate the certificates I used the Certbot tool. I chose to run this via docker.

Note: You’ll need to make sure you’ve enabled Shared Drives in Docker for Windows. To do this open Docker Settings and click Shared Drives. Tick the drive you want to share and click Apply.

Another Note: I tried the DNS challenge however with 123-reg at least, the TTL for the TXT record was 4 hours, and if you rerun the certbot it will give you new validation values everytime, meaning if you screw up you won’t get another chance for around 4 hours!

Follow the interactive steps:

  1. If this is the first time you’ve run it then you will need to enter your email address.
  2. Then follow the link to read the terms and conditions, then enter A to agree
  3. Decide whether you would like to share your email with the EFF
  4. Enter the domain name(s) you would like to generate a certificate for, note this does not support wildcards certificates
  5. Then agree to having your IP address logged (if you don’t you cannot generate the certificate so make sure you are using an IP address you are happy sharing?)
  6. Follow the instructions to validate you own the domain
    1. We picked the http option earlier which means we need to generate a file on the server
    2. To do this go the Kudu page and find the SSH page (will typically look like https://[[Web App Name]]
    3. You’ll want to
    4. Then
    5. Then
    6. Then

Certbot will then spit out a bunch of files in your mounted folder.

Unfortunately these files aren’t quite usable. We’ll need to extract a certificate from them. For that we’ll need to install openssl locally. Navigate to and download the latest version (Win64 OpenSSL v1.1.0h was the one I used). I chose to install the binaries to the OpenSSL bin directory, and then added that directory to my path environment variable (for Windows 10, type environment variables into Start and add a new row to the Path variable).

Once installed we’ll need to run the following (I used the archive version as the live folder didn’t work for me, and it simply linked to the archive folder anyway)

You will be prompted for an export password, which is important to remember as we’ll need it when we upload the certificate to Azure (use something memorable e.g. iHATEcertificates69!)

Using the certificate

Once we have our certificate we can navigate to the SSL certificates page on our Web App in Azure. Choose Upload Certificate, choose the [[Domain Name]].pfx file and enter the export password you chose earlier.

Then we simply click Add binding under the SSL bindings area on the same page and associate the certificate with the custom domain name we have already added.

One final thing that is probably worth doing is going to the Custom domains tab and enabling HTTPS Only, this essentially forces all HTTP traffic to use HTTPS.

Whats next?

LetsEncrypt only gives you certificates that are valid for 3 months. That means we’ll need to do the same steps in 3 months, which is a bit tedious.

I plan on building a tool to help with this (similar to the LetsEncrypt Windows App Service tool), so watch this space!