DEV Community: Christoph Dieck

Goodbye Fritz!Box, Hello Ubiquiti

Christoph Dieck — Fri, 18 Sep 2026 08:50:00 +0000

Why switch at all?

The Fritz!Box 7690 is a capable device. Telephony, Wi-Fi, DECT, smart home, all in one box. That is also the problem. I want a network I actually control: VLANs, firewall rules, a proper dashboard. The Fritz!Box does a bit of everything; I want something that does the routing well and leaves the rest to me.

On top of that, I kept running into performance problems over the past few months. The Wi-Fi would slow down for no obvious reason, in the middle of the day, with the same number of devices as always. Streaming stuttered, video calls lagged. A reboot fixed it every time, but who wants to restart their router on a schedule? It felt more and more like the box was overwhelmed by everything it had to handle: smart home devices, DECT phones, VPN, guest network, AdGuard as DNS. At some point it just could not keep up.

I went with the Ubiquiti Cloud Gateway Ultra (UCG Ultra). Small, reasonably priced, and the UniFi ecosystem has everything a homelab network needs.

Step 1: reading the Fritz!Box config

Before unplugging the old router, you should know what it actually does. The Fritz!Box has an export function under System → Backup → Save. The result is an .export file, basically a massive text dump of every configuration file on the device.

The relevant WAN settings live inside ar7.cfg. Opening that file for the first time feels a bit like doing your taxes. Thousands of lines, cryptic variable names. But the handful of values you actually need are easy to spot once you know what to look for.

One thing to keep in mind: the export file is encrypted if you set a password during export. Passwords and credentials inside the config are additionally encoded. If you need to extract plaintext credentials from the file (e.g. SIP credentials for VoIP), you can use my Fritz!Box Config Decrypt Tool.

Step 2: understanding the WAN settings

My ISP is Buchholz Digital (BuDi) with an FTTH connection. The setup is refreshingly simple: no PPPoE, no credentials. The router connects via Ethernet to the ONT, tags VLAN 700, and gets a public IP through DHCP.

Here is the relevant section from the Fritz!Box config:

dslifaces {
        enabled = yes;
        name = "internet";
        dsl_encap = dslencap_ether;
        dslinterfacename = "dsl";
        no_masquerading = no;
        stackmode = stackmode_ipv4only;
        vlancfg {
                vlanencap = vlanencap_fixed_prio;
                tagtype = vlantagtype_customer;
                vlanid = 700;
                vlanprio = 0;
        }
        ppptarget = "internet";
        mtu = 0;
        etherencapcfg {
                use_dhcp = yes;
        }
        stay_always_online = yes;
}

The key values at a glance:

Setting	Value
Connection type	DHCP (no PPPoE)
Internet VLAN	700
VoIP VLAN	650
TR-069 VLAN	550
IPv4	via DHCP
IPv6	Automatic (dual-stack)
MTU	1500 (auto)

Three VLANs in total. For the UCG Ultra, only VLAN 700 matters. VLAN 650 handles telephony and VLAN 550 is for remote management by the ISP. The UCG Ultra needs neither.

Step 3: configuring the UCG Ultra

The UniFi Network Controller makes this surprisingly painless:

Under Internet/WAN, set connection type to DHCPv4.
Set VLAN ID to 700. This is the one that matters.
MAC Address Override is there if the ISP expects the Fritz!Box MAC. I did not need it, but it is good to know it exists. You can find the old MAC in the export file under user.cfg, where the Fritz!Box itself is listed as a device:

usercfg {
        users2 {
                type = internet_user_ip;
                landeviceUID = 8511;
                mac = 34:E1:A9:24:97:3D;
        }
}

The MAC is also on the sticker on the bottom of the Fritz!Box, or in the web interface under Home Network → Network.

Set IPv6 to "Auto" or "DHCPv6" for dual-stack.
Set DNS to custom servers (in my case 192.168.50.250 for AdGuard and 1.1.1.1 as fallback).

Cable from the ONT into the WAN port of the UCG Ultra, configure VLAN 700, done. It worked on the first try. I was almost disappointed there was no drama.

Step 4: migrating LAN settings

I carried the Fritz!Box settings over to the LAN side. The subnet is 192.168.50.0/24 with gateway 192.168.50.1 and a DHCP range from 192.168.50.20 to 192.168.50.200.

Static DHCP leases:

Device	IP	MAC
NAS	192.168.50.2	90:09:D0:35:57:8B
Proxmox	192.168.50.24	98:FA:9B:2E:20:CB
Docker host	192.168.50.46	BC:24:11:A5:65:6F

For the IPv6 ULA prefix I set fd15:d91c:273f::/48 manually on the UCG Ultra so that local IPv6 addresses (like AdGuard on fd15:d91c:273f::250) stay stable.

Does the ISP notice the switch?

Yes, and it does not matter.

The MAC address on the WAN port is different. With a DHCP connection like mine that is not a problem: the DHCP server just hands out a new lease. If it does cause trouble, the UCG Ultra lets you override the MAC. The DHCP hostname also changes, since the Fritz!Box sends fritz.box and the UCG Ultra sends something else. That is purely cosmetic.

TR-069 goes away. The Fritz!Box was remotely managed by the ISP via TR-069 on VLAN 550, and the UCG Ultra does not support it, so the ISP loses remote access to the router. In my case a quick phone call to BuDi sorted it out. Everything else stays the same: VLAN 700 works identically, DHCP-based IP assignment is device-independent, and the fiber connection at the ONT is unchanged.

What about VoIP?

The Fritz!Box handled telephony over VLAN 650, and the UCG Ultra cannot do SIP. If you still need a landline, you can run the Fritz!Box as an IP client behind the UCG Ultra just for telephony, or use a standalone SIP phone or adapter.

I went with the first option. The Fritz!Box now sits on a LAN port of the UCG Ultra in IP client mode and only handles DECT and phone calls. To set that up, go to Internet → Account Information → Internet Access in the Fritz!Box UI and switch to "Use existing internet connection (IP client)". Retirement for the Fritz!Box, but with a small side gig.

What I learned

The Fritz!Box export files are the key to this. All WAN settings live in ar7.cfg, and once you have fought through the text dump you can find the relevant values in a few minutes. For FTTH with BuDi you only need three things: VLAN 700, DHCP, no PPPoE.

Swapping the router on a DHCP connection is painless. No call to the ISP, no activation, no waiting. Plug it in, configure the VLAN, it works. TR-069 going away feels more like a feature than a bug, and the Fritz!Box lives on as a dedicated telephony device in IP client mode instead of going in the bin.

The 35-watt roommate now has a new neighbor in the network cabinet. Part 8 is about the UniFi VLAN setup, because once you have a proper router you might as well do proper network segmentation.

This post was originally published on www.slashgordon.link.

Ads? Never Heard of Them.

Christoph Dieck — Wed, 16 Sep 2026 13:57:21 +0000

The goal: quiet across the whole network

Ads on the internet are exhausting, on phones, on smart TVs, everywhere. For anyone running a homeserver the obvious answer is a network-wide DNS blocker. Pi-hole was the default choice for years, but I went with AdGuard Home. It feels more modern, does DNS-over-HTTPS and DNS-over-TLS out of the box, and I like the interface more.

Sounds easy enough, right? Start the container, done. That was optimistic.

The final boss: port 53

My first attempt was to run the container on the host network. That failed immediately because of port 53.

Port 53 is the standard port for DNS requests, and on almost every modern Linux server, my Ubuntu host included, it is already taken by systemd-resolved. The container could not start.

I could have disabled systemd-resolved, but poking around in the host system goes against how I want to run this machine. The Docker host should stay as vanilla as possible. So, plan B.

The fix: Macvlan

A Docker Macvlan network is made for cases like this. The container behaves like a real physical device on the network: it gets its own MAC address and, more importantly, its own IP address from the router, independent of the host server. No more port conflict on port 53.

My network is dual-stack, so I did it properly. The container gets a dedicated IPv4 address (192.168.50.250) and a dedicated IPv6 address, a stable ULA starting with fd....

The next problem: Traefik

The DNS blocker worked now, but I wanted the web dashboard on my own domain (adguard.dieck-labs.de) behind Traefik as a reverse proxy, instead of typing IP addresses into the browser. This is where it got annoying.

Network isolation

For Traefik to reach the container, both services need to share the same internal Docker network, in my case apps. But a container attached to Macvlan is isolated from the normal Docker world. So the container has to join both networks: Macvlan for DNS traffic from the LAN, apps for Traefik.

The 502 Bad Gateway

After wiring it into Traefik I got nothing but 502 Bad Gateway. Hours of debugging.

The cause was subtle: if you do the initial AdGuard Home setup via the Macvlan IP, it often configures itself to listen only on that one interface, so requests coming from Traefik through the internal apps network are ignored. In AdGuardHome.yaml I had to bind the web UI to 0.0.0.0 so it listens on all interfaces, and move the admin UI to an uncommon port like 8087. Then Traefik can reach it while DNS keeps using port 53.

The architecture

This is what the traffic flow looks like now:

graph TD
    subgraph "Home Network (192.168.50.0/24)"
        Phone[📱 Smartphone] -- DNS Query --> AGH
        TV[📺 Smart TV] -- DNS Query --> AGH
        Laptop[💻 Laptop] -- DNS Query --> AGH
        FB[🌐 Fritz!Box<br/>DHCP Server] -. distributes DNS .-> Phone & TV & Laptop
    end

    subgraph "Lenovo M920q (Docker)"
        AGH[AdGuard Home<br/>192.168.50.250]
        TF[Traefik<br/>Reverse Proxy]

        AGH -- apps network --> TF
    end

    subgraph "Internet"
        User((👤 Me)) -- HTTPS --> CF[Cloudflare]
        CF -- Tunnel --> TF
        TF -- Port 8087 --> AGH

        AGH -- DNS Upstream --> DNS[Cloudflare DNS<br/>1.1.1.1]
    end

    style AGH fill:#4CAF50,stroke:#2E7D32,color:#fff

