Selfhosted
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!
view the rest of the comments
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_start
doesn'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 --user
which thus requires the sysctl change, whereas I'm not using a systemd user service, relying instead onUser=some-non-root-user
to use rootless podman, but requiring root privileges to manage the systemd service.