If your NAS has enough resources the happy(ish) medium is to use your NAS as a hypervisor. The NAS can be on the bare hardware or its own VM, and the containers can have their own VMs as needed.

Then you don’t have to take down your NAS when you need to reboot your container’s VMs, and you get a little extra security separation between any externally facing services and any potentially sensitive data on the NAS.

Lots of performance trade offs there, but I tend to want to keep my NAS on more stable OS versions, and then the other workloads can be more bleeding edge/experimental as needed. It is a good mix if you have the resources, and having a hypervisor to test VMs is always useful.

If you are just using a self signed server certificate anyone can connect to your services. Many browsers/applications will fail to connect or give a warning but it can be easily bypassed.

Unless you are talking about mutual TLS authentication (aka mTLS or two way ssl). With mutual TLS in addition to the server key+cert you also have a client key+cert for your client. And you setup your web server/reverse proxy to only allow connections from clients that can prove they have that client key.

So in the context of this thread mTLS is a great way to protect your externally exposed services. Mutual TLS should be just as strong of a protection as a VPN, and in fact many VPNs use mutual TLS to authenticate clients (i.e. if you have an OpenVPN file with certs in it instead of a pre-shared key). So they are doing the exact same thing. Why not skip all of the extra VPN steps and setup mTLS directly to your services.

mTLS prevents any web requests from getting through before the client has authenticated, but it can be a little complicated to setup. In reality basic auth at the reverse proxy and a sufficiently strong password is just as good, and is much easier to setup/use.

Here are a couple of relevant links for nginx. Traefik and many other reverse proxies can do the same.

How To Implement Two Way SSL With Nginx

Apply Mutual TLS over kubernetes/nginx ingress controller

The biggest question is, are you looking for Dolby Vision support?

There is no open source implementation for Dolby Vision or HDR10+ so if you want to use those formats you are limited to Android/Apple/Amazon streaming boxes.

If you want to avoid the ads from those devices apart from side loading apks to replace home screens or something the only way to get Dolby Vision with Kodi/standard Linux is to buy a CoreELEC supported streaming device and flashing it with CoreELEC.

List of supported devices here

CoreELEC is Kodi based so it limits your player choice, but there are plugins for Plex/Jellyfin if you want to pull from those as back ends.

Personally it is a lot easier to just grab the latest gen Onn 4k Pro from Walmart for $50 and deal with the Google TV ads (never leave my streaming app anyways). Only downside with the Onn is lack of Dolby TrueHD/DTS Master audio output, but it handles AV1, and more Dolby Vision profiles than the Shield does at a much cheaper price. It also handles HDR10+ which the Shield doesn’t but that for at isn’t nearly as common and many of the big TV brands don’t support it anyways.

I’ve got about 30 zwave devices, and at first the idea of the 900mhz mesh network sounded like a really solid solution. After running them for a few years now if I were doing it again I would go with wifi devices instead.

I can see some advantages to the mesh in a house lacking wifi coverage. However I would guess most people implementing zigbee/zwave probably have a pretty robust wifi setup. But if your phone doesn’t have great signal across the entire house a lightswitch inside of a metal box in the wall is going to be worse.

Zwave is rather slow because it is designed for reliability not speed. Not that it needs to be fast but when rebooting the controller it can take a while for all of the devices to be discovered, and if a device goes missing things break down quickly, and the entire network becomes unresponsive even if there is another path in the mesh. Nothing worse than hitting one of your automations and everything hangs leaving you in the dark because one outlet three rooms over is acting up.

It does have some advantages, like devices can be tied to each other (i.e. a switch tied to a light) and they will work even without your hub being up and running (zwave controller I think can even be down).

Zwave/Zigbee also guarantee some level of compatibility/standardization. A lightswitch is a lightswitch it doesn’t matter which brand you get.

On the security front Zwave has encryption options but it slows down the network considerably. Instead of just sending out a message into the network it has to negotiate the encrypted connection each time it wants to send a message with a couple of back and forth packets. You can turn it on per device and because of the drawbacks the recommendation tends to be, to only encrypt important things like locks and door controls which isn’t great for security.

For Zwave 900mhz is an advantage (sometimes). 900mhz can be pretty busy in densely populated areas, but so can 2.4 for zigbee/wifi. If you have an older house with metal boxes for switches/plaster walls the mesh and the 900mhz penetration range may be an advantage.

In reality though I couldn’t bridge reliably to my garage about thirty feet away, and doing so made me hit the Zwaves four hop limit so I couldn’t use that bridge to connect any additional devices further out. With wifi devices connecting back to the house with a wifi bridge, a buried Ethernet cable, etc can extend the network much more reliably. I haven’t tried any of the latest gens of Zwave devices which are supposed to have higher range.

The main problem with wifi devices is that they are often tied to the cloud, but a good number of them can be controlled over just your LAN though. Each brand tends to have their own APIs/protocols though so you need to verify compatibility with your smart hub before investing.

So if you go the wifi route make sure your devices are compatible and specifically check that your devices can be controlled without a cloud connection. Especially good to look for devices like Shelly that allow flashing of your own firmware or have standardized connection methods in their own firmware (Shelly supports MQTT out of the box)

All of the “snooping” is self contained. You run the network controller either locally on a PC, or on one of their dedicated pieces of hardware (dream machine/cloud key).

All of the devices connect directly to your network controller, no cloud connections. You can have devices outside of your network connected to your network controller (layer 3 adoption), but that requires port forwarding so again it is a direct connection to you.

You can enable cloud access to your network controller’s admin interface which appears to be some sort of reverse tunnel (no port forwarding needed), but it is not required. It does come in handy though.

As far as what “snooping” there is, there is basic client tracking (what IP/mac/hostnames) to show what is connected to your network. The firewall can track basics like bandwidth/throughout, and you can enable deep packet inspection which classifies internet destinations (streaming/Amazon/Netflix sort of categories). I don’t think that classification reaches out to the internet but that probably needs to be confirmed.

All of their devices have an SSH service which you can login to and you have pretty wide access to look around the system. Who knows what the binaries are doing though.

I know some of their WISP (AirMAX) hardware for long distance links has automatic crash reporting built in which is opt out. There is a pop up to let you know when you first login. No mention of that on the normal Unifi hardware, but they might have it running in the background.

I really like their APs and having your entire network in the network controller is really nice for visibility but my preference is to build my own firewall that I have more control over and then Unifi APs for wireless. If I were concerned about the APs giving out data, I know I could cut that off at the firewall easily.

A lot of the Unifi APs can have OpenWRT flashed on them, but the latest Wifi7 APs might be too locked down.