The config: two networks, one container

Here is the final Docker Compose file (adguard.yml in the repo), the result of too many evenings staring at terminal output:

version: "3.9"

services:
  adguardhome:
    image: adguard/adguardhome:latest
    container_name: adguardhome
    restart: unless-stopped
    networks:
      # Network 1: DNS traffic from the home network
      macvlan_net:
        ipv4_address: 192.168.50.250
        ipv6_address: fd15:d91c:273f:0::250
      # Network 2: Communication with Traefik
      apps:
    volumes:
      # Docker-managed working data (logs etc.)
      - adguard_work:/opt/adguardhome/work
      # IMPORTANT: local bind mount for writable config
      - ./adguard:/opt/adguardhome/conf
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=apps"
      - "traefik.http.routers.adguard.rule=Host(`adguard.dieck-labs.de`)"
      - "traefik.http.routers.adguard.entrypoints=websecure"
      - "traefik.http.routers.adguard.tls.certresolver=myresolver"
      # Traefik talks to the admin UI on this custom port
      - "traefik.http.services.adguard.loadbalancer.server.port=8087"

networks:
  macvlan_net:
    driver: macvlan
    enable_ipv6: true
    driver_opts:
      parent: ens18 # Physical host interface
    ipam:
      config:
        - subnet: 192.168.50.0/24
          gateway: 192.168.50.1
        - subnet: fd15:d91c:273f:0::/64
          gateway: fd15:d91c:273f:0::1
  apps:
    external: true # Existing Traefik network

volumes:
  adguard_work:
    external: true

The config trick

One detail matters: AdGuardHome.yaml in the local ./adguard directory needs a small manual change:

http:
  address: 0.0.0.0:8087  # Listen on all interfaces
dns:
  bind_hosts:
    - 192.168.50.250
    - "fd15:d91c:273f:0::250"
  port: 53

I first tried mounting the config via Docker configs. Clean, and satisfying on paper. But it also made the file read-only, so the AdGuard dashboard could no longer save changes. The old-fashioned bind mount turned out to be the practical choice.

Feeding the Fritz!Box

A network-wide ad blocker is useless if no device uses it. Instead of changing DNS settings on every phone, laptop, and TV by hand, I let the Fritz!Box hand out AdGuard as the default DNS server over DHCP. In the Fritz!Box UI, go to http://fritz.box → Internet → Account Information → DNS Server, enable "Use other DNSv4 servers", and enter 192.168.50.250 as the preferred DNS server. For IPv6 DNS, add fd15:d91c:273f:0::250 as well. Then briefly toggle Wi-Fi off and on so devices pick up the new settings.

The result

Open the AdGuard query log and you can watch tracking domains get dropped in real time.

The YouTube app on the smart TV feels snappier because it spends less time on ad requests, and every device in the house sees less tracking.

A few things I took away: Macvlan is the cleanest way around a host-level port conflict like port 53; a two-network Docker setup only works reliably if the service binding is right; and a pragmatic bind mount sometimes beats a cleaner read-only config. The 35-watt roommate now doubles as the bouncer for the home network.

This post was originally published on www.slashgordon.link.

Monitoring, or 'Why is the internet constantly asking for my .php files?

Christoph Dieck — Mon, 14 Sep 2026 14:36:15 +0000

A Grafana dashboard sounds like an enterprise thing, far too much hassle for a private homelab. I used to think so too.

Terms like Prometheus, Exporter, Loki, and Promtail sound like a lot of overhead and a steep learning curve. But I started playing around with it for fun, and thanks to Docker the whole thing was up and running faster than you can spell "monitoring". This is how I ended up monitoring my setup and turning away bots at the front door.

What do I actually want to know?

You might remember my setup from the article about Cloudflare Tunnels and Docker Stacks. I want visibility into my Nginx instances, the Proxmox host, the Ubuntu server (including SSH logs), and my Docker containers.

That's a fair number of endpoints, but there's a matching exporter for almost all of it:

pve-exporter fetches metrics directly from the Proxmox API.
node-exporter is the classic for Linux host metrics (CPU, RAM, disk).
cAdvisor looks inside Docker containers and cgroups.
promtail is the log vacuum that ships everything to Loki.

The backend is Loki for logs and Prometheus for time-series metrics. It looks like this:

graph LR
    classDef grafana fill:#F47A20,stroke:#fff,stroke-width:2px,color:#fff;
    classDef prometheus fill:#E6522C,stroke:#fff,stroke-width:2px,color:#fff;
    classDef loki fill:#000,stroke:#fff,stroke-width:2px,color:#fff;
    classDef exporter fill:#00a3cc,stroke:#fff,stroke-width:2px,color:#fff;
    classDef source fill:#444,stroke:#fff,stroke-width:1px,color:#fff,stroke-dasharray: 5 5;

    subgraph DataSources ["🔍 Data Sources"]
        LogFiles["Logfiles (Journal, Fail2ban, Docker Socket)"]:::source
        HostOS["Host OS (/proc, /sys, rootfs)"]:::source
        DockerEngine["Docker Engine (Containers, cgroups)"]:::source
        ProxmoxAPI["Proxmox VE (API)"]:::source
    end

    subgraph Agents ["🤖 Agents & Exporters"]
        Promtail["Promtail"]:::exporter
        NodeExporter["Node-Exporter"]:::exporter
        cAdvisor["cAdvisor"]:::exporter
        PVEExporter["PVE-Exporter"]:::exporter
    end

    subgraph Databases ["💾 Storage Databases"]
        Loki["Loki (Log-Aggregation)"]:::loki
        Prometheus["Prometheus (Time-Series Metrics)"]:::prometheus
    end

    Grafana["Grafana (Dashboards)"]:::grafana

    LogFiles -.-> Promtail
    Promtail --> Loki
    HostOS -.-> NodeExporter
    DockerEngine -.-> cAdvisor
    ProxmoxAPI -.-> PVEExporter

    Prometheus --> NodeExporter
    Prometheus --> cAdvisor
    Prometheus --> PVEExporter

    Grafana --> Loki
    Grafana --> Prometheus

Under Docker the configuration is mostly a copy-paste job. Only the Proxmox exporter needs manual work, since you have to create an API token with the right permissions in the PVE interface.

Dashboards

At grafana.com/dashboards there's a large selection of community dashboards you can import by ID. My favorites:

Node Exporter Full: everything about the host.
Nginx Web Analytics: who's coming from where?
cAdvisor Exporter: what are my containers eating?
SSH Logs: who is trying to log in via SSH?
CrowdSec Metrics: who's already been kicked out?

Provisioning runs from YAML files, so everything comes back instantly after a fresh install. The details are in my GitHub repo.

First discoveries: hello, botnet

As soon as the first Nginx logs showed up in Grafana, there was a lot more traffic than I expected. A second look showed that most of it came from bots.

I was getting hammered with 404s for paths like /tool.php, /admin-footer.php, or /abc.php. My sites are static HTML built with Astro, so there is nothing here for a PHP exploit to find, but the bots keep trying every second anyway.

Log excerpt (anonymized):
request for /tool.php with HTTP status: 404 from 172.22.0.8 located in IT
request for /jga.php with HTTP status: 404 from 172.22.0.8 located in IT

The fix: Traefik and CrowdSec

I thought Cloudflare's free plan would catch all of this. It doesn't, plenty of these scans still get through. And since Traefik sits behind the Cloudflare proxy, it normally only sees the Cloudflare IP, so a ban would block the proxy itself.

The answer is CrowdSec, the modern successor to fail2ban, plus a Traefik plugin. The label forwardedHeadersCustomName=CF-Connecting-IP tells the CrowdSec plugin to read the real visitor IP from the Cloudflare header.

Here is my docker-compose.yml snippet for the two of them:

version: "3.8"

services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: crowdsec
    restart: unless-stopped
    # Entrypoint handles the bouncer key from secrets
    entrypoint: ["/bin/sh", "-c", "export BOUNCER_KEY_traefik=$(cat /run/secrets/crowdsec_bouncer_key) && exec /docker_start.sh"]
    environment:
      COLLECTIONS: "crowdsecurity/traefik crowdsecurity/http-cve crowdsecurity/base-http-scenarios"
    volumes:
      - crowdsec-config:/etc/crowdsec
      - crowdsec-data:/var/lib/crowdsec/data
      - traefik-access-logs:/var/log/traefik:ro
    networks:
      - apps
      - monitoring_net
    secrets:
      - crowdsec_bouncer_key

  traefik:
    image: traefik:v3.6.6
    container_name: traefik
    restart: unless-stopped
    depends_on:
      - crowdsec
    command:
      - "--accesslog=true"
      - "--accesslog.filepath=/var/log/traefik/access.log"
      - "--experimental.plugins.crowdsec-bouncer.modulename=github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin"
      - "--experimental.plugins.crowdsec-bouncer.version=v1.4.1"
    labels:
      - "traefik.enable=true"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec-bouncer.crowdseclapihost=crowdsec:8080"
      - "traefik.http.middlewares.crowdsec.plugin.crowdsec-bouncer.forwardedHeadersCustomName=CF-Connecting-IP"
    networks:
      - cloudflare
      - apps

The middleware in action

From here I just add the middleware label to every web service (portfolio, blog, and so on). Every request gets checked against the CrowdSec database, and if an IP is flagged as malicious, Traefik blocks it immediately.

blog-astro-web-prd:
  image: nginx:alpine
  labels:
    - "traefik.enable=true"
    - "traefik.http.routers.blog-astro-prd.rule=Host(`www.slashgordon.link`)"
    - "traefik.http.routers.blog-astro-prd.middlewares=crowdsec@docker"

Is it worth the effort?

For me, yes. It's reassuring to open Grafana and watch the banned-IPs count climb while the CPU load of my 35-watt roommate stays flat. The dashboard also makes the effect obvious: as soon as a bot starts scanning my .php paths, it's blocked after a few attempts.

This post was originally published on www.slashgordon.link.

