Powered by Pangolin

Most of the time, I would deploy a site like this to a standard VPS. Traefik would run beside the application stack, Docker labels would define the routes, and the server would handle both public ingress and the application itself. It is a proven, straightforward approach.

For 605software.com, I wanted to try something different. I already owned a VPS, but I also had capable hardware sitting at home. Using it meant lowering the cost of hosting additional projects, learning more about self-hosted infrastructure, and putting equipment I already owned to work.

The site runs in Docker on a server in my basement, while a small public VPS with just 2 vCPUs and 2 GB of RAM runs a self-hosted instance of Pangolin at the edge. The VPS manages public DNS, TLS certificates, ports 80 and 443, and the policies that determine what reaches the site, including UFW, Fail2ban, and other standard security measures.

Internet -> Pangolin VPS -> Gerbil/Newt tunnel -> home server Docker containers

Making use of hardware I already owned

The home server is an older Dell OptiPlex desktop with an Intel Core i5-7500, 8 GB of RAM, and a 500 GB SATA SSD. It is not fancy hardware, but it is more than capable of hosting this site and several other personal or business services.

That capacity is the point. A small marketing site does not need a large cloud instance, and neither do many internal tools or low-traffic applications. The OptiPlex lets me use hardware I already own for the workloads that fit it, while keeping the VPS focused on public ingress.

Pangolin sits at the edge

The VPS is the only machine exposed to the public internet. Pangolin's bundled Traefik instance handles HTTPS and reverse proxying there, so I do not need a second public reverse proxy or an open port on my home router.

I specifically did not want to rely on a proprietary tunneling service such as Cloudflare Tunnel for this setup. Pangolin is open source, gives me direct control of the edge infrastructure, and keeps the routing model understandable. I also did not want to expose services by forwarding ports from my home router (for obvious reasons). Avoiding that direct inbound path keeps the home network boundary smaller and easier to manage.

The split makes responsibilities clear: the VPS accepts public traffic, and the home server runs the applications.

The connection starts at home

Newt runs alongside the application containers on the home server and creates an outbound tunnel to the VPS. Because the connection originates from inside the network, there is no inbound port forwarding and no need to reveal the home IP address.

When a request arrives for 605software.com, Pangolin sends it through that established tunnel to the Nuxt container running the site. Docker DNS resolves the service name on the shared pangolin_public network.

Keeping the application network small

Only the web-facing application containers join the pangolin_public network. Databases, caches, queues, workers, and the Docker API stay on private networks. The application does not publish a host port; Pangolin reaches it through Newt instead.

This is a useful default for a small self-hosted setup. Public routing is explicit, and adding another site means creating one HTTP resource with a hostname, Docker service name, and internal port.

Multiple services

The OptiPlex also runs Umami for privacy-focused analytics and Bugsink for error monitoring. Both let me keep application data on infrastructure I control while avoiding usage-limited hosted analytics plans and paid cloud error-tracking services such as Sentry.

Where practical, I prefer dependable, open-source software that I can self-host rather than adding another proprietary service or recurring subscription. Pangolin, Umami, and Bugsink all fit that approach without compromising the capabilities this site needs.

I am happy with how straightforward the setup was, from routing traffic through Pangolin to bringing each Docker service online. Next, I plan to put the server to work hosting more services, including Infisical for secrets management.

More than a tunnel

This setup uses only a small part of what Pangolin can do. For 605software.com, I primarily use it to route public traffic through an encrypted tunnel to a Docker service on my home server.

Pangolin can also provide zero-trust network access, securely expose private homelab services, and restrict resources to authenticated users or approved clients. Those capabilities make it useful for administrative tools and internal applications that should never be openly accessible from the internet.

My current setup is intentionally simple, but Pangolin leaves room to expand the home server without redesigning how remote access and public ingress work.