Networking has long been my Achilles heel. I know the very basics, but the more complex areas of networking have been a bit puzzling to me. By the time I figured out how IPv4 works, I found IPv6 and that my ISP supports it.

Back to square one.

That didn’t stop me from learning some bits, and after 8+ years of self-hosting as a hobby, I’ve settled on a setup that works for me and overcomes common residential internet connection nuances, such as dynamic IPv4 addresses and changing IPv6 prefixes. I’m sharing these tips and tricks with the goal of helping out other hobbyists out there that happen to share a similar stack.

Background

My ISP is polite enough to provide a public IPv4 address, and allowing incoming traffic is a toggle in their online self-service. Not perfect, but at least you can do it. However, they charge about 6 EUR a month for the static IP address service, which I am not willing to pay out of principle.

They also support IPv6, which is great, and they provide you a whole /56 slice of it to play with using IPv6 prefix delegation. Unfortunately they have configured the lease time for the prefix to be incredibly short: 26 minutes!

A router reboot or short power outage usually results in the IPv4 address and IPv6 prefix changing, which is really annoying as my services become unavailable for a short time.

Dynamic DNS

A common way to overcome the dynamic IP address limitation is to sign up with a provider to set up a DNS record that changes whenever your home IP address changes. My domain registrar does not have this as a feature, and I’m not interested in using a different provider, so I went in a different direction and built a home-grown script that does the same thing.

Initially, this script relied on a public service that tells you what your IP address is, and based on that I could check if things have changed and I need to update my DNS record. This approach has one glaring catastrophic failure mode though: that provider could lie to you one day and now you’ve pointed your DNS records at the attackers’ servers. :)

I ignored that failure mode for a while, but once I learned about the effectiveness of LLM-based tooling, I decided to give it a go and to build a better solution that takes into account my setup and requirements, while at the same time saving me from the frustration of troubleshooting and debugging this in a late evening. I’m still very limited on available free time, so optimizing for that is a priority for me.

My main networking gear runs OpenWRT, and it supports running shell scripts periodically in a crontab. The router has two WAN interfaces, one for IPv4 and one for IPv6. It already knows what IP address and prefix have been assigned to it, so I don’t have to rely on an external service provider for finding this out.

Handling IPv4 addresses is simple: check the IPv4 address of the WAN interface. Query your existing DNS records, diff it, and if it has changed, push an update in a separate API call. Super simple!

With IPv6, the approach is slightly different. Instead of the WAN interface, I have to get the IPv6 address of the target machine, and make sure that it’s routable over the public internet. When you’ve checked your network settings in an IPv6 network, you may have noticed a lot of different IP addresses there, with lots of letters thrown into the mix.

Here’s an example from the machine that is serving you this blog (likely out of date though!):

    inet6 fdb3:6dad:6dce::f41/128 scope global dynamic noprefixroute 
    inet6 fdb3:6dad:6dce:0:2e0:4cff:fe0c:9ddb/64 scope global noprefixroute 
    inet6 2001:7d0:856c:4000::f41/128 scope global dynamic noprefixroute 
    inet6 2001:7d0:856c:4000:2e0:4cff:fe0c:9ddb/64 scope global dynamic noprefixroute 
    inet6 fe80::2e0:4cff:fe0c:9ddb/64 scope link noprefixroute 

The two relevant ones are the ones that start with 2001:, others are link-local or accessible over the local network only. The shorter one consists of the IPv6 prefix part, and then the unique bit at the end is a predictable suffix that the host gets. The other one also works, but is as far as I understand randomly generated and more difficult to predict when we get around to next sections.

I know that there is probably a better way to do this, but I wanted to keep things simple enough so that I can troubleshoot them if needed. It may be possible to trigger this updater script on events that WAN and WAN6 interfaces send, but I have not validated this theory.

There are many different ways to find the IPv6 address of a particular host, so the script I have just tries multiple approaches to find the one that we’re looking for.

Here’s the script in case you’re interested in setting up something similar. It reads credentials from an .env file and is built around the Zone API. On OpenWRT, the only dependency that you need to install is curl, which to my surprise was not part of the default packages list, probably to save on space.

One lesson I learned from a previous iteration of the script: if you trigger DNS record updates every minute, then Zone will actually reach out to you via e-mail telling you to cut that shit out, politely. It was just one missing if statement, and yet it caused some frustration to engineers far away. Sorry!