Docker Cleanup and Surgical Data Recovery

Christoph Dieck — Sat, 12 Sep 2026 17:51:02 +0000

Sometimes you just want to clean up a bit and accidentally tear down half the house. That's what happened to me last week with my home lab. I wanted to free up some space on the Lenovo M920q and ran a routine Docker cleanup: delete a few unused images, remove orphaned volumes.

But when I opened my Gitea instance afterward, the page was blank. No repositories, no users, everything reset to factory defaults. All my code was gone.

The fatal error in the compose file

The answer was in my docker-compose.yml, where I had made a bad architectural mistake during setup. My volume mapping looked like this:

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    volumes:
      - /var/lib/docker/volumes/infra_volume/_data/gitea_data:/data

At first glance it looks like a normal path. The problem is that /var/lib/docker/volumes/ is Docker's internal storage. I had reached around Docker and pointed a bind mount straight at the raw data of another volume (infra_volume). Docker didn't see that dependency, so the cleanup job classified the original volume as unused and deleted it.

Surgical recovery from the Proxmox backup

Restoring the entire VM from backup would have taken forever and overwritten the rest of my setup. I only needed one directory out of the backup, so I had to extract the data directly from the Proxmox backup without ever booting the VM.

The backup lay as a compressed file on my storage:

vzdump-qemu-100-2026_02_23-01_00_02.vma.zst

First, I had to remove the compression:

zstd -d vzdump-qemu-100-2026_02_23-01_00_02.vma.zst

Then I extracted the raw VMA archive using Proxmox's own tool into a temporary folder:

vma extract vzdump-qemu-100-2026_02_23-01_00_02.vma /mnt/restore

Now I had a raw image file called tmp-disk-drive-scsi0.raw in front of me. You can't just mount such an image. It contains its own partitions and, in Ubuntu's case, LVM structures. I had to mount the image as a loop device:

losetup -f
losetup /dev/loop0 /mnt/restore/tmp-disk-drive-scsi0.raw
kpartx -av /dev/loop0

With the kpartx command, I made the partitions in the image visible to the host system. Since Ubuntu uses LVM, I had to wake up the volume group inside the backup:

vgscan
vgchange -ay

The system immediately found the volume group ubuntu-vg. Now I could finally mount the partition like a normal disk and navigate to my lost data:

mount -t ext4 /dev/ubuntu-vg/ubuntu-lv /mnt/vm
cd /mnt/vm/var/lib/docker/volumes/infra_volume/_data/gitea_data

There they were again. My repositories and the Gitea database were intact.

The NFS trap and the SQLite repair

Copying the data back brought the next hurdle. My new destination was an NFS share on my Synology NAS. NFS uses root_squash by default, so the root user of the Proxmox server can't push files with full permissions to the share, and a normal copy failed.

The solution was rsync without taking over permissions:

rsync -rlt --no-perms --no-owner --no-group /mnt/vm/var/... /mnt/gitea/

The relief was short-lived. The file gitea.db was corrupted, probably because the backup ran at the exact moment the database was being written to. SQLite has a repair mode for this:

sqlite3 gitea.db ".recover" | sqlite3 gitea_fixed.db

If that aborts, you can force SQLite to ignore errors during import:

sqlite3 gitea.db ".recover" | sqlite3 -init <(echo ".bail off") gitea_fixed.db

Two things I'd do differently next time. I ran .recover directly on the file sitting on the NFS mount, and SQLite's locking doesn't get along well with NFS, so that's a second corruption waiting to happen. The safer order is: copy the file to local disk, check how bad it actually is, repair it there, then rsync the fixed copy back.

sqlite3 gitea.db "PRAGMA integrity_check;"

integrity_check tells you upfront whether you're looking at a handful of misplaced pages or a completely shredded file, before you commit to a recovery pass.

The new setup

After replacing the database and cleanly unmounting everything (umount, vgchange -an, losetup -d), I rebuilt the setup to avoid the mistake.

The new compose file keeps the data on the NAS via a direct mount point instead of a path inside Docker's internal storage. Whatever Docker does on the Lenovo, the data stays on the NAS:

version: "3.9"

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: always
    networks: [cloudflare]
    ports:
      - "3000:3000"
      - "2222:2222"
    volumes:
      - /mnt/gitea:/data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/api/healthz"]
      interval: 30s
      timeout: 5s
      retries: 3

  runner:
    image: gitea/act_runner:latest
    container_name: gitea-runner
    restart: always
    depends_on: [gitea]
    networks: [cloudflare]
    environment:
      GITEA_RUNNER_NAME: CI-Runner
      CONFIG_FILE: /data/config.yaml
      GITEA_INSTANCE_URL: http://gitea:3000
      GITEA_RUNNER_REGISTRATION_TOKEN_FILE: /run/secrets/gitea_runner_token
    volumes:
      - runner_data:/data
      - /var/run/docker.sock:/var/run/docker.sock

networks:
  cloudflare:
    external: true

volumes:
  runner_data:
    external: true

secrets:
  gitea_runner_token:
    file: /data/compose/secrets/gitea/gitea_runner_token

What I took away from it

Never use /var/lib/docker/volumes/ or any of Docker's internal paths as the source for a bind mount. Use --no-perms --no-owner --no-group when rsyncing onto an NFS mount. Learn SQLite's .recover mode before you need it, but run integrity_check first and repair on local disk, not over NFS. Add a healthcheck so the next failure shows up as a failing container instead of an empty page. And a backup is only worth something once you have actually pulled a single directory out of one and put it back.

This post was originally published on www.slashgordon.link.

Recovering a lost RNS 510 radio code with a Python script

Christoph Dieck — Sat, 12 Sep 2026 11:04:50 +0000

I upgraded the stereo in my Volkswagen Tiguan to a newer system, which left the old RNS 510 for sale. Selling it turned out to be less straightforward than I expected.

The roadblock

The RNS 510 has an anti-theft protection code. When I installed it years ago, it came with a small card holding a four-digit PIN, meant to be kept somewhere safe. I put it somewhere so safe that I couldn't find it when I needed it.

On the day of the sale, the buyer, a Volkswagen enthusiast, installed the unit in his car and hit the security code prompt. I had no idea where the card was. Without the code the unit is a brick, and the sale was about to fall through.

Brute-forcing the PIN

Rather than lose the sale, I looked at brute-forcing the PIN. The unit was mine, so I was recovering my own code.

Entering thousands of combinations by hand isn't practical, so I wrote a tool to do it. That became the RNS510 Code Finder.

Building the RNS510 Code Finder

The script is Python and uses pyserial. It connects to the RNS 510 over a serial (COM) port, sends each PIN in a given range, reads the device's response to see whether the PIN was accepted, and logs every attempt. I've since cleaned it up and released it as open source.

How to use it

If you're in the same spot, trying to sell an RNS 510 without the PIN card, here's how to run the RNS510 Code Finder.

1. Clone the repository

First, clone the RNS510 Code Finder repository from GitHub:

git clone https://github.com/SlashGordon/rns510-code-finder.git
cd rns510-code-finder

2. Install pyserial

With Python installed, add the pyserial library:

pip install pyserial

3. Run the script

Connect the RNS 510 to your computer via a serial port and run the script. This example uses COM1; replace it with the correct COM port for your device. You can also adjust --baudrate, --timeout, --start, and --stop:

python rns510_code_finder.py --portname COM1 --baudrate 9600 --timeout 2 --start 0 --stop 1999

The script tests PINs across the range and prints the correct code to the terminal when it hits it.

4. Example output

Running it looks roughly like this:

$ python rns510_code_finder.py --portname COM1 --baudrate 115200 --timeout 1 --start 0 --stop 1999
2023-08-12 14:23:45,123 - INFO - Opened serial port COM1
2023-08-12 14:23:45,124 - INFO - Trying code: 0000
2023-08-12 14:23:45,225 - INFO - Code 0000 is invalid.
...
2023-08-12 14:24:15,567 - INFO - Trying code: 1234
2023-08-12 14:24:15,668 - INFO - Code found: 1234
2023-08-12 14:24:15,669 - INFO - Closed serial port COM1

The code it prints unlocks the RNS 510.

How it went

I connected my PC to the RNS 510, started the script, and watched it work through the PINs. A few minutes later it found the code, and the unit powered up.

I wrote the code down, gave it to the buyer, and the sale went through.

Takeaway

Keep your radio code somewhere you'll find it again. If you've already lost it, the RNS510 Code Finder is on GitHub. Use it only on a device you own.

GitHub Repository: RNS510 Code Finder

License: MIT License - Open for everyone to use, improve, and share.

This post was originally published on www.slashgordon.link.

astro-gallery: four image gallery components for Astro

Christoph Dieck — Mon, 31 Aug 2026 11:42:51 +0000

Every time I write a post with photos in it, I need a gallery. The dog post needed one. The paving post needed three. I kept copying the same Astro component from post to post, tweaking it slightly each time, and the copies slowly drifted apart.

So I did the sensible thing and turned it into a package. It is called astro-gallery, it is on npm, and my blog now runs on it.

What astro-gallery is

astro-gallery is a set of four gallery components for Astro. You point a component at a folder in src/, drop your photos in, and it handles the rest: image optimisation through astro:assets, responsive srcset, a lightbox, EXIF reading at build time, and structured data. No client framework, no config file, one integration.

The four components:

Component	What it does
`JustifiedGallery`	Aspect-ratio-aware rows that fill the width edge to edge. Nothing gets cropped to a grid cell.
`ImageGallery`	A uniform responsive grid. Click a thumbnail, get a lightbox with arrow-key navigation.
`ImageTimeline`	Reads each photo's EXIF capture date, groups by day, lays the days out on a timeline. Horizontal rail or vertical spine.
`MapGallery`	Reads GPS EXIF and drops a photo marker per location on a Leaflet map. Ships a consent gate so no tile request happens before the visitor agrees.

