If you’ve read my previous tutorial on configuring SWAG using Cloudflare and a custom domain and are looking for a similar solution that doesn’t require paying for a custom domain, there are several free dynamic DNS providers you can leverage instead. In this tutorial, I’ll walk you through using Duck DNS, one of the self-hosted community’s favorite free alternatives, to accomplish the same task.
Before we begin, if you’ve stumbled upon this tutorial and aren’t sure what a reverse proxy is — it’s a secure way to externally access applications or services installed on a computer or server on a home or internal network. Instead of exposing your network to the internet through port forwarding, a reverse proxy will allow you to set up an application behind an internal firewall that can be accessed through a domain or subdomain name rather than an exposed IP address and port.
What We’ll Need
Below is a list of the free services and applications I’ll be referencing in this guide. By default, the guide is catered towards Linux-based systems and I’ll assume you already have Unraid or docker-compose installed and the basics configured.
- A free Duck DNS account (sign in using one of the account options provided)
- An application you’d like to access externally
- Access to the Community Applications plug-in if you’re using Unraid
- Access to your router’s settings
Setting up DuckDNS.org
The first thing we’ll need to do is create the subdomains we’ll leverage to access our applications externally. Navigate to DuckDNS.org and sign in using one of the account options given to you.
Logging in will bring you to a page with some key pieces of information we’ll need throughout the guide, with the most pertinent being the token in the header section. Note where this is, because we’ll need it later in the tutorial. The token is also specific to your account and should not be shared, which is why I’ve obfuscated mine in the screenshot below.
In the body of the Duck DNS page you’ll find a section titled “Domains”. This is where we’ll configure the subdomains that we’ll use to create our reverse proxy links.
There are a few things to note about Duck DNS before we move forward:
- Duck DNS is a free service, and since you aren’t purchasing your own custom domain, all of your subdomains will end in “.duckdns.org”.
- The free account type only provides five free subdomains. If you need more, log in using one of the other account options for an additional five.
- Duck DNS is a popular service, which means a lot of the common subdomains have already been taken. You may have to get creative to find a subdomain that works for you.
For my subdomain, I’ve chose my own name and let Duck DNS automatically populate my current public IP address in the “current ip” field. (The “ipv6” field can be left blank.)
That’s all we’ll need to do within DuckDNS.org for the time being.
Now that Duck DNS has been configured correctly, navigate to the Community Applications plug-in in Unraid and install the Docker container “SWAG”, or keep reading for a docker-compose example for non-Unraid users.
Below are the relevant fields/environment variables we’ll need to consider before we can install SWAG (everything else is optional and can be left blank):
- HTTP Port: Defaults to ‘80’. If you’re using Unraid, the system already uses port 80, so we’ll need to assign a different port for the time being. I’ve used ‘280’ instead.
- HTTPS Port: Defaults to ‘443’. If you’re using Unraid, the system already uses port 443, so we’ll need to assign a different port for the time being. I’ve used ‘2443’ instead.
- Email: The e-mail address that will be registered for the Let’s Encrypt certificates and notified of expiration dates, etc.
- Domain Name / URL: Enter one of your Duck DNS subdomains here (it doesn’t matter which).
- Subdomains: If you have multiple subdomains you’d like to register, enter ‘wildcard’ into this field, which will accommodate any current and/or future Duck DNS subdomains on your account (without requiring you to update this configuration). Otherwise, leave it blank.
- Validation: Enter ‘duckdns’
- DuckDNS Token: Copy and paste the Duck DNS token from your account page
- Appdata Config Path (or ‘config’ volume to mount if using docker-compose): Enter the path you’d like SWAG to save its configuration files to.
Leave everything else as-is for the time being and click “Apply” to install if you’re using Unraid.
If you’re using docker-compose, see below for an example from the LSIO team of a properly-configured YML file and then use ‘docker-compose up swag -d’ to build the container once you’ve entered your own configuration settings:
Forwarding HTTP/HTTPS to SWAG in Your Router’s Settings
SWAG should now be installed and listening for external web requests on the ports you specified in your container configuration. Next, we’ll need to update our router’s settings to forward all HTTP/HTTPS traffic to these ports on our server.
The tricky part about this step is that every router’s configuration tools look different, so I can’t provide exact steps on how to do this. The concept is the same regardless of your router — you’ll want to log into your router’s settings and find the port forwarding section. From there, forward HTTP and HTTPS traffic to the custom ports assigned during installation.
For this guide, I’m using the Verizon Fios router I have installed at my house as an example. Here’s what the configuration looks like after updating the port forwarding settings:
My router is now configured to route any incoming HTTP traffic from port 80 to port 280 on my server (which has an internal IP address of 192.168.121.161), and then the same for HTTPS traffic (port 443 to port 2443).
If you’re not on Unraid and were able to utilize ports 80 and 443, forward to those ports on your server instead.
On the server (192.168.121.161), SWAG is listening for traffic on those same ports and after completing the next section, will redirect it to the application being requested.
Save and exit your router’s settings.
Configuring Subdomains in SWAG
The process to configure subdomains and subfolders from here on out is fairly straightforward, even without a simple web interface like the one provided by NGINX Proxy Manager.
To begin, navigate to the config folder you mapped during setup (should be in AppData for Unraid users). From there, open ‘nginx’ and then ‘proxy-confs’.
In this folder, we’ll find sample configurations for most of the common applications that the LinuxServer team believes users typically set up:
To configure a subdomain for a given application, find its sample file (note the SAMPLE file extension), open it in a text editor (I typically use Notepad++), and then save the file as application.conf, removing the ‘.sample’ file extension:
If you’re having trouble with the extension not saving correctly, open a blank document, copy and paste the text from the sample configuration file, and then save the file in the ‘proxy-confs’ folder with the ‘.conf’ file extension.
Inside the file you just saved, you’ll need to update the subdomain reference on the ‘server_name’ line to the name of the Duck DNS subdomain you’d like to point towards that application.
In the example below, I’ve updated the subdomain for FreshRSS to the Duck DNS subdomain of my own name that I had configured above:
Another important setting to monitor within the configuration files is the name of the application being referenced, which may not always match the name of the application running on your server.
The best example of this type of scenario is Bitwarden’s password manager, which is commonly utilized through a fork now called VaultWarden. If you’ve installed VaultWarden and try to set up a reverse proxy using the Bitwarden .conf file, you’ll need to replace every instance of ‘bitwarden’ when referenced next to the text ‘$upstream_app’.
Otherwise, SWAG will look for a container called ‘bitwarden’ when it tries to forward traffic to the appropriate application and return an error.
Leave the ports as-is by default, which are usually correctly configured for the various applications found in the ‘proxy-confs’ folder. (Note that they should typically match the internal ports used by the application — not the ports you might have exposed during installation, unless SWAG is on a separate network.)
Final Steps and Review
Once you’ve saved your application SAMPLE files as .conf files and have updated application subdomain and application names as necessary, you’ll need to restart the SWAG container for them to take effect (you’ll need to do this any time you make a change to SWAG’s settings).
If you followed the steps above correctly, your reverse proxy should now work correctly by navigating to the your Duck DNS subdomain.
If you’d like to add subdomains in the future, the steps are as follows:
- Add a new subdomain at DuckDNS.org
- Find the application’s SAMPLE .conf file and save it as a .conf file (updating the subdomain/application name as needed)
- Restart SWAG
What if SWAG doesn’t have a sample file for my application?
You’ll eventually notice the SWAG container doesn’t come with a .conf file for every application. To combat this, they’ve included template subdomain/subfolder files that you can use to begin building a .conf file for the desired application:
In most instances you can just update the container name (next to $upstream_app), ports, and subdomain references, and everything should work out okay, but it isn’t always that simple.
What I usually do is a quick Google search for “<name of application> NGINX configuration” and search the results for someone who might have already asked the question and received the proper configuration text.
Additionally, most applications typically include various proxy configuration files for different web servers (NGINX, Traefik, Caddy, etc.) in their documentation, so that’s another place to look (SWAG utilizes NGINX).
SWAG’s capabilities extend far beyond what has been covered in this guide, but it’s a great place to start in terms of creating your initial proxies to begin accessing your applications externally and securely.
If you’ve followed this guide, please ensure you’ve secured all applications with some sort of authorization (enable username/password to log in, etc.) and then stay tuned for future guides on securing SWAG and your proxies even further.
Have any questions or comments about the content in this guide? Feel free to reach out to the author on reddit with any feedback or for additional help concerning these topics.