Predictable IP addresses

It’s a good idea to set up static IP addresses for your hosts, both for IPv4 addresses and IPv6 prefix delegation via DUID-s.

The OpenWRT GUI LuCI makes it quite simple, just set the addresses as static on the landing page for the hosts that you are interested in forwarding traffic to, and you’re done!

My recommendation here is to also set a predictable IPv6 suffix, otherwise all your IPv6 traffic rules may break once again due to this nuance.

I like to make that host number the same for both IPv4 and IPv6, quick example:

• 192.168.1.2
• 2001:7d0:854f:8e00::2

Here’s a configuration snippet example from /etc/config/dhcp, look for the hostid option:

config host
        option name 'mycoolserver'
        option ip '192.168.1.69'
        list mac '12:34:56:78:90:AB'
        option duid 'yourduidgoeshere'
        option hostid '69'

Apply with service dnsmasq restart.

In LuCI, as of OpenWRT 25.12, look for “IPv6 token”.

Note that due to a bug, it doesn’t seem to be possible to set a numeric IPv6 token via GUI, which is why you will need to add it manually in CLI using the above approach.

Port forwards, traffic rules, potato, potahtoh

Whenever you want to make a local machine accessible on the internet for IPv4, the solution is simple: set up a port forward to that particular machine, and you’re done! It’s a common enough flow for people who’ve set up game servers and the like, and well understood by more novice users.

With IPv6, port forwards don’t help. You’ll have to check one tab over at “Traffic rules” in OpenWRT GUI.

It’s a common misconception that by using IPv6 you are exposing everything to the world as each device gets its own IPv6 address, but turns out that this is not the case in most common setups. By default, OpenWRT forwards only a few types of traffic to IPv6 hosts, such as ICMP packets that make ping work between devices over IPv6 across the public internet. If you are interested in allowing IPv6 clients to access services on your local server that has an IPv6 address, you will have to explicitly allow it by adding a new traffic rule.

There’s one issue with this approach that a lot of users seem to run into: if the IPv6 prefix changes, then all my traffic rules that are pointing to a particular host are automatically broken!

Luckily there is a clever workaround implemented on OpenWRT that bypasses this issue. Assuming that you followed the previous step and set yourself up with a predictable IPv6 suffix, when setting up a traffic rule, set the target device up as ::69/-64, just replace 69 with your actual suffix. The IPv6 prefix can now change, but the ports that you’ve made accessible on this specific host will remain working.

At this point, you should be all set with a reasonably well working setup where you’ve handled the issues with dynamic IPv4 and IPv6 prefix, and you can access your services over the public internet even when things happen.

Limitations

One issue that this setup has is the fact that DNS change propagation takes time. Usually clients will pick up the new records within 5 minutes, but in my professional career I’ve seen some clients take up to 24 hours or longer to finally start sending traffic to the new DNS record. Whenever your IP address changes, there will be a mini-outage. Not catastrophic if you’re just hosting hobby projects and personal services at home, but I wouldn’t host anything mission-critical in such a setup.

When your OpenWRT device is as underpowered as mine, then you may notice that the TLS encryption overhead when curl -ing around can be significant. I have set my dynamic DNS script to run every 5 minutes, and it shows up on the CPU usage graphs on my router.

Wireguard all the things!

I know that Tailscale is a popular method of connecting up your devices and making your personal services privately accessible over that, which significantly reduces your attack surface. Being behind a few updates or not being vigilant enough is less of an issue compared to exposing your services over the public internet.

You don’t necessarily need Tailscale for that though! If you just need a way to access your services over a private and secure network, then setting up a dedicated mini PC or single-board computer is a very good starting point. Let it be the server, allow traffic to move between the clients over the Wireguard interface, and you’re all set!

Alternatively, if you have an OpenWRT router, then you can do it right there, but I found the GUI management setup to be a bit clunky compared to deploying the plain configuration files to clients. When I did do that test, I discovered quickly that my router and its single ARM CPU core with no cryptography extensions is too slow for managing my Wireguard network, with speeds topping out at 20 Mbit/s. 20. The LattePanda IOTA can easily saturate its gigabit link, as does the ThinkPad T430, and even devices like the Orange Pi Zero can handle a theoretical maximum of about 240 Mbit/s over Wireguard measured using wg-bench.

My current Wireguard host is the LattePanda V1, the most unstable computer in my fleet. With a USB adapter, it can push almost half a gigabit of traffic over Wireguard.

