Should you put a UDM-Pro at the edge of your homelab?

The more time I spend with the UDM-Pro at the edge of my home network, the more I think the UDM line is aimed at people who want a network, not at people who want to do networking. It does the job. It just doesn't really invite you in.

I run BIRD2 on Linux for everything AS215855 related, so the UDM-Pro is doing something specific in my setup. It's the gateway for the house, not the gateway to the internet at the ASN level. That distinction is going to matter.

So if you've been eyeing one for the homelab, here's how I'd think about it.

What it actually is

The UDM-Pro is four things in one rackmount box. A gateway and firewall, a UniFi controller, an NVR, and the brains for any UniFi APs and switches you adopt to it. There's no PoE on the box itself, so if you want to feed UniFi cameras and APs you'll need a separate UniFi PoE switch. Most people end up buying one anyway.

That bundling is the whole pitch. Instead of running a separate router, a separate AP controller, and a separate NVR, you get one device that does all of it. There's an obvious appeal to that, especially if you want the homelab to be a hobby and not a second job.

But there's a rule about restaurants that I think applies here. If you walk into a place with forty dishes on the menu, you start to wonder whether any one of them is going to be great. A kitchen with that much surface area is doing a lot of things passably and very few things deeply. The UDM is four products in one box, and after a while you start to feel it the same way. It's good at all four. It isn't deep at any of them. That tradeoff is fine if your bar for any one role is "good enough". It starts to bite when your bar for one of them, in my case the routing, is higher than that.

What it's good at

Anyway. Here's what the UDM actually gets right.

The topology view is genuinely useful. You can see every adopted device, every client, what's plugged into which port, and live throughput per client. When something is misbehaving on the network it's usually faster to find it in the UniFi UI than it would be to chase it through tcpdump and ARP tables. Right?

VLAN setup is straightforward once you accept how UniFi wants you to do it. You define networks, tag them on ports, and the firewall rules between zones are a few clicks. It's not as expressive as iptables or pf, but for the kind of segmentation most homelabs need (IoT VLAN, guest VLAN, lab VLAN, trusted VLAN) it's more than enough.

The VPN story has gotten much better over the past couple of years for the common case. WireGuard server is built in and works for the v4 case. Site Magic handles site-to-site mesh between UniFi sites without you needing to touch IPsec configs. The Identity stuff for remote client access works. None of this is exotic, and you don't have to fight it for the bread-and-butter setup.

And under everyday load, the box just does the job. The household saturates its WAN when it wants to. LAN-to-LAN routing between VLANs holds up. Latency through the gateway doesn't show up on traceroutes from a client to anywhere I care about. The UDM isn't the thing in the house anyone complains about, which is half the battle for any edge device.

Where it gets in your way

The thing that keeps biting me is WireGuard and IPv6. The UDM gives you WireGuard, but only the v4 path is in the official UI. The fields in the controller's WireGuard server panel are v4 fields top to bottom. Interface address, peer allowed-IPs, the lot. There's no route through the controller to put v6 on the tunnel. You can SSH in and add it by hand, which works, until the controller pushes config and your edits are gone. For a platform that puts WireGuard front and center, the fact that v6 still isn't part of the official story tells you which corners of the menu got real attention.

New hardware, old gaps

Zoom out from that day-to-day gripe for a moment, because it sits inside a bigger pattern, and the pattern is really what I keep coming back to. It isn't even about the original UDM-Pro any more. Ubiquiti keeps shipping new gateway hardware. The SE, the Max, the Cloud Gateway Ultra, the UDR, and most recently the UDM Beast. Each release is faster than the last. But the fundamentally missing features from the existing product line don't move much.

Take the Beast. It runs ARM Neoverse N2 cores, the same family of cores you find in serious server silicon. 25GbE WAN. Twice the RAM of the Pro Max. $1,499. On paper this is a box that wouldn't look out of place at the edge of a small datacenter.

Now look at what you still don't get on it. The gateway config still has no version-controllable export. IPv6 still isn't quite a first-class peer of v4 across the platform, in firewall rules and in places like the WireGuard server we just talked about. BGP is still bolted onto the side of the UI rather than integrated into it. None of those are hardware problems. Neoverse N2 cores will not fix any of them.

That's what feels off. The hardware refresh keeps happening. The platform keeps not catching up. The Beast can have all the infrastructure-grade silicon in the world, and on the day it ships you still can't tell at a glance from the UI which of your BGP peers are flapping. After a while that stops looking like a roadmap problem and starts looking like a choice about where the engineering effort goes.

What about BGP

A quick note for anyone wondering, because I know some of you are. And these days that audience isn't just people running their own ASN. If you have a homelab Kubernetes cluster you probably touch BGP too. MetalLB in BGP mode, or Cilium announcing service prefixes, both want a BGP peer somewhere on the network, and your home gateway is the obvious place to put it.

The UDM is running FRR under the hood, so the protocol implementation itself is the real thing. You get BGP, OSPF, route-maps, prefix-lists, all of it. That part is not the limitation.

The limitation is that BGP isn't part of the controller. It's adjacent to it. The controller manages your VLANs and your firewall rules in real time. Your BGP config is a file you download, edit, and upload. That is not nothing. You can keep that file in git if you want, which is more than you can say for the rest of the gateway's config. But it makes BGP feel like a foreign object on the box. Add a MetalLB pool? Download, edit, upload. Onboard a new BGP peer? Same.

Would I want to do that on a UDM-Pro myself? No. Not because FRR is the problem. FRR is fine. The chore is just the chore.

For my own ASN work specifically I keep BGP off the UDM entirely. It sits next to a Linux server running BIRD2 where the config lives in git and bird-exporter handles metrics. That separation is the right one for me. The Kubernetes case is harder to escape, since MetalLB really does want to peer with your gateway. You live with the file-shuffle workflow until Ubiquiti decides to bring BGP into the UI properly.

Conclusion

So would I recommend the UDM-Pro for a homelab edge? If you came here because you're into networking, probably not. And the same goes for the rest of the UDM line.

It will save you from running and maintaining three or four separate appliances. The UI is honestly really good. The ecosystem, if you stay inside it, is coherent in a way that almost no other prosumer gear is. None of that is fake.

But networking is exactly the thing the UDM hides from you. You will not get better at BGP by running one. You will not get better at iptables. The platform is built to keep you above that layer, and the hardware refreshes keep widening the gap between the silicon and the management surface that touches it.

For me, that's the call. Not whether the UDM is good or bad as a box, but whether what it hides from you is what you came here to learn about. For my own setup the answer ended up being "keep BGP off it", and the UDM has been a fine home gateway ever since.