For a high security context, you would want to figure out private inter-pod networking.
For what you describe, host networking sounds OK.
this post was submitted on 12 Mar 2025
21 points (95.7% liked)
Selfhosted
44306 readers
1 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
I'd stick to using the host IP for communication between pods. It keeps the separation of different pods intact, makes it easier to add new services and if you ever get a second machine for containers you can continue doing it the same way just with a different IP.
I made a comment on another post a while ago, talking a bit about inter-container/pod networking.
It seems simple. Does it use pasta as the default networking backend? Also, I guess separating each app into their own network is added security, right? So if anything happens to one app, it cannot move laterally to the other apps unless it manages to gain access to the reverse proxy, which then it would be a huge problem.
I looked up when pasta became the default networking backend for rootless and it seems to have been with podman 5.0. I do remember using podman 5.x versions, so I was most likely using pasta.
The reason why I seperated each app into their own network was indeed for security. The only container with access to all the networks is the reverse proxy.
One more question, how did you manage to get the reverse proxy to proxy your pods? I just added two containers to one, and I cannot access the containers anymore by their names. Do I need to expose their ports on the pod configuration?
Containers within a pod can use localhost to access each other. Containers outside of the pod needs to use the pod name to access the containers in the pod.
I agree that you’ll want to figure out inter-pod networking.
In docker, you can create a specific “external” network (external to the docker container is my understanding) and then you can attach the docker compose stack to that network and talk using the hostnames of the containers.
Personally, I would avoid host network mode as you expose those containers to the world (good if you want that, bad if you don’t)… possibly the same with using the public IP address of your instance.
You could alternatively bind the ports to 127.0.0.1 which would restrict them from exposing to internet… (see above)
So just depends on how you want to approach it.
Personally, I would avoid host network mode as you expose those containers to the world (good if you want that, bad if you don’t)… possibly the same with using the public IP address of your instance.
My instance is only exposing the HTTP/HTTPS ports, those are the only ports enabled in the firewall.
Sounds like you should be good there then!
I've started using this method in the past weeks and it mostly does what I want it to do: https://github.com/eriksjolund/podman-caddy-socket-activation/