this post was submitted on 17 Oct 2025
27 points (100.0% liked)
Selfhosted
60409 readers
420 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.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.
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 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can use rootless caddy via systemd socket activation, here's a basic setup:
And that's it really.
You can find a few more examples over here: https://github.com/eriksjolund/podman-caddy-socket-activation
Systemd socket activation has a few more interesting advantages on top of unlocking binding priviliged ports:
--network nonewhile still being able to connect to it via systemd socket, pretty neat to expose some web app while completely cutting its own external access.Drawbacks is that the file descriptor binding is a bit awkward and not always supported (caddy/nginx/haproxy do support it though). And that podman pods / kube do not support it (or at least not yet).
It seems that I'd still need to modify
net.ipv4.ip_unprivileged_port_start=80in sysctl, which I don't want to do. If I do it, the socket isn't even strictly necessary.TBH I haven't played with passing caddy's podman network to other containers, mine is a simple reverse proxy to other standalone containers but not directly connected via
podman run --network(or quadlet network). In my scenario I can at least confirm thatnet.ipv4.ip_unprivileged_port_startdoesn't need to be modified, the only annoyance is that I cannot use a systemd user service, even though the end process doesn't run as root.EDIT: Actually looking at the examples a bit more closely I think the primary difference with my setup is that the systemd socket is started with
systemd --userwhich thus requires the sysctl change, whereas I'm not using a systemd user service, relying instead onUser=some-non-root-userto use rootless podman, but requiring root privileges to manage the systemd service.