The photos in the examples below are real. A hiking trip in the Harz, a few days on Rügen, and some odds and ends from around Hamburg. All of them live in one folder, src/assets/images/demo/, and every example reads from that same folder.

Setup

Install the package and add the integration.

npm install astro-gallery

// astro.config.mjs
import { defineConfig } from 'astro/config';
import gallery from 'astro-gallery';

export default defineConfig({
  integrations: [
    gallery({
      locale: 'en-GB',
      // pick a basemap for MapGallery. 'osm' is keyless.
      map: { basemap: 'osm' },
    }),
  ],
});

The integration exposes its resolved config to the components through a virtual module. The components will not render without it, so this step is not optional.

Then import a component in any .astro or .mdx file and give it a folder:

---
import JustifiedGallery from 'astro-gallery/components/JustifiedGallery.astro';
---
<JustifiedGallery folderPath="demo" album="Trips 2025 and 2026" />

JustifiedGallery

This is the one I reach for first. Rows are justified to the container width using each photo's aspect ratio, so a landscape shot takes more horizontal space than a portrait, and nothing is cropped to fit a box. It is the layout you know from Flickr, Unsplash and the Lightroom web galleries.

It is built for Core Web Vitals. Every image carries its intrinsic width and height so there is zero layout shift, offscreen rows use content-visibility to skip rendering work, and the first couple of images load eagerly with fetchpriority="high". The rest lazy load. There is a blur-up skeleton while each image decodes.

The alt prop is a map of file name to alt text. You only fill in the ones that matter. For the rest, the component builds an alt string from the file name or from an embedded IPTC caption if the photo has one. More on that below.

ImageGallery

Same photos, uniform grid. Every cell is identical, so each image is cropped with object-fit: cover to fill it. Use this when your photos are roughly the same shape, or when the gallery is really just navigation and you want it tidy.

It also takes an explicit images array if you would rather list imported images, /public paths or remote URLs by hand, with per-image alt and caption. That is the mode the older posts on my blog use.

ImageTimeline

Here is where the EXIF reading earns its keep. ImageTimeline reads DateTimeOriginal from each photo, groups the photos by calendar day, and lays the days out in order. If a day has GPS data it reverse-geocodes a location label for that group, once, at build time. Nothing hits the network in the browser.

Default orientation is a horizontal rail you scroll sideways:

Set orientation="vertical" and the same data stacks down the page on a left-hand spine:

The Rügen days cluster together in August 2025. The Harz days sit in June 2026. You can see the shape of both trips without a caption telling you.

MapGallery

MapGallery reads the GPS coordinates, builds one circular photo marker per location, and puts them on a Leaflet map. Photos without GPS are skipped. If none of the photos have GPS, the component renders nothing.

The important part is the consent gate. Map tiles come from a third-party CDN, and loading them sends the visitor's IP address to that provider. So MapGallery renders an overlay first and loads nothing from the network until the visitor clicks the button. The choice is remembered in localStorage.

Underneath the map, in the HTML, there is a plain list of linked thumbnails with real alt text. Search engines and no-JS visitors get that list. The client script swaps in the interactive map once you accept the gate. Nobody loses the content.

You pick the look with a basemap preset: osm (keyless), carto-dark, carto-light, carto-voyager, stadia-dark or esri-satellite. The CARTO and Stadia presets need a free API key, which you pass as map.tileApiKey. On my blog the key lives in a Gitea secret and the config falls back to plain OpenStreetMap when it is not set.

What you get for free

The reason I bothered to package this properly, rather than keep copy-pasting, is the boring stuff. Every component renders crawlable, accessible markup on the server. The JavaScript only enhances it.

Semantic HTML. Galleries are a <ul> of <figure> elements. Each thumbnail is a real <a href> to the full-size image, so crawlers can follow it. The timeline is a <section> with an <ol> where each day heading is a <time datetime="...">.
Alt text that is not a file name. Resolution order: an explicit value you pass, then an embedded IPTC or XMP caption, then a humanised file name (IMG_4821.JPG is recognised as camera noise and ignored), then "<album> photo N".
Lazy loading without layout shift. Intrinsic width and height on every <img>, plus loading="lazy" and decoding="async". The first image is eager and high priority for LCP.
Responsive images. ImageGallery and JustifiedGallery emit a srcset across a set of widths, never upscaling past the source, with a matching sizes.
Structured data. Each gallery emits one <script type="application/ld+json"> with an ImageGallery whose associatedMedia is a list of ImageObject entries. Relative URLs become absolute when site is set in astro.config.

astro-gallery vs rolling your own

	astro-gallery	Hand-rolled component	A JS lightbox library
Image optimisation	`astro:assets`, built in	You wire up `getImage` yourself	Usually none, you pass URLs
EXIF date and GPS	Built in, build time	You add `exifr` and the plumbing	Out of scope
Consent gate for map tiles	Built in	You build it	Out of scope
Semantic HTML and JSON-LD	Built in	Whatever you remember to add	Depends on the library
Client JS	About 2 kB for the lightbox, Leaflet only on map pages	Your call	The whole library on every page
Config surface	One integration, sensible defaults	Full control, full maintenance	Its own API

Rolling your own is fine. I did it for a year. The problem was never the first copy. It was the fifth copy, slightly different from the other four, with a bug I had already fixed somewhere else.

FAQ

Does it need a client framework like React?
No. The components are .astro files. The only client JavaScript is a small dependency-free lightbox, plus Leaflet on pages that use MapGallery.

Where do the images live?
Anywhere under src/. The default base folder is src/assets/images/, so folderPath="demo" reads from src/assets/images/demo/. ImageGallery also accepts imported images and remote URLs directly.

Does the reverse geocoding call an API on every build?
Only for coordinates it has not seen before. Results are cached to a JSON file that you commit, shared by ImageTimeline and MapGallery. After the first run, builds and CI never touch the network for geocoding.

Can I theme it?
Yes. Everything is namespaced under .asg-* and driven by CSS custom properties. Override the tokens in your own CSS. Light and dark are picked up from prefers-color-scheme.

Which Astro versions work?
Astro 4 and up. My blog runs Astro 7.

Monte Carlo Simulation: How to go broke eight times faster with 8 Eurojackpot lines

Christoph Dieck — Sun, 30 Aug 2026 18:24:35 +0000

Every lottery player knows the saying: "One line is no line, you have to play a few more to boost your chances!" That's why the average player often fills out a complete ticket with 8 lines.

Sounds like a solid strategy, right? Wrong. It’s actually the fastest way to systematically burn through your cash.

To prove it, we wrote a Python simulation that uses historical payout data and cold, hard combinatorics to see who actually has any money left in their account at the end.

What exactly is a Monte Carlo simulation?

Named after the famous casino in Monaco, the Monte Carlo simulation is basically the brute-force approach to probability theory.

Usually, mathematicians use a single, elegant formula to calculate the expected value. That formula will dryly inform you: "You lose an average of 1 Euro per Eurojackpot line." That might be mathematically correct, but emotionally, it's a bit of a snooze. It doesn't capture the true pain of slowly bleeding out financially.

The Monte Carlo simulation throws that elegant formula right out the window. Its core concept is pure, raw computing power. Instead of just calculating the theoretical outcome, we let the computer simply play through reality thousands of times. It’s not an equation; it’s a simulation and iteration of real events.

The computer spawns 1,000 fictional players. For every player and every draw over the last 10 years, it generates a random number based on the actual Eurojackpot probabilities. It simulates the real-world winning and (mostly) losing, step by step. At the end, we aren't looking at some abstract theoretical number, but at the very real, blood-red bank accounts of 1,000 ruined clones.

The Setup

We're using Polars for lightning-fast data processing, NumPy to simulate millions of random draws, and Matplotlib to visualize our financial doom.

First, grab our historical Eurojackpot database and drop it into the same folder.

The Script

Here is the complete Python code. It calculates the exact mathematical odds on the fly using combinatorics (math.comb), links them up with the real average payouts from recent years, and then runs 1,000 players through the brute-force meat grinder.

"""
Eurojackpot Monte Carlo Simulation
===================================
Simulates realistic lottery participation over multiple years
using exact combinatorial probabilities and historical payout data.
"""

from __future__ import annotations

import math
import logging
from dataclasses import dataclass, field
from pathlib import Path
from typing import TYPE_CHECKING

import matplotlib.pyplot as plt
import matplotlib.ticker as ticker
import numpy as np
import polars as pl

if TYPE_CHECKING:
    pass

# ---------------------------------------------------------------------------
# Logging
# ---------------------------------------------------------------------------
logging.basicConfig(level=logging.INFO, format="%(message)s")
log = logging.getLogger(__name__)


# ---------------------------------------------------------------------------
# Constants
# ---------------------------------------------------------------------------
MAIN_POOL = 50
MAIN_PICK = 5
EURO_POOL = 12
EURO_PICK = 2
TICKET_COST = 2.0
DRAWS_PER_YEAR = 104  # 2× per week

PRIZE_TIERS: dict[str, tuple[int, int]] = {
    "5 + 2": (5, 2), "5 + 1": (5, 1), "5 + 0": (5, 0),
    "4 + 2": (4, 2), "4 + 1": (4, 1), "4 + 0": (4, 0),
    "3 + 2": (3, 2), "2 + 2": (2, 2), "3 + 1": (3, 1),
    "3 + 0": (3, 0), "1 + 2": (1, 2), "2 + 1": (2, 1),
}


# ---------------------------------------------------------------------------
# Config dataclass
# ---------------------------------------------------------------------------
@dataclass
class SimConfig:
    players: int = 1_000
    years: int = 10
    fields_per_draw: int = 8
    output_dir: Path = field(default_factory=lambda: Path("."))

    @property
    def total_draws(self) -> int:
        return self.years * DRAWS_PER_YEAR

    @property
    def cost_per_draw(self) -> float:
        return self.fields_per_draw * TICKET_COST

    @property
    def total_spent(self) -> float:
        return self.total_draws * self.cost_per_draw


