

OK, add step above: use wildcard certificate for your domain.
Terminating the TLS connection at your perimeter firewall is standard practice, there’s no reason your jellyfin host needs to obtain the certificate.
OK, add step above: use wildcard certificate for your domain.
Terminating the TLS connection at your perimeter firewall is standard practice, there’s no reason your jellyfin host needs to obtain the certificate.
Actual answer for 3:
All the fear-mongering about exposing jellyfin to the internet I have seen on here boils down to either
(Not saying YOU say that; just preempting the usual folklore typically commented whenever someone suggests hosting jellyfin publicly accessible)
How good is it with background activities?
About the only thing holding me back is that my phone runs a continuous glucose monitor, constantly connecting with a small sensor in my arm. That all quietly dying in the background would just… not be an option.
Yyyyyyupp
“Oh no, this device is rooted! :(” Yes because I know what I am doing, now show me my account balance you stupid piece of ahit banking app.
No, mate. I don’t need a guide, or a tour. Just a single clarifying sentence.
“My product does x”. Right now, x could be:
What does your product DO? And dong you dare answer “it helps you make money”, that does not explain anything.
I have clicked every link on that site and I still have exactly zero clue wtf this is.
Ah, my bad then! I didn’t see a repo linked in the post or on the site. That’s great, then!
Cool idea. But since it doesn’t seem to be open source and self-hostable, I won’t trust it.
FWIW, I have no issues sending mails/having them be received from my self-hosted to Google mail
Sorry, I should have mentioned: liking bare-metal does not mean disliking abstraction.
I would absolutely go insane if I had to go back to installing and managing each and every services in their preferred way/config file/config language, and to diy backup solutions, and so on.
I’m currently managing all of that through a single nix config, which doesn’t only take care of 90% of the overhead, it also contains all config in a single, self-documenting, language.
Nice. My partner has a Proxmox setup, so we’ve adapted the Nix config to spin up new VMs of any machine with a single command.
NixOS :)
Maybe I should have clarified that liking bare-metal does not imply disliking abstraction
Containers != services.
I don’t think I am better than anyone. I jumped into these comments because docker was pushed as superior, unprompted.
Installing and configuring does not an expert make, agreed; but that’s not what I said.
I would say I’m pretty knowledgeable about the things I host though, seeing as I am a contributor and / or package maintainer for a number of them…
They are using a hosting provider - their dad.
“The cloud” is also just a bunch of machines in a basement. Lots of machines in lots of “basements”, but still.
OK, but I’d rather be the expert.
And I have no troubling spinning up new services, fast. Currently sitting at around ~30 Internet-facing services, 0 docker containers, and reproducing those installs from scratch + restoring backups would be a single command plus waiting 5 minutes.
No, I actually think that is a good analogy. If you just want to have something up and running and use it, that’s obviously totally fine and valid, and a good use-case of Docker.
What I take issue with is the attitude which the person I replied to exhibits, the “why would anyone not use docker”.
I find that to be a very weird reaction to people doing bare metal. But also I am biased. ~30 Internet facing services, 0 docker in use 😄
I would say yes, it’s still self-hosting. It’s probably not “home labbing”, but it’s still you responsible for all the services you host yourself, it’s just the hardware which is managed by someone else.
Also don’t let people discourage you from doing bare-metal.
Yeah why wouldn’t you want to know how things work!
I obviously don’t know you, but to me it seems that a majority of Docker users know how to spin up a container, but have zero knowledge of how to fix issues within their containers, or to create their own for their custom needs.
Which shouldn’t really be an issue since you should only host on 443, which tells bots basically nothing.
Configure your firewall/proxy to only forward for the correct subdomain, and now the bots are back to 0, since knowing the port is useless, and any even mildly competent DNS provider will protect you from bots walking your zone.
I host it publicly accessible behind a proper firewall and reverse proxy setup.
If you are only ever using Jellyfin from your own, wireguard configured phone, then that’s great; but there’s nothing wrong with hosting Jellyfin publicly.
I think one of these days I need to make a “myth-busting” post about this topic.