Home-lab design (2026 edition) part 3 - Inside the Docker VM

This is the next part of my progressively-deeper look at my "home lab" setup in 2026 - now we're peering into the Docker VM itself. There are a million "here are the 19 Docker apps you ABSOLUTELY MUST run in 2026" listicles out there, that's fine. I don't run that many, and many of them are of a highly-personalised, only-on-my-network-thankyou nature that I'm not even going to mention. The key two (yes, just two) are [Nginx Proxy Manager](https://nginxproxymanager.com/) and [Arcane](https://getarcane.app/). The first because it means I can forget about individual internal network addresses, port numbers, and "this website is not secure" non-HTTPS browser warnings, the latter because it's a dead simple dashboard to see what's going on at the Docker level. I'm not even going to talk any more about Arcane because it's just so simple; it's exactly what you'd expect a Docker web UI to look like:

## Nginx Proxy Manager ALL THE THINGS NPM is just a really nice and simple frontend for an Nginx instance, and I must admit I may have got a little carried away re-front-ending almost every local-network-based web app I regularly use, viz: - Arcane - HAOS - My Synology NAS - My Mikrotik router - Octoprint - My Raspberry Pi - The Proxmox UI - My DLNA streamer, Serviio - My ISP router (a TP-Link) - All my personal scratch-my-own-itch apps; and - Nginx Proxy Manager itself(!) ### Setting up Now *most* of these webapps and Dockerized apps work *great* with Nginx Proxy Manager providing a wildcard HTTPS certificate and proxying for them. If it's a simple app like `http://nas:5000` it's the work of seconds to give it a better address. For a new Dockerized webapp, my process is: - Get it going and find out what port it's on, i.e. `webport` - Check I can hit it at `http://docker:webport` - Go into NPM and add a proxy host for `coolapp.lab.themillhousegroup.com` that points to `http://docker:webport`, and add force SSL on the SSL tab using my `*.lab.themillhousegroup.com` wildcard certificate - I've already got a corresponding "wildcard" DNS `CNAME` entry in the Mikrotik router that ensures `*.lab.themillhousegroup.com` will resolve to `docker`:

NPM automagically manages this certificate for me thanks to the wonders of the `DnsMulti` DNS-based certificate management system, which does the whole Lets Encrypt automated-renewal dance via any one of a [huge number of DNS providers](https://go-acme.github.io/lego/dns/#dns-providers) (I use Netlify which is as simple as configuring a Personal Use Token and giving it to the `dnsmulti` plugin as an environment variable) There are a couple of "difficult" apps that needed a little more configuration though. ### Home Assistant Doesn't take kindly to being proxied by NPM and has to have a couple of (very simple) stanzas added to its `configuration.yaml`: ``` # Allow NGinx Proxy Manager to proxy for homeassistant: # https://community.home-assistant.io/t/using-nginx-proxy-manager-with-homeassistant-all-via-docker/725019/6 # https://www.reddit.com/r/homeassistant/comments/1dp4nwf/hass_behind_nginx_proxy_manager/ http: use_x_forwarded_for: true trusted_proxies: - 10.240.0.105 # IP of docker - 10.240.0.0/24 # the Docker subnet - 127.0.0.1 # Add the localhost IPv4 address - ::1 # Add the localhost IPv6 address # ... and further to that: # https://community.home-assistant.io/t/using-nginx-proxy-manager-with-homeassistant-all-via-docker/725019/13 homeassistant: external_url: "https://haos.lab.themillhousegroup.com" ``` As you can probably tell, I like pasting the relevant web link into configuration docs; those links are to various fora - [Reddit `/r/homeassistant`](https://www.reddit.com/r/homeassistant/comments/1dp4nwf/hass_behind_nginx_proxy_manager/) for the `trusted_proxies` IP addresses and the [Home Assistant Community](https://community.home-assistant.io/t/using-nginx-proxy-manager-with-homeassistant-all-via-docker/725019/13) for the `external_url` setting. ### Proxmox Proxmox *really* wants you to use HTTPS everywhere, so you need to turn on ALL the SSL options in NPM, and ALSO use https *in the address of the proxied instance as well* - which is unusual, but makes sense, as it does create a self-signed certificate when you first set up your system. I basically followed [this guide on Reddit](https://www.reddit.com/r/Proxmox/comments/1jsgto6/accessing_proxmox_via_nginx_proxy_manager/) so my NPM setup for `proxmox.lab.themillhousegroup.com` looks like this (note the `https` in the Scheme - different to every other host!):

Upgrading to the Mikrotik RouterBoard RB2011, Part 3 - DNS

This is Part 3 of my RB2011 series - if you want to start from the start, [here's Part 1](https://blog.themillhousegroup.com/2025/01/upgrading-to-mikrotik-routerboard.html). You can find the [whole series here](https://blog.themillhousegroup.com/search/label/routerboard). We're part-way through replacing the `dnsmasq` instance on the Raspberry Pi (which does DHCP, DNS and ad-blocking via Pi-Hole-style `0.0.0.0` resolution). To minimise interruption to network users, we're doing this in a staged manner, gradually moving services over to the RB2011. DHCP is [done](https://blog.themillhousegroup.com/2025/03/upgrading-to-mikrotik-routerboard.html) so we now have the Routerboard providing leases to everyone, but the lease points back to the Pi for DNS. We'll set up DNS now, because _local-device_ name resolution will actually be in a bit of a mess (i.e. it won't work at all) - let's fix that! ### DNS on RouterOS v7 The [Mikrotik DNS server](https://help.mikrotik.com/docs/spaces/ROS/pages/37748767/DNS) is pretty straightforward to configure. All we have to do is set the upstream DNS server (the ISP router) and allow external connections: ``` [admin@MikroTik] > /ip/dns/set servers=10.240.0.1 [admin@MikroTik] > /ip/dns/set allow-remote-requests=yes ``` Then we change our global DHCP server config to start serving the RB2011 as the DNS server: ``` [admin@MikroTik] > /ip/dhcp-server/network/set numbers=0 dns-server=10.240.0.11 ``` We should also add a manual entry for the Raspberry Pi, which used to "just know" its own address but now we need to be explicit: ``` [admin@MikroTik] > /ip/dns/static/add name=pi1 address=10.240.0.200 ttl=9000 ``` And also, the Pi needs to be told to use the RB2011 for DNS now: *`/etc/resolv.conf`:* ``` # Use the Mikrotik RouterBoard RB2011: nameserver 10.240.0.11 ``` Whew! As DHCP clients start getting their new DNS settings (or you can force-renew one if you're impatient) you'll start to see the _IP_ -> _DNS_ -> _Cache_ page in the web UI start to fill up. Mostly with absolute crap, but that's t'Internet for you...

### Adlist functionality For me, the key advantage of running my own DNS server is ad-blocking via the Pi-Hole or ["DNS sinkhole"](https://en.wikipedia.org/wiki/DNS_Sinkhole) mechanism - in short, DNS requests for known ad-serving domains get the answer `0.0.0.0` which stops resolution in its tracks. RouterOS has full support for this, and it even uses the same format for the blocked-domain list as [Pi-Hole](https://docs.pi-hole.net/database/gravity/#adlist-table-adlist) so the transition from the Pi couldn't be easier. I like to use my own "curated" adlist as _sometimes_ it's useful to be able to comment-out a line, when it turns out certain extremely-annoying apps actually *need* access to one of those spammy domains. To do this, _push_ your adlist file from the Pi onto the RB2011 using `scp`: ``` pi $ scp /etc/dnsmasq.blockfiles/dnsmasq.blocklist.txt admin@mikrotik:adlist.txt ``` And enable it in the RB2011: ``` [admin@MikroTik] > /ip/dns/adlist/add file=adlist.txt ``` And that's it! Allow some time for all the DHCP clients to get told about their new DNS settings, and then we can turn off `dnsmasq` on the Pi for good! ``` pi $ sudo service dnsmasq stop ``` P.S. don't forget to `/system/backup/save` again on the RB2011!