Forget about Nginx, I switched to this reverse proxy and it's even better

Once you've started self-hosting a few apps on a NAS, one of the next improvements to your home lab is adding a reverse proxy to access your services through one domain name. While many home labbers use Nginx as their reverse proxy solution, it was created as a webserver, and lacks some of the comforts of purpose-built code.

While I've been playing around with multiple reverse proxy solutions lately, including one that I liked, I noticed that it was built on top of another program, Traefik, to handle the reverse proxy under the hood without manual intervention. I thought I'd better check that out because it might be more suited to my needs, and in many ways it is.

It's also a world apart from the Nginx reverse proxy I originally used because of one key feature. Traefik has automatic configuration discovery, which dynamically routes to your services without your help. It's a Docker container, which is even better for simplifying networking in my home lab setup, as it primarily uses containerized services. It's simple to set up and even easier to manage, and it can also be an ingress controller for Kubernetes or Amazon ECS if I want to move my home lab to the cloud.

Traefik makes exposing services in your home lab simple

Putting your reverse proxy in a container makes all your containers easier to manage

Traefik makes running a reverse proxy in your home lab effortless. Well, almost effortless, as you still have to set up the docker-compose file and bring up your other services. The point is that Traefik's automatic service discovery adds any new services to your reverse proxy as it discovers them. It only takes a few seconds after the container is created and is somewhat magical to watch.

There's no manual messing around with route configuration; it just works. And as someone who has frequent happy accidents in the home lab, that's a wondrous thing. Imagine configuration files for the network routing for your home lab that aren't riddled with IP addresses or other routing rules, that you have to update and sync between systems. Plus, it's got all the modern conveniences that you could want, from Let's Encrypt for SSL certificates to support for TCP, HTTP, and UDP traffic, and it has direct integration into monitoring dashboards like Grafana, DataDog, Prometheus, and others.

The structure of Traefik has changed over time, with the current configuration breaking things up into four main groups:

• EntryPoints: These are the network ingress into Traefik, and define the port listening for packets and if they're TCP or UDP.
• Routers: These connect incoming requests to the services that can handle them.
• Middlewares: Attach to routers and can modify requests or responses before they reach your services. It's also where most plugins live.
• Services: Responsible for configuring how to reach the containers or other services that handle incoming requests.

If you're not using containers, you can use any number of other services from which Traefik can pull service details for routing purposes, like Amazon ECS, Etcd, or even an HTTP endpoint. The key is that you're left with more time to play around with your home lab services, because you're not spending all your time updating routing configurations.

Plus, it can reconfigure itself dynamically without your intervention

With how Traefik is designed, it's relatively easy to build new plugins to serve as middleware. The neat thing here is that they're platform-agnostic, so not only do they work across every protocol the reverse proxy works with, they also work with all the major orchestrators, like Kubernetes, Docker, and Amazon ECS, so you don't have to worry about compatibility, just on your design.

Plugins and middleware are flexible in their use. Most reverse proxies bind the plugins to the proxy, so any changes are made to every route unless exceptions are added. But in Traefik, they're attached to the Router elements so that you can build a middleware chain for individual services or routes. And you only install them once, even if you're using them across several routes, reducing complexity and the amount of disc space you take up.

There's one other big benefit to this methodology. Remember, Traefik is set up to configure itself dynamically. Any changes to routing via middleware or plugins are applied in real time, without you having to reload or restart the proxy. Can we say "unlimited uptime?" Of course, we can, especially if our Traefik containers are installed on a high-availability Proxmox cluster.

If your home lab is containerized, Traefik is the easiest way to get a reverse proxy running

My home lab is heavily Docker-centric, with a few scattered VMs for testing in different environments. That makes Traefik a perfect fit, as the automated discovery and routing means I can focus on the parts of home labbing that I enjoy, and not worry about how often the IP addresses of my services change. But even if you're not using containers, Traefik is still fantastic for taking the drudgery out of routing your reverse proxy; it just needs a couple of extra configuration steps. It's simple to use, works as a load balancer, and can work as a reverse proxy that's connected to several different environments, whether those are on-premises or cloud-hosted. I've only scratched the surface of what I can do with it, with the next steps to get it using my own domain, and set up a web application firewall to keep me more secure.