If you’re like me, and you like hosting your services over Docker or Podman, then instead of listening on ports for all interfaces on your containers (default behaviour when setting up port forwards), I recommend listening only on the Wireguard interface. This makes the service only accessible over Wireguard, meaning that you only need to set up one port forward and traffic rule to connect to the Wireguard network, and then you have access to all of your services. The attack surface is significantly reduced, the whole Wireguard solution is stable and very small, and unless you leak your private key, you are reasonably secure!

Here’s a snippet from a compose file showcasing how to set this up for IPv4 and IPv6:

ports:
  - 10.69.69.12:2283:2283
  - "[fded:abba:acca::12]:2283:2283"

Want to make the service available over Wireguard and over the local network directly? Just add those to the list! Note that if your local address changes and you don’t update it in the compose file, your container will refuse to start up as it cannot listen to the interface any longer, but you can mitigate that with the static IP addresses step.

When you are going with this route, it is unlikely but still possible that by the time the container starts up, the Wireguard interface is not yet up. To resolve this, you can use systemd to set Wireguard up as a dependency that you will have to wait for before the container starts up.

I manage my Wireguard connection with wg-quick@interfacename service. You can set up a systemd override for Docker, or if you manage your Docker/Podman services via systemd, then you can set it up per-service using this pattern:

# /etc/systemd/system/myimmichserver.service.d/override.conf
[Unit]
Requires=wg-quick@interfacename.service
After=wg-quick@interfacename.service

By the way, systemd overrides are also really useful for ensuring that your storage that your containers rely on is properly mounted. If my service requires the path /immich to be available and mounted, add something like this:

BindsTo=immich.mount
After=immich.mount

If you unmount the mount point, it will also properly bring down the service. The service won’t start if the mount point is missing. I’ve had the issue with containers seeing blank mount points more times than I’d like to admit, and this has eliminated this issue for me.

systemd has received a lot of hate online, and I don’t think it’s fair. The ease with which you can set up dependencies on your system, set up resource limits, make services more restricted to improve the security posture is great and allows me to and avoid all sorts of failure modes. Production services that I’m responsible for make use of these systemd features, with great results.

For services that need to be public, such as Nextcloud and its public shareable links, this approach won’t work, obviously, but for things that only you and your family members use, this is a viable approach.

Conclusion

This setup works well enough for me to confidently host my blog and self-hosted services off of it. I’ve hit a lot of paper cuts and frustrations along the way, but after following this guide, you don’t have to do the same.

Yes, VLAN-s are intentionally missing from this guide. I’ll get to them eventually, maybe by Q4 2037 given my lack of free time.

And no, IPv6 isn’t complicated, it’s just different from what everyone is used to. If we started out with IPv6 right from the get-go, we wouldn’t be having dumb arguments online.

LattePanda V1. It’s been a while, huh?

I had it as a backup server (which I blew up).

Then it got promoted to… a backup server. But then its PSU blew up.

Then it was waiting for some cool ideas at a potato enthusiast.

Now it’s back in my hands.

Unlike its modern counterpart, the LattePanda V1 is a flawed single board computer.

It’s slow.

It’s unstable if you connect power hungry USB devices to it.

It needs some cooling, but I’m too cheap to buy a properly designed heat sink for it.

It has display quirks.

It only has a slow 100 Mbps Ethernet link.

It only seems to work reliably on one side. Not even joking, the “heat sink down” configuration is the only one that works for me.

LibreELEC failed to play back any videos on it properly. The videos would play for 10 seconds, and then it would hang, no matter the encoding or hardware acceleration settings.

With hardware prices being wonky again, I decided to give this board a last chance of being useful. If new hardware is absurdly expensive, then it makes perfect sense to use what you have, no matter how slow or crummy it might be. Reduce, reuse, and only then recycle.

That’s when I decided to run a Jellyfin server off of it. Transcoding is out of the question, but serving media files over the network should still be quick enough, right?

For this experiment, I used one of the 18 TB hard drives that I’ve covered earlier. Just the single one, no redundancy here. This one drive is probably about 10x the cost of the LattePanda V1 itself, making it a perfectly reasonable choice.

For ease of troubleshooting, debugging and guaranteed eventual reinstallation, I put Fedora Server on an 128 GB USB 3.0 flash drive by Samsung. Risky move, I know, but as you might have noticed, this whole build is everything but reasonable. That left the eMMC storage as the perfect candidate for storing cache and service related files.

