Btw, nice read OP. Always great to see more Nix “in the wild”.

Yeah, but no dark magic involved.

• build image
• copy to proxmox ISO store
• import, resize disk
• start, wait to come online
• read ssh pubkey, save it
• rekey secrets
• rebuild VM

The only “magic” parts are two nix modules for handling proper networking and hardware setup, and exposing required attributes to the script.

Works really well, zero manual config (beyond the services you want to run…) required on nix or proxmox side.

Nothing. People fearmonger

Funny - same thing here. Got 3 proxmox hosts running, all virtual machines are NixOS though.

I’d love to go full Nix, but between my GF and I, we kinda split the responsibilities: hardware is hers, applications are mine. And there’s not a chance she’ll give up her Proxmox hosts 😄

Got it automated to a single “provision” command though that will spin up any of my nix VMS unanttended, so I’m happy with that.

Think about it like this:

• with ansible, you are responsible for making sure that executing the described steps in the described order leads to the desired result

• with nix, you describe what you want your system to look like, and then figuring out how to get there is nix’s problem (or rather, is obvious to nix thanks to nixpkgs)

?

Better open a package request (or pull request :D) then 😄

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.

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:

• put jellyfin behind a proper reverse proxy. Ideally on a separate host / hardware firewall, but nginx on the same host works fine as well.
• create subdomain, let’s say sub.yourdomain.com
• forward traffic, for that subdomain ONLY, to jellyfin in your reverse proxy config
• tell your relatives to put sub.yourdomain.com into their jellyfin app

All the fear-mongering about exposing jellyfin to the internet I have seen on here boils down to either

• “port forwarding is a bad idea!!”, which yes, don’t do that. The above is not that. Or
• “people / bots who know your IP can get jellyfin to work as a 1-bit oracle, telling you if a specific media file exists on your disk” which is a) not an indication for something illegal, and b) prevented by the described reverse proxy setup insofar as the bot needs to know the exact subdomain (and any worthwhile domain-provider will not let bots walk your DNS zone).

(Not saying YOU say that; just preempting the usual folklore typically commented whenever someone suggests hosting jellyfin publicly accessible)

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:

• help you scam people
• provide a meditation partner
• help you learn how to code in Cobol
• give travel tips
• …

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.

FWIW, I have no issues sending mails/having them be received from my self-hosted to Google mail

On many trackers, you get “paid” for time seeded. Usually in the forms of bonus points or the like. You can then exchange these for improving your ratio (or a freeleech token, or an invite,…).

It’s a system that also rewards keeping media available even if you are not uploading to anyone.

Also, keep in mind that often, a large part of the available content is freeleech (meaning leeching it doesn’t affect your ratio), but seeding those torrents usually still does improve your ratio.

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.