After trying out Cosmos Cloud (and it not working for the clients), I’m back at square one again. I was going to install Docker Desktop, but I see it warns that it runs on a VM. Will this be a problem when trying to remote connect to certain services, like Mealie or Jellyfin?
Docker containers are isolated by default… nothing on the outside can reach them unless you say so. You open the door with a port mapping
In your compose file:
Read this as HOST:CONTAINER. It says: “when something hits my server on port 8096, forward it to port 8096 inside the Jellyfin container.”
So once it’s running, you go to http://your-server-ip:8096/ in a browser and you’re talking to Jellyfin. The container is still isolated you’ve just opened one specific door to access it.
Wouldn’t this be insecure? Is that what the reverse proxy thing is for - to keep it safe?
Also, is it possible to make it so the name is simpler? I bought a domain name just in case.
Is there a place I can learn about ports and networking more? Something like Khan Academy but for networking?
To your first questions, well need to untangle a few thoughts wrapped into that.
Right now, http://your-server-ip:8096/ is plain HTTP. On your home network that’s usually fine. Over the internet, you’d want HTTPS so passwords and stream data aren’t sent in the clear.
Just opening a port on Docker only exposes it to your local network. It’s not on the public internet unless you also forward the port on your router. So by default, only devices on your network can reach it.
From there is it secure? That’s on Jellyfin. Using strong passwords and trusting Jellyfin is secure is as good as you can do here.
The reverse proxy is where you handle the https, and where you go from domain.com:8096 to jelly.domain.com
If using caddy for example, that looks like this somewhere in your caddyfile
Your reverse proxy sits in front of your containers and routes traffic by hostname. You tell it: “when someone visits jellyfin.yourdomain.com, send them to the Jellyfin container on port 8096.”
The other pieces you’ll need:
DNS pointing jellyfin.yourdomain.com at your server’s IP (public IP if accessing from outside, local IP if just at home) A TLS certificate so HTTPS works, Let’s Encrypt is free, and Caddy gets them automatically with zero config (Nginx and Traefik can too, just more setup).
Also rputer port forwarding on 80 and 443 to make it accessible outside the house.
The last part there is the actual risky part. When you put a service on the open internet, bots from everywhere will find it instantly and begin running scripts to try to find a way in. With only this setup, again, the insecurity is Jellyfin. When an exploit drops, you need to be updated ASAP to stay on top of your security.
There are tons of ways to make this more secure. The easiest way would be tailscale/(wireguard). You basically install tailscale on every device that will connect to your server instead of opening your routers port. It keeps your device off the open internet but allows devices all on its tailscale VPN connect to it with the domain you setup.
You can achieve something similar using cloudflare tunnels. Your server runs a daemon that reaches out to cloudflare and it’s served to the internet that way, friends access via normal URL, no extra download required.
Lastly the best but cost prohibitive option is to do it through a VPS. A virtual private server does what cloudflare does, basically, but you control it. If the money is not prohibitive, I strongly recommend this. When cloudflare goes down again (and it will go down again), you won’t be beholden to their infrastructure being online to access your server.
Happy to clarify anything here. I wrote this response in 3 parts and rereading it it feels a little disjointed lol
Ah sneaky. You added a question.
The answer to is there somewhere you can learn about this? Yes and no. You will ultimately learn by doing for this stuff.
Comptia network+ study guides will have all this knowledge and more.
If you’re all in, Hack The Box is a freemium platform (think codecademy but less hand-holdy) that isn’t designed to teach you this, but will absolutely teach you this in the process. It is a platform for offensive and defensive cybersecurity. These things are covered as afterthoughts in bigger pictures, but it will (at least for folks who learn by doing) force you to familiarize yourself with it implicitly.
Otherwise as far as IPs and ports and containers, I can tell you all you need to know, because it ain’t much. It feels confusing/overwhelming at first but everything individual slice of this stuff is pretty simple. It’s just an absurd amount of knowledge. Just take baby steps and learn what you need to know to get done what you seek.
I didn’t have too much coffee, you had too much coffee.
IP address: a machine’s address on a network. Like a street address.
Port: a numbered door on that machine. The IP gets you to the building; the port gets you to the right room. Different programs listen on different ports.
DNS: the phonebook. Maps friendly names like example.com to IPs so you don’t have to memorize numbers.
Router: the doorman between your home and the internet. Stuff inside can reach out; nothing gets in unless you tell it to.
Container: a sandboxed mini-computer running on your machine. Isolated by default. You map a host port to a container port to let traffic in.
Reverse proxy: a switchboard. One program that takes all incoming traffic and routes it to the right service based on the hostname.
Welcome to foggy’s IP, ports, and containers lesson, take a shot of espresso, we’re going in!
special IP addresses:
127.0.0.1 - “This same machine.” Talking to yourself. Also written as localhost.
192.168.x.x - private home network range. What your router hands out to your devices. Not routable on the internet. 10.x.x.x - another private range. Bigger, used by businesses and some routers. Same idea as 192.168.
172.16.x.x to 172.31.x.x - the third private range. Docker likes this one for its internal container networks.
0.0.0.0 - “all interfaces” or “any address.” When a service binds to this, it means “listen on every network this machine is connected to.” Also sometimes means “no specific address” depending on context.
255.255.255.255 - brosdcast. “Everyone on this network.” Rarely something you’ll type, but you’ll see it.
169.254.x.x - link-local. What your machine assigns itself when it wanted a DHCP address from the router but didn’t get one. If you see this, something’s wrong with your network.
Port talk:
Ports 0-1023: well-known ports. Reserved for standard services. On Linux you need root to bind to these. The ones you’ll actually see:
Ports 1024-49151: registered ports. Assigned to specific apps by convention. A sampling:
Nothing enforces these: they’re just conventions. You could run Jellyfin on port 7777 if you wanted.
Ports 49152–65535: ephemeral ports. A neato part:
When you connect to a servers port 443, for example, your machine connects to the server’s port 443, but it also needs a port on your end for the server to send replies back to. Your OS grabs a random unused port from this high range, uses it for that one connection, and releases it when done. Thus, ‘ephemeral’
Containers? Sure:
A container is a program packaged in a bubble. It’s basically a VM without the machine part. Let’s say you wanna run Jellyfin AND Plex. Let’s say tomorrow there’s a brand new video file format and Jellyfin supports it and Plex doesn’t. Jellyfin needs to use some new version of ffmpeg that Plex cannot use. The solution? Containers.
Each program is containered with what it needs to run happily. Nothing more. Your machine does the rest.
https://training.linuxfoundation.org/networking/
It seems they don’t have anything on networking exactly, but maybe some of their stuff on container orchestration can be helpful https://training.linuxfoundation.org/full-catalog/?_sft_product_type=training&_sft_topic_area=cloud-containers
About the domains and reverse proxies, if you are testing or on local network reverse proxy or domain are not needed. If you want to access it outside of your network they make more sense.
But also for my services I use https://tailscale.com/ and that way I avoid dealing with domain and reverse proxies by instead just connecting to my local network remotely.