Cooling is solved by a random server heat sink slapped on the bottom of the LattePanda, with a few critical components like the CPU making contact with thick and soft thermal pads. The whole thing is fastened using velcro strips that I cut to a thin size in the middle so that I can route it between the components on the PCB and within the heat sink fins. The edges of the heat sink are covered with some painters’ tape that I had around to avoid shorting anything out on the board, because those parts on the board contain all sorts of metal bits and pins that have power going through them. I’m actually quite happy with that mount!

I’ve been experimenting with Podman again after Docker kept doing weird things with the v29 release, and I’ve been happy with the results, so that’s what I used on the LattePanda V1 as well. I slapped Jellyfin on it, threw in some test files and gave it a go.

Navigating the UI feels a bit slow at times, but it’s not really noticeable on an LG smart TV with a really laggy user interface.

Actual video playback that requires no transcoding works quite well, at least for smaller media sizes.

Technically, you can do transcoding on this and even utilize the tiny little integrated GPU in it, but the results are not usable. With smaller files it might be usable, but in one test I saw 7-8 FPS transcoding speeds and the server struggling to keep up, with CPU usage locked at 100%.

If we ignore all the downsides, then the LattePanda V1 can actually be a usable media server. Serving files off of a big drive does not require a lot of resources, and for that the LattePanda V1 is a solid choice. It also uses only a few watts of power on its own, so you can keep it on 24/7 guilt-free. In this build, the hard drive itself is actually the most power hungry component by a long shot (about 2/3 of the total power budget).

The 2 GB of memory is juuuuuuuust enough for this setup.

As of writing this post, it has been running for about a week, and it’s been fine. I intend to keep it running in a drawer for as long as possible just to see what will die first.

Will it be the eMMC storage?

The USB flash drive holding the operating system?

The expensive hard drive?

The power supply?

The thin velcro strips holding the cooling together?

My patience?

Don’t worry, I have backups. Well, backups of the important bits. I’m ready to lose data again.

2026-01-22 update

Okay, it was too bad of an idea.

The LattePanda V1 would occasionally just… stop.

From what I gathered by accident, it’s likely that the USB port containing the operating system would flake out and result in the system not being able to run any tools that are not in memory. I tried to move the installation to the eMMC drive, but after failing multiple times due to the display not working, or the system deciding to shut down randomly, I gave up on it. For now.

Guess I’ll have to use it in a solar-powered website project. ¯\_(ツ)_/¯

I use Uptime Kuma to check the availability of a few services that I run, with the most important one being my blog. It’s really nice.

Today I wanted to set it up on a different machine to help troubleshoot and confirm some latency issues that I’ve observed, and for that purpose I picked the cheapest ARM-based Hetzner Cloud VM hosted in Helsinki, Finland.

Hetzner provides a public IPv6 address for free, but you have to pay extra for an IPv4 address. I didn’t want to do that out of principle, so I went ahead and copied my Docker Compose definition over to the new server.

For some reason, Uptime Kuma would start up on the new IPv6-only VM, but it was unsuccessful in making requests to my services, which support both IPv4 and IPv6. The requests would time out and show up as “Pending” in the UI, and the service logs complained about not being able to deliver e-mails about the failures.

I confirmed IPv6 connectivity within the container by running docker exec -it uptime-kuma bash and running a few curl and ping commands with IPv6 flags, had no issues with those.

When I added a public IPv4 address to the container, everything started working again.

I fixed the issue by explicitly disabling the IPv4 network in the Docker Compose service definition, and that did the trick, Uptime Kuma made successful requests towards my services. It seems that the service defaults to IPv4 due to the internal Docker network giving it an IPv4 network to work with, and that causes issues when your machine doesn’t have any IPv4 network or public IPv4 address associated with it.

Here’s an example Docker Compose file:

name: uptime-kuma
services:
  uptime-kuma:
    container_name: uptime-kuma
    networks:
      - uptime-kuma
    ports:
      - 3001:3001
    volumes:
      - /path/to/your/storage:/app/data
    image: docker.io/louislam/uptime-kuma
    restart: always
networks:
  uptime-kuma:
    enable_ipv6: true
    enable_ipv4: false

That’s it!

If you’re interested in different ways to set up IPv6 networking in Docker, check out this overview that I wrote a while ago.