# ---------------------------------------------------------------------------
# Probability calculation
# ---------------------------------------------------------------------------
def calculate_exact_probabilities() -> dict[str, float]:
    """Exact Eurojackpot winning probabilities via combinatorics."""
    total_main = math.comb(MAIN_POOL, MAIN_PICK)
    total_euro = math.comb(EURO_POOL, EURO_PICK)

    probabilities: dict[str, float] = {}
    prob_sum = 0.0

    for tier, (match_m, match_e) in PRIZE_TIERS.items():
        ways_main = math.comb(MAIN_PICK, match_m) * math.comb(
            MAIN_POOL - MAIN_PICK, MAIN_PICK - match_m
        )
        ways_euro = math.comb(EURO_PICK, match_e) * math.comb(
            EURO_POOL - EURO_PICK, EURO_PICK - match_e
        )
        prob = (ways_main / total_main) * (ways_euro / total_euro)
        probabilities[tier] = prob
        prob_sum += prob

    probabilities["No Win"] = 1.0 - prob_sum
    return probabilities


# ---------------------------------------------------------------------------
# Data loading
# ---------------------------------------------------------------------------
def load_empirical_payouts(
    file_path: str | Path,
    probabilities: dict[str, float],
) -> tuple[np.ndarray, np.ndarray]:
    """Load historical payout data and align with probability tiers."""
    log.info("[1/3] Loading historical payouts…")

    df = pl.read_json(str(file_path))
    payouts_df = df.select(pl.col("prizeDistribution")).unnest("prizeDistribution")
    avg_payouts: dict[str, float] = payouts_df.mean().to_dicts()[0]

    tiers = list(probabilities.keys())
    payouts = np.array(
        [0.0 if t == "No Win" else float(avg_payouts.get(t) or 0.0) for t in tiers],
        dtype=np.float64,
    )
    probs = np.fromiter(
        (probabilities[t] for t in tiers), dtype=np.float64, count=len(tiers)
    )
    probs /= probs.sum()  # normalise to guard against floating-point drift

    return payouts, probs


# ---------------------------------------------------------------------------
# Monte Carlo simulation
# ---------------------------------------------------------------------------
def run_monte_carlo(
    payouts: np.ndarray,
    probs: np.ndarray,
    cfg: SimConfig,
    *,
    seed: int | None = None,
) -> pl.DataFrame:
    """
    Vectorised Monte Carlo simulation.

    Memory layout: (total_draws, players, fields_per_draw)
    All draws are sampled in a single call for maximum throughput.
    """
    rng = np.random.default_rng(seed)

    log.info("[2/3] Simulating %d players over %d draws…", cfg.players, cfg.total_draws)
    log.info(
        "      Fields/draw: %d  |  Cost/draw: €%.2f  |  Total per player: €%.2f",
        cfg.fields_per_draw, cfg.cost_per_draw, cfg.total_spent,
    )

    # --- sample outcomes for every (draw, player, field) triple at once ---
    outcome_indices = rng.choice(
        len(payouts),
        size=(cfg.total_draws, cfg.players, cfg.fields_per_draw),
        p=probs,
    )
    raw_winnings: np.ndarray = payouts[outcome_indices]

    # sum over fields, subtract per-draw cost, cumsum over time
    net_per_draw = raw_winnings.sum(axis=2) - cfg.cost_per_draw  # (draws, players)
    bankroll = np.cumsum(net_per_draw, axis=0)                   # (draws, players)

    return pl.DataFrame(
        bankroll,
        schema=[f"Player_{i}" for i in range(cfg.players)],
    )


# ---------------------------------------------------------------------------
# Visualisation helpers
# ---------------------------------------------------------------------------
_PALETTE = {
    "jackpot":   "#00E5FF",
    "major":     "#FFD700",
    "minor":     "#FF9800",
    "profit":    "#00ff88",
    "loss":      "#ff4d4d",
    "worst":     "#ffffff",
    "breakeven": "#00bfff",
    "bg_fig":    "#0f1117",
    "bg_ax":     "#111827",
    "bg_legend": "#1f2937",
    "bg_text":   "#1f2937",
    "edge_text": "#ff4d4d",
}


def _profit_color(balance: float) -> str:
    if balance >= 1_000_000:
        return _PALETTE["jackpot"]
    if balance >= 100_000:
        return _PALETTE["major"]
    if balance >= 10_000:
        return _PALETTE["minor"]
    if balance > 0:
        return _PALETTE["profit"]
    return _PALETTE["loss"]


def _apply_dark_style(fig: plt.Figure, ax: plt.Axes) -> None:
    fig.patch.set_facecolor(_PALETTE["bg_fig"])
    ax.set_facecolor(_PALETTE["bg_ax"])


def _add_stats_box(
    ax: plt.Axes,
    avg: float,
    winners: int,
    players: int,
    fields: int,
) -> None:
    ax.text(
        0.02, 0.04,
        f"Stake per draw: €{fields * TICKET_COST:.2f}\n"
        f"Average result: €{avg:,.0f}\n"
        f"Profitable players: {winners}/{players}",
        transform=ax.transAxes,
        fontsize=12,
        bbox=dict(
            boxstyle="round,pad=0.6",
            facecolor=_PALETTE["bg_text"],
            edgecolor=_PALETTE["edge_text"],
            alpha=0.9,
        ),
    )


def _euro_formatter(x: float, _pos: int) -> str:
    return f"€ {int(x):,}"


# ---------------------------------------------------------------------------
# Plot generation
# ---------------------------------------------------------------------------
def analyze_and_plot(df: pl.DataFrame, cfg: SimConfig) -> None:
    """Generate log-scale (illusion) and linear-scale (reality) charts."""
    log.info("[3/3] Creating visualisations…")

    players = len(df.columns)
    final_balances = np.array(df.row(-1))

    avg_balance   = float(final_balances.mean())
    best_balance  = float(final_balances.max())
    worst_balance = float(final_balances.min())
    best_idx  = int(final_balances.argmax())
    worst_idx = int(final_balances.argmin())

    best_col  = df.columns[best_idx]
    worst_col = df.columns[worst_idx]

    winners_mask = final_balances > 0
    winners_count = int(winners_mask.sum())

    winner_cols = [df.columns[i] for i, w in enumerate(winners_mask) if w and df.columns[i] != best_col]
    loser_cols  = [df.columns[i] for i, w in enumerate(winners_mask) if not w]

    # cap losers shown to 500 for readability
    sample_losers = loser_cols[:500]

    plt.style.use("dark_background")

    chart_configs: list[tuple[str, str, bool, float | None]] = [
        (
            "eurojackpot_1_illusion_log.png",
            f"The Illusion: {cfg.years} Years Eurojackpot ({cfg.fields_per_draw} Fields)",
            True, None,
        ),
        (
            "eurojackpot_2_reality_linear.png",
            f"The Reality: {cfg.years} Years Eurojackpot ({cfg.fields_per_draw} Fields)",
            False, 5_000.0,
        ),
    ]

    for filename, title, use_log, ylim_max in chart_configs:
        fig, ax = plt.subplots(figsize=(12, 7))
        _apply_dark_style(fig, ax)

        # losers (faint red)
        for col in sample_losers:
            ax.plot(df[col].to_numpy(), color=_PALETTE["loss"],
                    alpha=0.15, linewidth=0.5, zorder=1)

        # non-best winners
        for col in winner_cols:
            series = df[col].to_numpy()
            ax.plot(series, color=_profit_color(series[-1]),
                    alpha=0.7, linewidth=0.8, zorder=3)

        # best & worst highlighted
        ax.plot(
            df[best_col].to_numpy(),
            color=_profit_color(best_balance),
            linewidth=1.5,
            label=f"Best: €{best_balance:,.0f}",
            zorder=6,
        )
        ax.plot(
            df[worst_col].to_numpy(),
            color=_PALETTE["worst"],
            linestyle="--",
            linewidth=1.5,
            label=f"Worst: €{worst_balance:,.0f}",
            zorder=6,
        )

        ax.axhline(0, color=_PALETTE["breakeven"], linestyle=":",
                   linewidth=1.5, label="Breakeven (€0)")

        if use_log:
            ax.set_yscale("symlog", linthresh=1_000)
            ax.set_ylabel("Net Bankroll (Log Scale)")
        else:
            ax.set_ylim(worst_balance - 500, ylim_max)
            ax.set_ylabel("Net Bankroll (Linear Scale)")

        ax.set_title(title, fontsize=18, fontweight="bold")
        ax.set_xlabel("Number of Draws (Tuesday & Friday)")
        ax.grid(True, axis="y", linestyle="--", alpha=0.15)
        ax.yaxis.set_major_formatter(ticker.FuncFormatter(_euro_formatter))

        legend = ax.legend(loc="upper right", fontsize=11)
        legend.get_frame().set_facecolor(_PALETTE["bg_legend"])
        legend.get_frame().set_edgecolor("#374151")

        _add_stats_box(ax, avg_balance, winners_count, players, cfg.fields_per_draw)

        plt.tight_layout()
        out_path = cfg.output_dir / filename
        fig.savefig(out_path, dpi=300, bbox_inches="tight")
        plt.close(fig)
        log.info("[+] Saved: %s", out_path)

    log.info("\nAll charts generated successfully.")


# ---------------------------------------------------------------------------
# Entry point
# ---------------------------------------------------------------------------
def main() -> None:
    data_file = Path("eurojackpot-history.json")

    if not data_file.exists():
        log.error("Error: '%s' not found.", data_file)
        return

    cfg = SimConfig(players=10_000, years=10, fields_per_draw=8)

    probabilities      = calculate_exact_probabilities()
    payouts, probs     = load_empirical_payouts(data_file, probabilities)
    df_simulation      = run_monte_carlo(payouts, probs, cfg, seed=42)
    analyze_and_plot(df_simulation, cfg)


if __name__ == "__main__":
    main()

The Result

When you run the script, something visually striking happens. Thanks to the symlog scaling on the Y-axis, we get to see both: the brutal, steady losses of the general public and the absurd outliers of the extreme winners, all without breaking the chart.

