Fair point, I’ve updated the readme now.

I hadn’t planned on that specifically. An idea that’s been in the back of my mind is to allow the configuration file be used to let users decide what command gets run, and with what arguments, so that you could use pretty much anything as the UI.

Honestly, I’d be surprised if static IPs fix it. Docker’s default network type (bridge network) is very good at assigning IPs to containers without clashing, even with container restarts and replacements: it’s been battle tested for years in production use. As others have said, standard DNS hostnames of containers should be sufficient. But I’ll certainly be interested to hear your results.

networks:
  app:
    ipam:
      config:
        - subnet: 172.20.0.0/24
          gateway: 172.20.0.1
services:
  app:
    image: my-app-image
    networks:
      app:
        ipv4_address: 172.20.0.10

In the above example I’ve declared a Docker Bridge network with the range 172.20.0.0/24 and a gateway at 172.20.0.1. I have a service named app with a static IP of 172.20.0.10.

The same is also possible with IPv6, though there are extra steps involved to make IPv6 networking work in Docker and it’s not enabled by default so I won’t go into detail in this comment.

Out of curiosity, what’s the use case for a static IP in the Docker Bridge network? Docker compose assigns hostnames equal to the service name. That is, if you had another container in the app network from my example above, it could just do a DNS lookup for app and it would resolve to 172.20.0.10.

Are you on AMD graphics by any chance?

Thanks, starting to suspect it might be only AMD graphics experiencing it.

Same build ID. Are you on Nvidia or AMD graphics?

Would it be worth chucking in an hourly restart cron job/systemd timer for the time being? Not an ideal solution for sure, but maybe that’s better than having to jump into the server every few hours (and users experiencing a seemingly stale feed).