In November 2024, my blog was down for over 24 hours.

Here’s what I learned from this absolute clusterfuck of an incident.

Lead-up to the incident

I was browsing through photos on my Nextcloud instance. Everything was fine, until Nextcloud started generating preview images for older photos. This process is quite resource intensive, but generally manageable. However, this time the images were high quality photos in the 10-20 MB size range.

Nextcloud crunched through those, but ended up spawning so many processes that it ended up using all the available memory on my home server.

And thus, the server was down.

This could have been solved by a forced reboot. Things were complicated by the simple fact that I was 120 kilometers away from my server, and I had no IPMI-like device set up.

So I waited.

50 minutes later, I successfully logged in to my server over SSH again! The load averages were in the three-digit realm, but the system was mostly operational.

I thought that it would be a good idea to restart the server, since who knows what might’ve gone wrong while the server was handling the out-of-memory situation.

I reboot.

The server doesn’t seem to come back up. Fuck.

The downtime

The worst part of the downtime was that I was simply unable to immediately fix it due to being 120 kilometers away from the server.

My VPN connection back home was also hosted right there on the server, using this Docker image.

I eventually got around to fixing this issue the next day when I could finally get hands-on with the server, my trusty ThinkPad T430. I open the lid and am greeted with the console login screen. This means that the machine did boot.

I log in to the server over SSH and quickly open htop. My htop configuration shows metrics like systemd state, and it was showing 20+ failed services. This is very unusual.

lsblk and mount show that the storage is there. What was the issue?

Well, apparently the Docker daemon was not starting. I was searching for the error messages and ended up on this GitHub issue. I tried the fix, which involved deleting the Docker folder with all the containers and configuration, and restarted the daemon and containers. Everything is operational once again.

I then rebooted the server.

Everything is down again, with the same issue.

And thus began a 8+ hours long troubleshooting session that ran late into the night. 04:00-ish late, on a Monday.

I tried everything that I could come up with:

• used the btrfs Docker storage driver instead of the default overlay one
  • Docker is still broken after a reboot
• replaced everything with podman
  • I could not get podman to play well with my containers and IPv6 networking
• considered switching careers
  • tractors are surprisingly expensive!

I’m unable to put into words how frustrating this troubleshooting session was. The sleep deprivation, the lack of helpful information, the failed attempts at finding solutions. I’m usually quite calm and very rarely feel anger, but during these hours I felt enraged.

The root cause

The root cause will make more sense after you understand the storage setup I had at the time.

The storage on my server consisted of four 4 TB SSD-s, two were mounted inside the laptop, and the remaining two were connected via USB-SATA adapters. The filesystem in use was btrfs, both on the OS drive and the 4x 4TB storage pool. To avoid hitting the OS boot drive with unnecessary writes, I moved the Docker data root to a separate btrfs subvolume on the main storage pool.

What was the issue?

Apparently the Docker daemon on Fedora Server is able to start up before every filesystem was mounted. In this case, Docker daemon started up before the subvolume containing all the Docker images, containers and networks was mounted.

I tested out this theory by moving the Docker storage back to /var/lib/docker, which lives on the root filesystem, and after a reboot everything remained functional.

In the past, I ran a similar setup, but with the Docker storage on the SATA SSD-s that are mounted inside the laptop over a native SATA connection. With the addition of two USB-connected SSD-s, the mounting process took longer for the whole pool, which resulted in a race condition between the Docker daemon startup and the storage being mounted.

Fixing the root cause

The fix for Docker starting up before all of your storage is mounted is actually quite elegant.

The Docker service definition is contained in /etc/systemd/system/docker.service. You can override this configuration by creating a new directory at /etc/systemd/system/docker.service.d and dropping a file with the name override.conf in there with the following contents:

[Unit]
RequiresMountsFor=/containerstorage

The rest of the service definition remains the same and your customized configuration won’t be overwritten with a Docker version update. The RequiresMountsFor setting prevents the Docker service from starting up before that particular mount exists.

You can specify multiple mount points on the same line, separated by spaces.

[Unit]
RequiresMountsFor=/containerstorage /otherstorage /some/other/mountpoint

You can also specify the mount points over multiple lines if you prefer.

[Unit]
RequiresMountsFor=/containerstorage 
RequiresMountsFor=/otherstorage 
RequiresMountsFor=/some/other/mountpoint