The hard truth in numbers:
At 8 lines per draw, you will burn through roughly €11,500 in 10 years. The simulation shows it clearly: even if you hit 3 correct numbers now and then, it won't save you from the statistical expected value. The red cloud inevitably drags every player into the negative. Most of the time, not a single one of the 1,000 simulated players finishes the decade in the green.

Think you're that green outlier on the chart? Test your own 8 lucky lines in our Eurojackpot Simulator and click your way into bankruptcy!

10 Years of Eurojackpot Data with Polars

Christoph Dieck — Sat, 29 Aug 2026 17:57:24 +0000

Welcome to the intersection of high-performance data engineering and terrible financial decisions.

In this post, we are going to do what every hopeful gambler eventually tries: analyze historical lottery data to find the "secret pattern." To do this, we will use Python's Polars library—because if we are going to calculate our inevitable financial ruin, we might as well do it with blazing fast, multi-threaded performance.

Spoiler alert: the data won't help you win. But it is a fantastic exercise in data manipulation, nested JSON parsing, and visualization. Let's dive in.

Step 1: Setup Your Development Environment

To follow along, you will need a Python environment with Polars (for data crunching) and Matplotlib (to draw pretty charts of our losses). Run this in your terminal:

mkdir eurojackpot-analysis
cd eurojackpot-analysis
python -m venv .venv
source .venv/bin/activate
pip install polars matplotlib

Step 2: Loading the Eurojackpot Draw History

We provide a massive, free dataset of all Eurojackpot draws over the last 10+ years right here on the site. Let's grab it:

wget https://www.howtolosemoneyfast.com/downloads/eurojackpot-history.json

Step 3: The "Reality Check" Script

Here is the complete Python script. It uses Polars' powerful .explode() method to untangle the nested arrays of winning numbers, and .unnest() to flatten the prize distribution data.

import polars as pl
import matplotlib.pyplot as plt
from pathlib import Path
from typing import Union

def load_lottery_data(file_path: Union[str, Path]) -> pl.DataFrame:
    """Loads historical lottery data from a JSON file."""
    path = Path(file_path)
    if not path.exists():
        raise FileNotFoundError(f"Dataset not found at: {path}")
    return pl.read_json(path)

def calculate_number_frequencies(df: pl.DataFrame, column_name: str, top_n: int = 10) -> pl.DataFrame:
    """Calculates the frequency of drawn numbers."""
    return (
        df.select(pl.col(column_name).explode())
        .group_by(column_name)
        .agg(pl.len().alias("frequency"))
        .sort("frequency", descending=True)
        .head(top_n)
    )

def analyze_payout_distribution(df: pl.DataFrame) -> pl.DataFrame:
    """Calculates summary statistics for minor prize tiers."""
    payouts_df = df.select(
        pl.col("date"), 
        pl.col("prizeDistribution")
    ).unnest("prizeDistribution")

    summary_stats = payouts_df.select([
        pl.col("2 + 1").drop_nulls().mean().round(2).alias("2 Main + 1 Euro"),
        pl.col("3 + 0").drop_nulls().mean().round(2).alias("3 Main + 0 Euro"),
        pl.col("3 + 1").drop_nulls().mean().round(2).alias("3 Main + 1 Euro")
    ])
    return summary_stats

def plot_reality_check(top_main: pl.DataFrame, payout_stats: pl.DataFrame):
    """Generates a professional dual-plot visualization."""

    # Set up a professional plotting style
    plt.style.use('ggplot')
    fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(14, 6))
    fig.suptitle("Eurojackpot Historical Analysis: The Illusion of Strategy", fontsize=16, fontweight='bold')

    # --- Plot 1: "Hot" Numbers ---
    # Convert Polars columns to lists for Matplotlib
    numbers = [str(n) for n in top_main["mainNumbers"].to_list()]
    frequencies = top_main["frequency"].to_list()

    ax1.bar(numbers, frequencies, color='#2c3e50', edgecolor='black')
    ax1.set_title("Top 10 Most Frequent Main Numbers", fontsize=12)
    ax1.set_xlabel("Lottery Number")
    ax1.set_ylabel("Times Drawn")

    # Add a cynical watermark/text box
    ax1.text(0.05, 0.95, "Past performance does not\nindicate future results.", 
             transform=ax1.transAxes, fontsize=10, verticalalignment='top', 
             bbox=dict(boxstyle='round', facecolor='white', alpha=0.8))

    # --- Plot 2: Payout Reality ---
    # Extract column names and their single row values
    tiers = payout_stats.columns
    avg_payouts = payout_stats.row(0)

    ax2.bar(tiers, avg_payouts, color='#e74c3c', edgecolor='black')
    ax2.set_title("Average Payouts for Common 'Wins'", fontsize=12)
    ax2.set_xlabel("Matching Tiers")
    ax2.set_ylabel("Average Payout (€)")

    # Add exact values on top of the bars
    for i, v in enumerate(avg_payouts):
        ax2.text(i, v + 0.5, f"€{v:.2f}", ha='center', fontweight='bold')

    plt.tight_layout()

    # Save the plot so you can upload it straight to your blog
    output_filename = "eurojackpot_reality_check.png"
    plt.savefig(output_filename, dpi=300)
    print(f"\n[+] Chart successfully generated and saved as '{output_filename}'")

    # Show the plot window
    plt.show()

def main():
    pl.Config.set_tbl_formatting("ASCII_MARKDOWN")
    pl.Config.set_tbl_hide_column_data_types(True)

    file_path = "eurojackpot-history.json"

    try:
        print("Initializing Eurojackpot Historical Analysis...\n")
        df = load_lottery_data(file_path)

        # Get top 10 for a better looking chart
        top_main = calculate_number_frequencies(df, "mainNumbers", top_n=10)
        payout_stats = analyze_payout_distribution(df)

        # Generate the visualization
        plot_reality_check(top_main, payout_stats)

    except Exception as e:
        print(f"Analysis failed: {e}")

if __name__ == "__main__":
    main()

The Results

When you run this script, Matplotlib generates the following reality check:

The takeaway: Even if you successfully pick the "hottest" historical numbers, and you manage to match 3 Main numbers and 1 Euro number... congratulations. You've statistically won enough to buy a nice pizza.

Want to see the math in action without writing any code? Try running 1,000 lifetimes of tickets through our live Eurojackpot Simulator and watch your virtual bank account drain in real-time.

Middle-earth and the Digital Infarction

Christoph Dieck — Fri, 21 Aug 2026 09:15:16 +0000

It was supposed to be a relaxed evening. I had finally convinced my girlfriend to watch the Lord of the Rings Extended Edition with me. The mood was good, the elves were marching into Helm's Deep. But right around 10 PM, everything went dark.

The entire LAN was dead. No streaming on the TV and no internet on the PC. The strange thing was that the Wi-Fi on my Fritzbox 7690 was still working perfectly. Only everything connected via cable was completely knocked out.

The Suspect in the Server Closet

Since I had just recently put the Lenovo M920q into service, it was naturally my prime suspect. My first assumption was a misconfigured Docker container. I thought about problems with macvlan or a container in Network Host Mode that might be causing a loop.

I disabled a suspicious container and had two days of peace. I thought the problem was solved. But then it happened again: right in the middle of the movie, the LAN was gone. Only when I pulled the network cable from the Lenovo did the entire network calm down immediately.

Hunting Through the Kernel Logs

I SSHed into the Proxmox host and searched through the logs:

dmesg -T | grep -i e1000e

There I found error messages appearing every second:

e1000e 0000:00:1f.6 nic0: Detected Hardware Unit Hang
TDH                  <52>
TDT                  <73>
next_to_use          <73>
next_to_clean        <52>

Technically, this is a problem with the ring buffers of the network card. Think of it like a conveyor belt. The system puts packets on the back (TDT - Transmit Descriptor Tail) and the card sends them off the front (TDH - Transmit Descriptor Head).

In my case, the logs showed:

TDH (Head): 52
TDT (Tail): 73

This means the system is queueing packets, but the hardware isn't processing them on the front end. The network card is simply frozen internally. Because the server is connected to the LAN via a bridge, this hang clogs up the entire Fritzbox switch port and takes down the rest of the wired network with it.

Why Does This Happen?

The culprit is a feature called EEE (Energy Efficient Ethernet), also known as IEEE 802.3az. The Intel i219-LM card tries to save power when there's little activity. But in combination with virtualization under Proxmox, it sometimes doesn't wake up properly. This leads to timing problems and ends in a Hardware Unit Hang.

The Solution

I applied three steps to get the Lenovo stable again:

1. Adjust Driver Options

In /etc/modprobe.d/e1000e.conf I added the following line:

options e1000e InterruptThrottleRate=0,0,0 EEE=0

This disables Energy Efficient Ethernet and interrupt throttling at the driver level.

2. Disable Offloading

So-called offloading refers to functions where the card takes work off the CPU (TSO, GSO, GRO). That sounds good in theory, but often leads to problems:

ethtool -K nic0 tso off gso off gro off

3. Create a Systemd Service

To make these settings persist after every reboot, I created a systemd service:

/etc/systemd/system/nic-stable.service:

[Unit]
Description=Disable NIC offloading and EEE for stability
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -K nic0 tso off gso off gro off
ExecStart=/usr/sbin/ethtool -s nic0 eee off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Then activated it:

systemctl daemon-reload
systemctl enable nic-stable.service
systemctl start nic-stable.service

And an initramfs update to load the modprobe config:

update-initramfs -u

The Rescue Mission Conclusion

It wasn't a bug in Proxmox or the Fritzbox. It was simply the hardware losing the thread while trying to save power. By the way, the Fritzbox doesn't see any of this because the problem happens at Layer 2 the network card just hangs before any IP packets can even be sent.

Since these adjustments, the system has been running without a single dropout. We were finally able to finish Lord of the Rings without interruption. If your LAN ever goes down for no apparent reason, take a look at your server's kernel logs:

