Using a Reverse Proxy with Ignition 8 on Windows

Includes Auto-Renewing SSL certificates.

In this article I’m going to go through setting up two versions of Ignition behind a reverse proxy. We’ll be using a windows server machine to run the reverse proxy software. There will be two instances of Ignition running on separate servers behind the proxy. One will be straight Ignition 8, the other will be running Ignition Maker Edition. Once you are finished with this, you’ll be able to access both instances from separate domain names via HTTPS. For the purpose of this tutorial I’m going to assume you already have a windows installation setup(this will be the proxy server) and two seperate ignition installs installed on your internal network.

This is the plan!

Set DNS A Records

First of all you need to set the A records with your domains DNS hosting provider to point to your incoming router/firewalls static IP address. For me that is the same static IP that hosts this blog.

Setup Port Forwarding

Now you need to forward ports 80(http) and 443(https) from your static IP to the proxy server internal IP address. You will do this from your router/firewall port forwarding section. There are many write-ups all over the internet on how to do this. I use Ubiquity equipment in my lab so it’s pretty easily done.

Open Windows Firewall Ports

Open the windows firewall and select Inbound rules. Create a new rule for Caddyserver and open TCP ports 80 and 443 and allow from any address and profile.

Install Caddy 2

On your reverse proxy machine, head over to and download the latest release. Here I’ll be using 2.1.1 Windows 64 bit

Extract the archive and you’ll find the caddy server is just a simple single executable file. Create a folder in the root of your C: drive called caddy, and move the caddy executable here.

Create a Caddyfile

Caddy needs a Caddyfile for its configuration. This is just a simple text file with your config setup. The Caddy server has good documentation which explains the caddy file in detail Create a new text document in the caddy folder called Caddyfile . Be careful in windows as it will automatically put the file as a .txt file. You need to remove the .txt file extension or caddy will not recognise the caddy file. I use the command prompt to do this (I’m not a windows guy so maybe there is an easier way, but I couldn’t find it). Copy the following text and paste into your Caddyfile, changing the email address, domain names and internal IP addresses to match your own. I’ve attached my caddy file here so you can check the correct format.

    # email to use on Let's Encrypt
    email [email protected]

    # Uncomment for debug

# Add gzip compression to requests
(webconf) {
  encode gzip

# Add forward headers to requests
(theheaders) {
    header_up X-Forwarded-Ssl on
    header_up Host {host}
    header_up X-Real-IP {remote}
    header_up X-Forwarded-For {remote}
    header_up X-Forwarded-Port {server_port}
    header_up X-Forwarded-Proto {scheme}
    header_up X-Url-Scheme {scheme}
    header_up X-Forwarded-Host {host}
} {
    reverse_proxy {
      import theheaders
    log {
                output file c:/caddy/ignition8.log
    import webconf
    redir /main/StatusPing /StatusPing
} {
    reverse_proxy {
      import theheaders
    log {
                output file c:/caddy/maker.log
    import webconf
    redir /main/StatusPing /StatusPing

Test The Reverse Proxy Server

Now we can run caddy. Open a command prompt and navigate to the caddy folder. Then run the caddy server for the first time.

cd c:\caddy
caddy run

You should get an out put similar to this as caddy negotiates with the lets encrypt certificate issuer:

If caddy won’t start, because it cannot bind to port 80, you may find that the windows web server IIS is running on your server. You can stop the service from the service manager – the service is called World Wide Web Publishing Service. Once the service is stopped retry Caddy. If everything works, go ahead and uninstall the IIS service.

An attempt was made to access a socket in a way forbidden by its access permissions.

Now you should be able to access your ignition installs from your relevant domain names:

Ignition accessed using https via reverse proxy.

Now press CTRL-C in your command prompt to stop the caddy server. We now need to run caddy as a service so it properly works with windows and starts stops on reboots properly.

Install NSSM The Non-Sucking Service Manager

Head over to and download the pre-release 2.2.4 version of NSSM

Unzip and you’ll see the 64 bit folder contains a single executable file. I usually move these single executable non installable files to a folder in the root folder for ease of use. So create a C:\nssm folder and move the 64 bit executable nssm file into it.

Open a command prompt and enter the following:

cd c:\nssm
nssm install caddy

Fill in the dialog box as below:

Check your services and start the caddy service:

That should be it, test your domains and check that it all works. If you have any problems or need help with anything, please let me know in the comments below and I’ll try to help you out.

By Roy Westwood

I've been an Industrial Automation professional for over 20 years. I currently lead a team of Systems Engineers creating OEE and Data Management solutions for customers all over the world.


  1. Roy, I enjoyed your video Using a Reverse Proxy with Ignition 8 on Windows. I have a question about that.

    Why do you want your gateway accessible from the public internet? You would type in the domain name you created and the gateway would come up. Is that not a big hole in security?
    Anyone could access it remotely and if they could get logged in they could do anything they want.

    We use a VPN to get on the same network as our servers running Ignition. So no one can access our gateway remotely unless they’re connected through our VPN.

    I don’t see how you can allow the gateway accessible via the public network. I could not get that passed our higher ups at our company. Is this not a big security flaw?

    1. Hi Jacob, glad you enjoyed the video. This entirely depends on what you are using ignition for. For our use case we are collaborating on development, and this works great for us. Our dev systems are not connected to any control systems and are deleted when we are finished.
      We do however have customers that have internet facing Ignition systems, but these are isolated from control and just for data delivery. It is in these cases that it is essential you are using SSL so all login data is encrypted.

Leave a comment

Your email address will not be published. Required fields are marked *