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.

Fair point, I’ve updated the readme now.

Aren’t we all? Aren’t Ext4 and ZFS considered mature because so many people have said “it works on my machine”?

I agree this person’s experience may contrast to your own, but I don’t think the fact that something has worked well for some people, and perhaps not for yourself, is a reason to discount it entirely.

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.