dmesg -T | tail -100

Often it's just a network card that slept a little too deeply. 🛌💤

I Built a Chimney Calculator Because I Wanted a Wood Stove

Christoph Dieck — Fri, 21 Aug 2026 07:17:45 +0000

The origin story

Early this year I decided to get a wood-burning stove for the house. Sounded simple. Pick a nice one, call the chimney sweep, done. Wrong.

The first question the sweep asked: "Which flue are you connecting to?" My house has a secondary shaft. Rectangular cross-section, not the standard 150mm round. It was originally just a ventilation shaft. Never designed for a combustion appliance. The sweep told me I needed a cross-section calculation according to DIN EN 13384-1 to prove the combination would even work. Pressure balance. Temperature at the outlet. Condensation risk. The whole program.

I looked at the math and got hooked. Not because it's pretty. It's not. It's pressure drops through friction, buoyancy from density differences between hot flue gas and cold ambient air, exponential temperature decay along insulated pipes, and dew point calculations that decide whether your chimney liner will dissolve in acid over time.

I wanted to understand it. So I built a tool that does it.

What DruckZugPro does

druckzug.pro is a free chimney cross-section pre-check tool based on DIN EN 13384-1. You enter your stove's exhaust data and your chimney geometry. The tool runs the three core verification checks and tells you if the combination is feasible.

This is not a certified calculation. You still need a professional for that. But it gives you a solid first answer before you spend money on a consultation that might end with "nope, doesn't work."

Three checks run simultaneously:

Pressure balance — Is the natural draft strong enough to overcome all friction and pressure losses?
Temperature check — Is the gas temperature at the chimney outlet still above the dew point? (If not: condensation, acid, masonry damage.)
Cross-section adequacy — Is the flue diameter large enough for the gas velocity to stay below critical limits?

Pass all three and you have a good basis for the real calculation. Fail one and the tool tells you what's wrong and what you could change.

The physics that makes it interesting

The core is a thermodynamic model. Flue gas enters the connecting pipe hot and cools exponentially as it travels upward. The cooling rate depends on the pipe material, insulation, diameter, ambient temperature, and mass flow rate.

The available draft comes from buoyancy. Hot gas is less dense than cold ambient air. The density difference over the effective chimney height creates a pressure differential. That's your engine.

Working against it: friction along the pipe walls, losses at bends and transitions, the outlet loss at the chimney top, and the operating pressure the stove itself needs.

The temperature check is where it gets serious for the building. If the flue gas cools below its dew point before leaving the chimney, water and sulfuric acid condense on the inner walls. Over years, that destroys masonry. The tool computes the outlet temperature using the worst-case outdoor temperature and compares it against the fuel-specific dew point.

Chimney visualization. An SVG diagram that renders your chimney geometry to scale. Height, diameter, connecting pipe, top adapter. Updates reactively when you change parameters.

Features beyond the core check

Appliance database. Over a hundred stove models with their official technical data (exhaust temperature, mass flow, CO2 content, fuel type). Select your model and the form auto-fills. Data sourced from manufacturer specifications and the HKI registry.

Compatible appliances finder. Flip the question. Instead of "does my stove fit my chimney?" ask "which stoves fit my chimney?" The tool runs a simplified DIN check against every appliance in the database and shows you which ones pass.

Parameter tuner. After the initial calculation, interactive sliders let you tweak chimney height, diameter, pipe length, and cross-section shape. Results update live. You can see exactly where the margins break or improve. Failing parameters get highlighted in red.

Weather resilience chart. Sweeps the calculation across a range of outdoor temperatures (from -20 to +35) and plots the pressure margin and temperature margin as curves. Shows you at which ambient temperature your chimney setup starts failing. Useful for understanding edge-case behavior in extreme cold.

PDF export. Generates a multi-page A4 report with all configuration data and calculation results. Uses pdfme for client-side generation. No server round-trip.

Calculation appendix. Shows the full intermediate values and formulas used. Every number is traceable. Molar mass, density, specific heat, thermal conductance, cooling factor, friction coefficient. If you want to verify the math by hand, everything is there.

The tech stack

Astro for static site generation. German and English with localized routes.
TypeScript for all DIN 13384-1 calculation logic. Pure functions, no DOM, fully testable.
Nanostores for reactive state. The config store triggers recalculation and UI updates.
Chart.js for pressure balance, temperature profile, weather resilience, and flow visualizations.
KaTeX for rendering mathematical formulas in the calculation appendix.
pdfme for client-side PDF report generation.
Ajv with JSON Schema for configuration validation.
Tailwind CSS for styling.
Vitest with fast-check for property-based testing on the thermodynamics module.

Everything runs in the browser. No backend. No accounts. Projects are saved in localStorage.

The architecture that made it clean

The DIN 13384 calculation is a pure function. ChimneyConfig goes in, CalculationResult comes out. No side effects. No store access. No DOM.

The pipeline runs in stages:

Validate input (structural and physical constraints)
Compute flue gas properties (density, specific heat, molar mass)
Compute pressure losses through the connecting pipe (friction + single-point losses at bends)
Compute pressure losses through the chimney (friction + transition + outlet loss)
Compute available draft (buoyancy from density differential over height)
Run the three verification checks
Generate recommendations if anything fails

The recommendation engine is the part I'm most pleased with. When the pressure check fails, it binary-searches for the minimum chimney height that would pass. When the cross-section fails, it iterates through standard diameters and recommends the smallest one that works. Actionable output instead of just "fail."

What I learned

DIN EN 13384-1 is surprisingly elegant once you strip away the bureaucratic language. It's basically Newton's cooling law combined with the hydrostatic pressure formula and pipe friction factors. Three equations that interact. The difficulty is not in any single formula. It's in getting all the constants right (thermal transmittance per wall type, friction coefficients per material, outlet loss coefficients per termination type) and handling the edge cases cleanly.

The hardest part was testing. The standard doesn't include reference calculations you can verify against. I had to cross-check results against commercial software outputs from a chimney sweep I know and manually verify intermediate values against textbook examples.

Try it

druckzug.pro — Enter your stove and chimney data, get instant results.
Compatible appliances — Find which stoves work with your existing chimney.

Free. No login. No tracking. If you're planning a stove installation and want a sanity check before calling the sweep, this saves you the guesswork.

The Cloud in a Cabinet

Christoph Dieck — Wed, 19 Aug 2026 13:36:30 +0000

In Part 1 I covered the hardware: how the Lenovo M920q replaced my overwhelmed Synology as a compute node. The hardware is in place, Proxmox is humming. Now for the real question: how do the services reach the internet without turning the router into Swiss cheese?

Infrastructure as Code: Everything in Git

Clicking containers together by hand is not for me. If I break something, I want to rebuild it with a single command. My setup: a Git repository with one YAML file per service.

Instead of dumping everything into one giant docker-compose.yml, I built my services as modular Portainer stacks:

gitea.yml My private code home, including a Gitea Runner for CI/CD.
jellyfin.yml Media streaming for after work. Movies live on the Synology, streaming runs on the M920q. For this to work, the NAS media volume needs to be mounted on the Docker host via NFS or SMB. In my case, a simple entry in /etc/fstab:

  //192.168.1.x/media /mnt/nas-media cifs credentials=/etc/nas-credentials,uid=1000,gid=1000 0 0

Jellyfin then accesses /mnt/nas-media through a bind mount.

vaultwarden.yml Password manager for all devices. More on this below.
web.yml Traefik as reverse proxy for my websites (blog, portfolio, howtolosemoneyfast etc.).
tunnel.yml The Cloudflare Tunnel that ties everything together.

New service? Create a YAML file, deploy it as a stack in Portainer, done. Everything broken? git pull, redeploy the stacks, back online.

Cloudflare Tunnels: No Open Ports, Still Reachable

The old way: open ports 80 and 443 on the router, set up DynDNS, and hope nobody rattles the front door. Today that is no longer necessary.

The Cloudflare Tunnel (cloudflared) establishes an encrypted connection from the inside out to Cloudflare. No inbound port needs to be opened. Cloudflare handles TLS termination, DDoS protection, and DNS.

Two things that make this especially valuable for my setup:

No port forwarding. My router stays completely locked down. Port scanners hit nothing.
Zero Trust via Cloudflare Access. Before anyone sees the login page of Jellyfin or Gitea, they must pass an email verification. Only approved email addresses get through.
One subdomain per service. In the Cloudflare dashboard you create a subdomain for each service and point it to the internal port. For example jellyfin.example.com → http://jellyfin:8096, git.example.com → http://gitea:3000. Each subdomain gets its own access rules. This keeps everything cleanly separated and lets you control who can reach each service individually.

The Architecture

Here is the path from the browser to each service:

The cloudflared container connects to Cloudflare automatically on startup. All services sit on the same Docker network as cloudflared and are reachable directly. Only the static websites (blog, portfolio) have Traefik in front as a reverse proxy, because multiple domains need to be routed to different Nginx containers. The Synology remains a pure storage node: movies and backups.

Important: local traffic should not go through the Cloudflare Tunnel. When the TV in the living room streams a movie, it makes no sense to send the data to Cloudflare and back into your own network. That costs latency and bandwidth. Instead, TV and notebook connect directly to Jellyfin via IP (port 8096). The tunnel is only for access from outside.

Vaultwarden Instead of KeePass + Google Drive

My previous setup: a KeePass database on Google Drive, the same .kdbx on every device. Works fine until you change a password on the laptop while the phone still has the old version open. Save, sync conflict, two files. Then you get to merge by hand and hope nothing is lost. That happened often enough that I got tired of it.

Vaultwarden is a Rust reimplementation of the Bitwarden server API. The trick: you use the official Bitwarden clients and browser extensions, point the server URL to your own domain, and log in. The clients cannot tell the difference from hosted Bitwarden, but the data stays with me.

Sync works across all devices, autofill in browsers and on mobile just works, and sharing passwords with the family is handled through organizations. The container uses less than 100 MB of RAM.