If you’re using systemd unit files for controlling containers, then you can use the same systemd setting to prevent your containers from starting up before the storage that the container depends on is mounted.

Avoiding the out of memory incident

Nextcloud taking down my home server for 50 minutes was not the root cause, it only highlighted an issue that had been there for days at that point. That doesn’t mean that this area can’t be improved.

After this incident, every Docker Compose file that I use includes resource limits on all containers.

When defining the limits, I started with very conservative limits based on the average resource usage as observed from docker stats output.

Over the past few months I’ve had to continuously tweak the limits, especially the memory ones, due to the containers themselves running out of memory when the limits were set too low. Apparently software is getting increasingly more resource hungry.

An example Docker Compose file with resource limits looks like this:

name: nextcloud
services:
  nextcloud:
    container_name: nextcloud
    volumes:
      - /path/to/nextcloud/stuff:/data
    deploy:
      resources:
        limits:
          cpus: "4"
          memory: 2gb
    image: docker.io/nextcloud:latest
    restart: always
  nextcloud-db:
    container_name: nextcloud-db
    volumes:
      - /path/to/database:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          cpus: "4"
          memory: 2gb
    image: docker.io/postgres:16
    restart: always

In this example, each container is able to use up to 4 CPU cores and a maximum of 2 GB of memory. And just like that, Nextcloud is unable to take down my server by eating up all the available memory.

Yes, I’m aware of the Preview Generator Nextcloud app. I have it, but over multiple years of running Nextcloud, I have not found it to be very effective against the resource-hungry preview image generation happening during user interactions.

Decoupling my VPN solution from Docker

With this incident, it was also clear that running your gateway to your home network inside a container was a really stupid idea.

I’ve mitigated this issue by taking the WireGuard configuration generated by the container and moving it to the host. I also used this as an opportunity to get a to-do list item done and used this guide to add IPv6 support inside the virtual WireGuard network. I can now access IPv6 networks everywhere I go!

I briefly considered setting WireGuard up on my openWRT-powered router, but I decided against it as I’d like to own one computer that I don’t screw up with my configuration changes.

Closing thoughts

I have not yet faced an incident this severe, even at work. The impact wasn’t that big, I guess a hundred people were not able to read my blog, but the stress levels were off the charts for me during the troubleshooting process.

I’ve long advocated for self-hosting and running basic and boring solutions, with the main benefits being ease of maintenance, troubleshooting and low cost. This incident is a good reminder that even the most basic setups can have complicated issues associated with them.

At least I got it fixed and learned about a new systemd unit setting, which is nice.

Still better than handling Kubernetes issues.

Good news, everyone! Doing IPv6 networking stuff on Docker is actually good now!

I’ve recently started reworking my home server setup to be more IPv6 compatible, and as part of that I learned that during the summer of 2024 Docker shipped an update that eliminated a lot of the configuration and tweaking previously necessary to support IPv6.

There is no need to change the daemon configuration any longer, it just works on Docker Engine v27 and later.

Examples

If your host has a working IPv6 setup and you want to listen to port 80 on both IPv4 and IPv6, then you don’t have to do anything special. However, the container will only have an IPv4 address internally. You can verify it by listing all the Docker networks via sudo docker network ls and running sudo docker network inspect network-name-here for the one associated with your container.

For services like nginx that log the source IP address, this is problematic, as every incoming IPv6 request will be logged with the Docker network gateway IP address, such as 10.88.0.1.

name: nginx
services:
  nginx:
    container_name: nginx
    ports:
      - 80:80
    image: docker.io/library/nginx
    restart: always

If you want the container to have an IPv4 and an IPv6 address within the Docker network, you can create a new network and enable IPv6 in it.

name: nginx
services:
  nginx:
    container_name: nginx
    networks:
      - nginx-network
    ports:
      - 80:80
    image: docker.io/library/nginx
    restart: always
networks:
  nginx-network:
    enable_ipv6: true

There are situations where it’s handy to have a static IP address for a container within the Docker network. If you need help coming up with an unique local IPv6 address range, you can use this tool.

name: nginx
services:
  nginx:
    container_name: nginx
    networks:
      nginx-network
        ipv4_address: 10.69.42.5
        ipv6_address: fdec:cc68:5178::abba
    ports:
      - 80:80
    image: docker.io/library/nginx
    restart: always
networks:
  nginx-network:
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: "10.69.42.0/24"
        - subnet: "fdec:cc68:5178::/64"

