127
Self hosting with subdomains
(jackdavies.github.io)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 04 Jan 2026
127 points (97.0% liked)
Selfhosted
62139 readers
537 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. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
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
Good as a general recommendation.
I also feel like the risk levels are very different. If it's something that performs a function but doesn't save/serve any custom data (e.g. bentopdf), that's a lot easier to decide to do than something complicate like Jellyfin.
I do have public addresses for Matrix, overleaf, AppFlowy, immich because they would be much less useful otherwise. Haven't had any problems yet, but wouldn't necessarily recommend it to others.
I'd never host any stuff with "Linux ISOs" on a public adress, that seems like it'd be looking for trouble.
Doesn't matter. Any exposure risks compromise. From there, an attacker could pivot to read your data, mine cryptocurrency on your device(s), serve objectionable material, or other unsavory activities.
Even if you have authentication enabled, not all APIs require authentication. Jellyfin in particular is not designed to be internet-facing. And even if it does require authentication, authentication bypass attacks are a thing.
If you really want to secure your computer, encase that puppy in concrete (after disconnecting it from power),
... sure. Nothing here is wrong, but there's ways to try and mitigate that. And then it's kinda an arms race, and vigilance.
What do you mean JellyFin is not designed to be Internet facing??? https://jellyfin.org/docs/general/post-install/networking/
https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825369811
Designed meaning in that case intended to be exposed.
More of an internal thing.
VPNs on the other hand are designed to be exposed. Same with some ssh servers or reverse proxies like traefik, nginx etc.
So you mean the JellyFin ports should not be directlly exposed, but self hosting and exposing nginx to forward the traffic locally to jellyfin is fine?
Better rather than worse, yes.
Just need to be aware if what you expose and how and where.
So its also not designed to be exposed via nginx?
Please stop nitpicking.
It's as insecure as every other software exposed to the internet.
It's just that some softwares (like Jellyfin) is more prone to be a risk than others (like nginx).
Juat be aware of what you do.