this post was submitted on 19 May 2025
94 points (96.1% liked)

Selfhosted

46654 readers
972 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Hi everybody.

How should I setup reverse proxy for my services? I've got things like jellyfin, immich a bitwarden running on my Debian server in docker. So should i install something like nginx for each of these also in docker? Or should I install it from repository and make configs for each of these docker services?

Btw I have no idea how to use something like nginx or caddy but i would still like to learn.

Also can you use nginx for multiple services on the same port like(443)?

(page 2) 28 comments
sorted by: hot top controversial new old
[–] jhdeval@lemmy.world 1 points 2 weeks ago (1 children)

Nginx, caddy and haproxy are 3 choice for reverse proxy. The way a reverse proxy works is it looks on port 80 and 443 for requests to a DNS connection. Like say you want to go to jellyfin you may have a DNS entry for jellyfin.personalsite.tld the reverse proxy will then take that and redirect the connection to the proper port and server behind your firewall. You do not need multiple reverse proxies. In the case of haproxy and nginx (only ones I have experience with) you create a "back end connection" like explained above and it will redirect. In the case of nginx it is very small I installed it natively and setup configs for each of my services for easy maintenance.

[–] Octavusss@lemm.ee 0 points 2 weeks ago

Okay and in that case can you please point me in the right direction how should i write the nginx configs for each of my services and also make ssl certificates?

[–] Shimitar@downonthestreet.eu 1 points 2 weeks ago
[–] ippokratis@lemmy.ml 0 points 2 weeks ago (1 children)

While using a web server before your self hosted micro services is the obvious answer and caddy the easier to configure, as a beginner you should also consider taiscale funnels. You dont need to mess with router stuff like port forward or caring if you ISP have your router behind a cgnat which is kinda norm nowadays , also dont have to care for a domain name dynamic DNS stuff . You could have a look to my quick how to . All you need is running a script , the ports and desired names of your subdomains and your tailscale auth key. https://ippocratis.github.io/tailscale/

[–] Octavusss@lemm.ee 1 points 2 weeks ago (1 children)

Well I already got static IP from my ISP and configured Wireguard on my directly on my router so I think I'm good.

[–] ippokratis@lemmy.ml 1 points 2 weeks ago (2 children)

The funnel exposes your local services to the public over https . Like what you want to accomplish with reverse proxy . Its just more straightforward for a beginner.

Personally I closed my router ports and switched to tailscalr funnels after using caddy with mutual TLS for years.

[–] CapitalNumbers@lemm.ee 1 points 1 week ago (1 children)

maybe silly question but does tailscale tunnel operate in a similar fashion to a cloud flare tunnel? as in you can remotely access your internal service over https?

[–] ippokratis@lemmy.ml 1 points 1 week ago

Yes that's exactly what they do

[–] WhyJiffie@sh.itjust.works 1 points 1 week ago (1 children)

The funnel exposes your local services to the public over https . Like what you want to accomplish with reverse proxy .

they did not say they want it public, and that's an additional security burden they may not need

[–] ippokratis@lemmy.ml 1 points 1 week ago* (last edited 1 week ago) (1 children)

He he didnt but thats what he meant

I mean 99% of users use reverse proxy for https public access

Also read the threat replies ...

That's what this thread is about

..........

No?

[–] WhyJiffie@sh.itjust.works 1 points 1 week ago (1 children)

if that's true, I assume it is because they don't know about the security consequences, nor about more secure ways. and for 99% that is the worst solution, because they won't tighten security with a read only filesystem, DMZ and whatnot, worse, they won't be patching their systems on schedule, but maybe in a year.

99% users should not expose any public services other than wireguard or something based on it. on a VPS the risk my be lower, but on a home network, hell no!

[–] ippokratis@lemmy.ml 1 points 1 week ago (1 children)

Ok I'm not any networking expert but I think you are overestimating the risk here.

Opening a port doesn't mean you are opening your whole home network just the specific services you want. And those not directly but with a web server in front of them . Web servers talked in this tgread that sit in front of open ports are well audited . I think that measures like mtls a generic web server hardening are more than ok to not ever be compromised.

But yeah I'm surely interested to listen if you could elaborate.

Thanks

[–] WhyJiffie@sh.itjust.works 1 points 1 week ago

Opening a port doesn't mean you are opening your whole home network just the specific services you want.

until a new high severity vulnerability gets discovered and some bot exploits it on your server, taking it over. and you won't even know. if they were a bit smart, you won't notice it ever either.

but there's more! its not only the reverse proxy that can be exploited! over the past few years, jellyfin has patched a dozen vulnerabilities, some of which allowed execution of arbitrary system commands. one of the maintainers have expressed that nobody should be running those old versions anymore, because they are not safe even only on the LAN. and this was just jellyfin.

load more comments
view more: ‹ prev next ›