I want to expose my services publicly on my own domain name, how would you guys do that?
I have seen people using Cloudflare, but I don’t want to use Cloudflare out of principle. I have also seen stuff on caddy and frp that I’ve done some rough researching.
What do you guys do?
You must log in or register to comment.
A reverse proxy is the traditional safe route. Use a web server like Apache, nginx or caddy, and setup to reverse proxy all your services through port 443, and use let’s encrypt and certbot to generate and manage TLS certificates.
I host around 15 public facing web services this way using nginx.
Just be aware, this is very public facing so server security and hardening is important. Things like strong passwords, disabled root, use ssh keys instead of passwords, setup fail2ban, setup crowdsec etc.
The more modern safer way is not to truly expose to full public and use things like tailscale or cloudflare tunnels. But this relies on 3rd party servers and I’m not a fan of that, but it does bring benefits.
Authentication & single sign-on service
Plugged into Reverse proxy, routing to each service by name
With a wild card cert so there are no name leaks.
Make your urls unexpected. If your domain is example.com, don’t put your jellyfin server at jellyfin.example.com. Instead, use watch.example.com or telly.example.com. Anything that’s memorable to you about what the service is without using a specific brand name.
With a wildcard dns record to point all names to your IP, and a wildcard certificate that works for all names loaded on your load balancer, it becomes hard for a hacker to know what name to use to get the load balancer to send them to the service they want to hack.
If you then use a sso tool like traefik’s ForwardAuth middleware, you won’t even get to the service until you’ve first authenticated.
If you use TLS like you should, your domains will be on the internet in the certificate transparency log. Yes, you should use a wildcard cert if you want this security by obscurity, but it’s still security by obscurity.
Security by obscurity is when the design or archetecture of the system is obscure enough to supposedly styme attackers (it doesnt), and as soon as people understand the design, your security is broken.
A hard to guess unpublished subdomain is a transparent and standard archetecture - nothing obscure about it and publishing that you use such a scheme doesnt break the security.
The subdomain is a bearer token that serves as an access control and just like a key or passphrase, has a security value proportional to the bits of information an attacker has to guess.
The real limitation is that browsers and humans are not great at not leaking domain names, so its very possible it will get leaked eventually and hard to rotate. Thats the reason they are weak. Still, they can be usefull to stop scanners just trolling for unpatched services.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CA (SSL) Certificate Authority CSAM Child Sexual Abuse Material DNS Domain Name Service/System Git Popular version control system, primarily for code ISP Internet Service Provider SSD Solid State Drive mass storage TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) nginx Popular HTTP server
10 acronyms in this thread; the most compressed thread commented on today has 24 acronyms.
[Thread #74 for this comm, first seen 6th Aug 2026, 09:00] [FAQ] [Full list] [Contact] [Source code]
I recently switched to Netbird on a VPS (on Vultr). Their reverse proxy is super easy to set up / self host. They also offer a free version that works pretty good too, I just wanted to make it difficult for myself (thats the whole point of self hosting, right? )
I have seen netbird pop around every now and again. I might try out their cloud free version first and if I like it I might try self hosting it.
So you host netbird on a vps you rent and that is used for reverse proxy? So with that reverse proxy I can have my home server be publicly accessible and I can have friends log in to my jellyfin server without having to connect to my tailnet.
My last concern is security. How is this set up good for making sure I don’t just get constantly botted and exploited?
Opening jellyfin up publicly is kind of asking for trouble if you ask me. I haven’t done so myself, but seen enough on this community and elsewhere to know that it’s probably not a good idea.
By all means correct me if you know more, but what I tend to see is one or two people here saying that Jellyfin devs don’t recommend exposing it publicly, only to be corrected by looking at the actual documentation. I suspect those cautioning against it are on outdated information and that Jellyfin carries much the same risk as exposing any other service.
but what I tend to see is one or two people here saying that Jellyfin devs don’t recommend exposing it publicly
I think what the devs are saying is ‘don’t expose Jellyfin to the public in an unsafe manner’. I don’t run Jellyfin, but can confirm what you’ve read here. In that vein, don’t expose anything to the public in an unsafe manner.
There is no safe manner of exposing jellyfin.
That first page says exposing it to the Internet is “not recommended”. Putting a reverse proxy in front of it does not meaningfully change the security posture. A malicious request to
http://jellyfin.homelab.com/exploitable-pagewill be sent to jellyfin in effectively the same way, whether through a reverse proxy or not. You would need a WAF set up specifically to look for relevant exploit attempts.https://github.com/jellyfin/jellyfin/issues/5415
Those are some outstanding known vulnerabilities, most of them unfixed. They are not particularly severe, but it shows that thorough security is not a priority for the jellyfin devs.