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.

That seems to have done the trick, thanks! I still get a brief flash of something (presumably the Library window) when steam boots, but it disappears as quickly as it appears.