Jellyfin Forum
Most Optimal JF/Docker Setup on Linux for Local & Non-Local Use? - Printable Version

+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: General Questions (https://forum.jellyfin.org/f-general-questions)
+--- Thread: Most Optimal JF/Docker Setup on Linux for Local & Non-Local Use? (/t-most-optimal-jf-docker-setup-on-linux-for-local-non-local-use)



Most Optimal JF/Docker Setup on Linux for Local & Non-Local Use? - 4r5hw45twh - 2025-01-21

What is the most simplistic, optimal setup one could have so that everything just flows nicely and
would have the least amount of headaches to fix issue(s) if they happened?

The goal I personally wanted to achieve:
Access JF & JS on my home devices (Firestick, phone, etc.) using the server's local IP address for JF/JS.
Access JF & JS when not home through my domain name.

My setup is:
-Domain name with Cloudflare pointing to my server's public IP.
-Docker has NPM, JF, & Jellyseerr (JS) in it and is managed by NPM.
-NPM's proxy host IP for JF is the server's native local IP instead of "jellyfin".
-JF docker compose file has these ports in it: 7359, 1900, and 8096
-Each docker compose file for each program in Docker ends with the custom network name I gave them (should I make these all "--net=host" instead?)
-Regarding VPN, I use ProtonVPN but I only want it On for qBittorrent. Cannot figure this out yet.


If a professional Linux, Docker, or NPM user/dev saw my setup and how it's configured, what could be optimized/changed?
Would they be like, "nah, change those custom network names on the docker compose files and just make them all host. Then do X differently to achieve Y by Z method" or what?
The point of this thread is to not only achieve a better setup for myself and my needs, but spark discussion in general on optimal setups.


RE: Most Optimal JF/Docker Setup on Linux for Local & Non-Local Use? - bitmap - 2025-01-22

Seems straightforward enough. A rule of thumb is to avoid giving additional permissions to containers if they're not needed. I call it the tenet of least access. If these are working without providing access to the host network, there's no need to do so. I have one container with host networking enabled: Pi-hole. All of the others use bridge network (not an amazing practice, but not super harmful). Not sure we have any professional Docker folks here, but most of us who use Docker have similar setups.

Code:
-p 7359/udp    Optional - Allows clients to discover Jellyfin on the local network.
-p 1900/udp    Optional - Service discovery used by DNLA and clients.

You could add your server's IP to the beginning of these if you want to clamp down a little more, but it's not really a huge deal. Another thing you could do is utilize non-standard ports for things so that nobody can scan through and find a Jellyfin instance. You're a relatively low-end target, so again it's not really a big deal.