Why I No Longer Use Pangolin

I no longer use Pangolin.

Pangolin is a solid project. I used it for a long time because it solved a real problem for me. It’s a particularly useful piece of infrastructure when you want to put a self-hosted web application on the Internet without turning the process into a weekend project. My needs simply changed.

One of the things I’ve learned over the years is that a good infrastructure decision isn’t necessarily a permanent one. Something that was exactly what I needed a couple of years ago can become the wrong tool without a problem surfacing, and that’s what happened here.

Pangolin was exactly what I needed

For a while, my home network had a pretty simple requirement: I want to share this thing with someone.

In some cases, it was my docs or a web application. Maybe I wanted someone to spend some time playing with ComfyUI or another service that I don’t like keeping to myself. There have been countless instances of needing to temporarily expose something so a peer could see what I was working on. Pangolin was excellent at that. It gave me a relatively straightforward way to take something that existed inside my network and make it available to somebody outside of it.

I even ended up making a video about installing it while I was working with Lawrence Systems with a slightly ridiculous amount of attention for a video about installing infrastructure in a Homelab.

Pangolin’s team even featured it on their homepage and that’s pretty cool.

I guess what I’m getting at is that this isn’t one of those, “Why I switched to X, and I’m never looking back” sort of changes, and it isn’t me discovering a product that didn’t work and running away from it, either. It worked - really well; the problem is that I stopped needing the thing it was particularly good at.

My Homelab Grew Up

This is the part that changed. A few years ago, I had a lot more things that I wanted to share publicly or semi-publicly. Friends would access services I was running and people would poke at things I was experimenting with. I’d spin something up, give somebody a URL, and we’d see what happened. Some of those people took what they saw and built their own systems.

That’s one of my favorite things about having a Homelab - you show somebody something interesting and, six months later, they’ve built their own version of it.

Eventually, the way I looked at my infrastructure evolved. No longer being hands-on with IT as a 9-to-5 had me begin to look at things differently. I stopped thinking so much about how to make things available, replacing the thought with “who actually needs access to this?”

Those are very different questions. These days, most of what I run aren’t things I need to expose to the internet. They’re things I want specific people to be able to reach, and that’s a fundamentally different access model.

No More Public Doorways

This is where Twingate enters the story. I’ve been using Twingate for quite a while, including before I started doing work directly with them. That matters to me because I’m not suddenly discovering a product because somebody is paying me to talk about it.

I’ve used Twingate for over a year, in parallel with Pangolin, and it has increasingly become the more natural way for me to give people access to my infrastructure. This clicked while in line at my local Target last winter. The line was crawling, so I started generating images with my ComfyUI instance from my phone. A few other people in the line got curious, and I let them generate some images while we waited. It was like a bite-sized version of the exposure I mentioned earlier.

If a friend needs access to something I’m running, I don’t need to publish a URL anymore. If an MSP peer needs access to my Gitea instance, I can set them up without exposing it to the public Internet.

I can give them access to the resource they require, and nothing else, and that is a much better fit for where my Homelab is today. There’s also a simple security benefit I appreciate: there is no public surface to attack.

I stopped publishing infrastructure and started granting access to it instead. That’s a fundamentally different access model, and a pretty compelling property.

Collaboration as an Unintended Side Effect

There’s another reason I like this setup that has nothing to do with networking. I have several MSP peers with access to parts of my environment. Some use it to reach my CRM while others are accessing AI-related tools, and a handful are working on a project that involves my n8n and Grist instances along with a bunch of microservices running around here.

I’ve also been able to give people private repository space where they can work on things without having to build and maintain an entire infrastructure stack themselves, and that has turned out to be surprisingly useful. I literally got a Discord message from an MSP owner, while writing this, whose machine didn’t meet my access policy - which is, admittedly, insanely stringent.

I get to see what people are building and when you spend enough time around technically curious people, watching someone else solve a problem is a pretty good way to accidentally find your next idea. Someone builds something weird, and then I build something slightly different. Someone sees that and suddenly the Homelab isn’t just a collection of servers anymore - it’s a shared workshop. That’s a much better use of it than putting another dashboard on the Internet because somebody might want to log into it.

Figuring Out What Fits

Again, Pangolin is great. There are plenty of options for secure remote access right now, and each comes with its own strengths and weaknesses. I’ve used several of them, and I’ve learned that the things I care about aren’t necessarily the things I want everyone else to care about.

Tailscale is a good example. I like what they’ve built, but I found myself uncomfortable with how much abstraction it puts between me and the network underneath it. That’s not inherently a bad thing - for a lot of people, making the network disappear is exactly the point. I happen to prefer being able to see and control what’s happening underneath the abstractions, particularly in my Homelab.

NetBird landed differently for me. It’s a capable networking platform, and I know people who use it very successfully. In my case, it crossed a boundary I care about: I already have opinions about how my network works, particularly around DNS, and I don’t want my remote-access platform making decisions in that area for me. That’s a personal infrastructure preference, not a criticism of how NetBird approaches the problem.

This is about as far as I’d take a comparison between the products. I’m not interested in declaring one of them “better.” I’m interested in choosing the tool that fits the way I operate my infrastructure.

Pangolin made a lot of sense when my requirement was:

I have a thing inside my network that I want somebody on the Internet to access.

My requirement today is much closer to:

I have a bunch of private infrastructure and I want specific people to access specific pieces of it.

Those aren’t completely different needs, but they lead to different architectural decisions. I think there’s a tendency in technology writing to interpret changing tools as some kind of referendum on the previous tool. It isn’t. Sometimes you just outgrow a workflow - and that’s a pretty good outcome.

Infrastructure Sneaks up on You

There’s a broader lesson here that I’ve been thinking about a lot lately. Infrastructure often starts out as a collection of experiments. One of the experiments becomes useful, then something else depends on it, somebody else starts using it - and then you realize you’ve accidentally built a small platform and questions begin to change.

You start caring about access models, backups, upgrades, authentication, what can go wrong, and who is going to have to fix the damn thing when it breaks. This is why I’ve become increasingly attracted to infrastructure that tackles one problem. I don’t need or want every component of my Homelab to be a Swiss Army knife. I prefer to have a handful of specialized tools that do one thing and do it very well.

This approach makes it easier to replace one when my needs change - which brings me to something else I’ve been working on lately. I’ve been rebuilding parts of this environment around that same philosophy: fewer assumptions, clearer boundaries, and infrastructure that supports the things I actually want to do rather than infrastructure that exists because I once thought it would be cool.

The same thought is how I ended up rebuilding my CRM of choice, too - and that’s a story for another post. For now, Pangolin is being retired from my environment. It did its job, it helped me do mine, and the requirements changed as a function of time - and that’s enough reason to move on.