If you choose the host network driver, your container will operate within the same networking space as your container host. If the host handles both IPv4 and IPv6 networking, then your container will happily operate with both. However, due to reduced network isolation, this has some security implications that you must take into account.

name: nginx
services:
  nginx:
    container_name: nginx
    network_mode: host
    # ports are not relevant with host network mode
    image: docker.io/library/nginx
    restart: always

If you want your container to only accept connections on select interfaces, such as a Wireguard connection, then you will need to specify the IP addresses in the ports section. Here’s one example with both IPv4 and IPv6.

name: nginx
services:
  nginx:
    container_name: nginx
    networks:
      - nginx-network
    ports:
      - 10.69.42.5:80:80
      - "[fdec:cc68:5178::beef]:80:80"
    image: docker.io/library/nginx
    restart: always
networks:
  nginx-network:
    enable_ipv6: true

What about Podman?

I’ve given up on Podman. Before doing things the IPv6 way, Podman was functional for the most part, requiring a few tweaks to get things working.

I have not managed to get Podman to play fair with IPv6. No matter what I did, I could not get it to listen to certain ports and access my services, the ports would always be filtered out.

Conclusion

I’m genuinely happy to see that the IPv6 support has gotten better with Docker, and I hope that this short introduction helps those out there looking to do things the IPv6 way with containers.

Steam recently launched a new feature: local network game transfers.

The idea is simple: if you have a game downloaded on another PC and you’re both on the same local network, then Steam can download game data from that PC, avoiding the need to download the game over public internet. Using this method you can reduce your internet usage and enjoy faster download times.

I think this feature is absolutely brilliant. There are many homes out there, even in developed countries, where the internet connection sucks. The speed might be capped at something very slow, such as 10 Mbit/s down, or you might have a bandwidth cap in place. Perhaps you have multiple gaming PC-s and you want to avoid downloading 100+ gigabytes worth of files over the internet to avoid hitting your bandwidth cap. In those situations being able to download your games to a PC that has a bunch of storage in it makes a lot of sense.

This isn’t the only way to achieve the same goal as projects like LanCache exist. However, with Steam the setup is so simple that anyone who knows how to install Steam could achieve a similar result. The only caveat is that you’re limited to games installed through Steam, LanCache supports many other services.

Here are some ideas on how you can set up your own Steam cache.

Using an old laptop

If you have an older laptop around and it has a gigabit Ethernet connection, then that can be a good candidate for setting up a Steam cache.

The hardware I picked for this test is a ThinkPad T430. It has a 4 core CPU in it, 16 GB of RAM and plenty of ways to attach storage to it. With storage I tried two approaches: using an older 1TB 2.5" SATA HDD, and using two Samsung 870 EVO 1TB SATA SSD-s in RAID0.

The hard drive based solution isn’t something I recommend, unless you plan on running two or more in a RAID-like setup. The Steam cache use case seems to have hit the limits of the hard drive and that limited the transfer speeds significantly.

The SSD-based setup was great! You might want to run something other than a RAID0 setup if you want to avoid a drive failure taking your whole Steam library with you, I ran with this setup mainly to see where the limits are. The Steam library is also something you can easily redownload, should things go really wrong.

One benefit of setting up an older laptop as a Steam cache is that you can take it with you to a place that has great internet connectivity, download your games there and bring it back home with you. That’s exactly what I did when performing testing, I went to my local hackerspace, started the downloads, and came back half a day later to find that over a terabyte worth of games had been downloaded. Doing the same on a slower home network would have taken days. I guess the idea of IP over avian carriers, or over humans, isn’t dead yet.

When downloading the games, I noticed that Steam was hitting the CPU hard. Even on a decent 4-core Intel i7-3820QM the CPU was often running at 100%. This meant that download speeds were usually around 500-700 Mbit/s, which is still good, but nowhere near saturating the gigabit link that the laptop had.

Now that I had all the games downloaded, it was time to test the performance. The maximum transfer speeds were around 400-500 Mbit/s over my local network. I used my Steam Deck over an USB-C dock to start the downloads and picked the internal NVMe SSD as the download target to avoid any storage speed bottlenecks. I would have liked to see speeds close to 1 Gbit/s, but these speeds are still a massive improvement if your network speeds are something like 50 Mbit/s down, that’s a 10x improvement!

