Last time this was asked, I’ve voiced the concern that tying fixed IP address to container definitions is an anti-pattern, and I’ll voice that again. You shouldn’t be defining a fixed IP address to individual services as that prevents future scaling.

Instead, you should leverage service discover mechanisms to help your services identify each other and wire up that way.

It seemed like in NPM, there is no fitting mechanisms out of the box. Which may suggest your use case is out growing what it may be able to service you for in the future. However, docker compose stacks may rescue the current implementation with DNS resolution. Try simplifying your npm’s docker compose to just this:

   networks:
      - npm

networks:
  npm:
    name: npm_default
    external: true

And your jellyfin compose with something like:

   networks:
      - npm
      - jellyfin_net

networks:
  npm:
    name: npm_default
    external: true
  jellyfin_net:
    name: jellyfin_net
    internal: true

Have your other services in Jellyfin stack stay only on jellyfin_net or whatever you define it to be, so they’re not exposed to npm/other services. Then in the configs, have your npm talk direct to the name of your jellyfin service using hostname, maybe something like jellyfin or whatever you’ve set as the service name. You may need to include the compose stack as prefix, too. This should then allow your npm to talk to your jellyfin via the docker compose networks’ DNS directly.

Good luck!

That setting also takes host names. As long as both containers share at least one network, put in the service name (not the container_name!), e.g. “npm” or whatever yours is called and you should be fine.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

[Thread #674 for this sub, first seen 11th Apr 2024, 20:55] [FAQ] [Full list] [Contact] [Source code]