For me this was the service that justified the whole homelab effort the fastest. No more Google Drive in the chain, no more broken .kdbx files.

Deployment via Shared Volumes

One detail I am quite happy with: how the websites go from git push to live without any file copying or rsync.

The Gitea Runner has access to specific Docker volumes listed as valid_volumes in its config, for example blog-astro-content-prd or howtolosemoney-content-prd. When a CI pipeline runs, the runner builds the static site and writes the output directly into the matching volume. The Nginx containers in web.yml mount exactly these volumes as read-only:

# web.yml (excerpt)
blog-astro-web-prd:
  image: nginx:alpine
  volumes:
    - blog-astro-content-prd:/usr/share/nginx/html:ro

# gitea.yml (runner config excerpt)
container:
  valid_volumes:
    - "blog-astro-content-prd"
    - "howtolosemoney-content-prd"
    - "portfoliomanager-content-prd"

Git push, runner builds, result lands in the volume, Nginx serves it. No SCP, no webhook, no second deploy step. The Nginx containers do not even notice anything changed because they just read from the filesystem.

FritzBox, IP Changes and the Bypass Rule

Cloudflare Access protects my services with email verification. But from my own network I do not want to go through that every time. For that there is a Zero Trust bypass policy that allows my public IP through. Problem: the FritzBox gets a new IP on every forced reconnect.

The solution is a webhook. In the FritzBox under "Internet > Permits > DynDNS" there is an update URL pointing to my nas-manager-hooks container. When the IP changes, the FritzBox calls the webhook which triggers a Python script that:

Fetches the current IPv4 and IPv6 via external services (ipify, ident.me)
Calculates the /64 network from the IPv6 address
Updates the Cloudflare Zero Trust bypass policy via API with the new IPs

Why fetch externally? The FritzBox passes the IPv4 in the DynDNS callback but no IPv6 address. So the script fetches IPv6 itself via api6.ipify.org with v6.ident.me as fallback. If the lookup fails it retries up to five times with exponential backoff.

The result: IP changes, FritzBox reports in, script runs, bypass policy is up to date. No cron job, no polling.

Real-World Performance CPU usage during that: rarely above 30%. Thanks to the fiber connection, my friends cannot tell whether the server lives in my cabinet or in a data center.

Some numbers from daily operation:

Metric	Value
RAM usage (all containers)	~8 GB
Idle power consumption	~10 W
Power consumption under load	~35 W
Active Docker containers	9

What's Next in Part 3?

Mysterious network outages, always right when a movie should be playing in the evening? In Part 3 I dig into the network logs to find out whether the M920q is really a good roommate or if it is secretly killing the Wi-Fi.

Building a Home Lab with a Lenovo ThinkCentre M920q

Christoph Dieck — Tue, 18 Aug 2026 08:14:25 +0000

It all started innocently enough. A little Jellyfin for the movie collection here, a small Gitea instance for my code there. My Synology DS223 handled the job without complaint. But once you get a taste for automating your own software pipeline, you quickly end up wanting a CI runner. And that is exactly where things went sideways.

When memory runs out

One runner here, one build process there, and suddenly my NAS was telling me we had a massive memory problem. 2 GB of RAM is no luxury resort for containers. It is more like a studio apartment with a shared kitchen. As soon as the Gitea Runner kicked off a build, the system started gasping for air. The OOM killer came knocking.

The conclusion was obvious: I need a real server. But without solar panels on the roof, the usual second-hand server monsters with their 200-watt power supplies were out of the question.

My requirements:

Enough CPU and RAM for Docker containers, CI/CD runners, and media streaming
35 watts max under load (electricity is not free)
Under 400 euros all-in, including upgrades
Compact enough to fit next to the NAS in the server cabinet

Big power, tiny box

After nights of browsing r/homelab and various forums, I landed on the quiet favorite of the home lab community: the Lenovo ThinkCentre M920q. An off-lease unit for 160 euros. Barely larger than a box of chocolates, but it has everything:

A real PCIe slot (for future 10GbE adventures)
Two RAM slots (up to 64 GB DDR4)
An M.2 slot for NVMe storage
An Intel Core i5-8500T with six cores that quietly get the job done

The shopping list

Component	Cost
Lenovo M920q (Refurbished)	160 EUR
32 GB RAM (2x16 GB DDR4)	100 EUR
1 TB NVMe SSD (WD SN770)	100 EUR
Original 8 GB RAM (sold on eBay)	-29 EUR
Original 256 GB SSD (sold on eBay)	-26 EUR
Total (net)	305 EUR

Selling the original components on eBay brought the total down to about 305 euros. For that money you get a machine that delivers more performance per watt than many a tower server. And it is quieter than the cooler box sitting next to it.

The foundation: Proxmox, Docker, Portainer

I went with Proxmox VE as the hypervisor. First order of business after installation: an Ubuntu Server VM with Docker and Portainer as the container management UI.

I immediately made a rookie mistake: I installed the Portainer Community Edition. Only after some digging did I find out that as a private user you can use the Business Edition completely free for up to three nodes. The BE offers access control, Git-based stack deployments, and automatic updates. All features you learn to appreciate as your setup grows.

Power consumption

The M920q draws about 10 watts at idle. Barely more than an LED bulb. Under full Docker load with multiple containers running builds, streaming media, and pushing to Git, it peaks at around 35 watts.

For context: a typical used rack server (Dell R720, HP DL380) idles at 80 to 150 watts doing nothing. Over a year, that difference adds up to roughly 100 to 200 EUR in electricity costs at German rates. The M920q pays for itself in saved power within two years compared to a traditional server.

What runs on it

After a few months of iteration, the Docker host now runs:

Gitea with a CI runner (my own Git forge with build pipelines)
Jellyfin (media streaming)
Traefik (reverse proxy)
Cloudflare Tunnel (secure remote access without port forwarding)
AdGuard Home (network-wide ad blocking)
Vaultwarden (password manager)
Grafana + Prometheus + Loki (monitoring and log aggregation)
CrowdSec (WAF/IDS in front of Traefik)
Multiple Nginx containers serving static sites

All of that on a 305 EUR mini PC drawing 10 watts idle. The six cores and 32 GB RAM handle it without breaking a sweat.

Why this works for a home lab

The ThinkCentre M-series machines are built for enterprise desktop use. That means:

Rock solid hardware (these run 24/7 in corporate fleets)
Excellent Linux/Proxmox compatibility out of the box
vPro/AMT for remote management if you want it
Abundant supply on the used market as companies cycle their leases

The M920q specifically hits a sweet spot. The i5-8500T has 6 cores (no hyperthreading, but 6 real cores), supports up to 64 GB RAM, and the PCIe slot means you can add a 10GbE NIC or an HBA card for direct-attached storage later.

Lessons learned

Start with Portainer Business Edition. The free three-node license is generous and the Git-based stack deployment alone is worth it. Being able to push a docker-compose change to a Git repo and have Portainer auto-deploy it removes a lot of manual SSH work.

Sell the original components immediately. RAM and SSD prices drop fast. I listed mine the day the upgrades arrived and got 55 EUR back. Waiting a month would have netted me 30 at best.

The NAS stays a NAS. I moved all compute workloads off the Synology and let it do what it does best: store files, run scheduled backups, and serve NFS shares. It is much happier now.

35 watts is the ceiling, not the floor. Most of the time the system idles well below that. My Grafana dashboard shows an average of 12 to 15 watts over a typical week. Only CI builds and transcoding push it higher.

Over to you

If you are running Docker workloads on a NAS and hitting memory limits, or if you are paying 20 to 30 EUR/month in electricity for a tower server that is mostly idle, the ThinkCentre M920q (or its newer siblings M920x, M930q, M90q) might be worth a look.

What is your home lab hardware? Curious to hear what others are running and how you keep power consumption reasonable.

DEV Community: Christoph Dieck

Goodbye Fritz!Box, Hello Ubiquiti

Why switch at all?

Step 1: reading the Fritz!Box config

Step 2: understanding the WAN settings

Step 3: configuring the UCG Ultra

Step 4: migrating LAN settings

Does the ISP notice the switch?

What about VoIP?

What I learned

Ads? Never Heard of Them.

The goal: quiet across the whole network

The final boss: port 53

The fix: Macvlan

The next problem: Traefik

Network isolation

The 502 Bad Gateway

The architecture

The config: two networks, one container

The config trick

Feeding the Fritz!Box

The result

Monitoring, or 'Why is the internet constantly asking for my .php files?

What do I actually want to know?

Dashboards

First discoveries: hello, botnet

The fix: Traefik and CrowdSec

The middleware in action

Is it worth the effort?

Docker Cleanup and Surgical Data Recovery

The fatal error in the compose file

Surgical recovery from the Proxmox backup

The NFS trap and the SQLite repair

The new setup

What I took away from it

Recovering a lost RNS 510 radio code with a Python script

The roadblock

Brute-forcing the PIN

Building the RNS510 Code Finder

How to use it

1. Clone the repository

2. Install pyserial

3. Run the script

4. Example output

How it went

Takeaway

astro-gallery: four image gallery components for Astro

What astro-gallery is

Setup

JustifiedGallery

ImageGallery

ImageTimeline

MapGallery

What you get for free

astro-gallery vs rolling your own

FAQ

Links

Monte Carlo Simulation: How to go broke eight times faster with 8 Eurojackpot lines

What exactly is a Monte Carlo simulation?

The Setup

The Script

The Result

10 Years of Eurojackpot Data with Polars

Step 1: Setup Your Development Environment

Step 2: Loading the Eurojackpot Draw History

Step 3: The "Reality Check" Script

The Results

Middle-earth and the Digital Infarction

The Suspect in the Server Closet

Hunting Through the Kernel Logs

Why Does This Happen?

The Solution

1. Adjust Driver Options

2. Disable Offloading

3. Create a Systemd Service

The Rescue Mission Conclusion

I Built a Chimney Calculator Because I Wanted a Wood Stove

The origin story

What DruckZugPro does

The physics that makes it interesting