If you’re worried about the fact that Windows 10 is going to lose support in October 2025 and your Steam cache PC is not supported by Windows 11, then don’t worry, you can do the same thing over Linux.

Using a virtual machine

If you already have a NAS or a home server running, then you can create a new VM, add a bunch of storage to it, setup the OS and Steam and you’re good to go!

I did most of the testing on a Windows 10 VM and a 1TB HDD attached over USB 3.0. I setup the VM using a bog-standard QEMU/KVM setup and set everything up through virt-manager in Linux. The only noteworthy part is that I set up the network interface as a macvtap device, resulting in the VM showing up on my local home network as if it was a separate PC. That step was taken to avoid any issues with the Steam instances on different PC-s not being able to transfer data directly between each other.

My server runs on the ASRock Deskmini X300. It has plenty of CPU performance, but during testing I ran into performance issues with the hard drive again. When I added SSD-based storage to the VM, I found that the performance was great and quite similar to what I saw on the laptop.

The downside with the Windows 10 VM setup was the CPU usage. While the VM was idling, my server saw a noticeable increase in idle CPU usage, utilizing about 10-20% of my CPU at all times. During transfers the VM was using most of my CPU cores.

I did testing on a Linux VM to see if those are more efficient compared to a Windows 10 VM. The answer is obviously “yes”, but there is one issue: I could not get Steam to work. At the time of testing, Steam had recently released a bigger visual overhaul and I suspect that it might have something to do with those issues. The VM has no GPU acceleration and opening Steam would result in “Loading user data” popup showing up, but nothing else happening. I tried Ubuntu Desktop 22.04, Fedora Linux 38, and even Flatpak installations of Steam. All of them ran into the same exact issue. There are probably ways to set Steam to not require GPU acceleration without opening its settings view graphically, but I did not bother with that.

If you like to think in virtual machines, then this is a good option. However, it’s not something I stuck with due to the inefficient resource usage that a Windows 10 VM exhibited.

Using containers

This is the solution that I am currently running.

I recently found the LinuxServer.io webtop Docker images. These containers allow you to run various Linux desktop environments and distros on the same machine. You can connect to them using the integrated KasmVNC solution over a browser. You can even use your GPU on the container host machine to improve the video rendering performance in the container!

I picked the fedora-xfce option because Fedora is great, and the XFCE desktop environment is not that resource intensive. I also utilized the linuxserver.io package install mod to install Steam on container startup. For networking, I created a separate Docker network using the macvlan driver to achieve something similar to the VM setup, resulting in the container showing up as a separate machine on the local network. Inside the container I set up Steam to start on startup using standard GUI tools that XFCE provides for this purpose.

I really like this setup. I can easily point the Steam downloads to a larger storage pool and make use of all the CPU power that Steam needs to perform the transfers.

During testing the limitation seems to have been my Steam Deck. I could still not saturate the 1 Gbit/s link.

The KasmVNC solution is quite nice and performant. The fact that I could use it in the browser makes it very convenient to use as well.

The CPU usage during idle is very small, except for when you accidentally leave the Steam window open with animated content being displayed. During file transfers the CPU gets a beating, but it’s nothing the AMD Ryzen 7 5700G can’t handle.

For storage I eventually ended up using a 1TB Lexar NVMe SSD. That’s not enough to download all the games I have in my Steam library, but at least I can download those games that take 20+GB of space and not have to worry about downloading those over a slower internet connection.

I have not ended up using this setup too much yet, but I imagine that with games growing in size this is going to become much more relevant for my Steam Deck. And if I were to move to the countryside where the only internet connection available is a mobile 4G connection capped at 10 Mbit/s down, then this setup would be fantastic to have.

Tech tips

If you intend to run a similar setup, I recommend enabling “Scheduled updates” to run during the night. I set mine up to auto-update games between 00:00 and 06:00, which is where I’m likely going to sleep and not notice that game downloads are taking place. Steam is notorious for hogging all of the bandwidth on the network and this nifty feature helps avoid disturbing other users on the network.

If you’re performing the initial mass download of your games but would like for it to take place during scheduled times, start downloading all of the games and then restart your machine. When Steam starts up again, you’ll notice that all your games are queued up nicely to download during your scheduled updates time slot.

Caveats

This setup is not ideal and the Steam support page highlights it well. For example, this setup does not work in fully offline situations as internet connectivity is required for the initial setup of the local network game transfer. I recommend giving that page a read to understand the requirements and technical specifics of this setup.