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.

Sorry, saw this only just now. I don’t really have any guides to point to, so just the basic steps:

• host jellyfin locally, e.g. on http://192.168.10.10:8096/
• configure some reverse proxy (nginx, caddy, in my case it’s haproxy managed through OPNSense)
• that proxy should handle https (i.e. Let’s Encrypt) certificates
• it should only forward https traffic for (for example) jellyfin.yourdomain.com to your Jellyfin server
• create a DNS entry for jellyfin.yourexample.com pointing either to your static IP, or have some DynDNS mechanism to update the entry

90% of this is applicable to any “how to host x publicly” question, and is mostly a one-time setup. Ideally, have the proxy running on a different VM/hardware, e.g. a firewall, and do think about how well you want/need to secure the network.

In any case, you then just put in https://jellyfin.yourdomain.com/ in the hotel TV.

I have never used Tailscale. I have also Jever seen anyone in the wild recommend it and explain what exactly the use-case is beyond plain, old, reliable, open source WireGuard.

So yeah, agreed.

Also I have been hosting Jellyfin publicly accessible for years with zero issues, so idk… I also dint k ow what the “you have to use Tailscale for jellyfin” people are doing with TVs/Firesticks/… in hotels, airbnbs,…

Are we talking permanent background tracking? Or sending a message “hey, I’m here”?

For manga, I’ve found Mihon to be nicest, by far, and it supports the API. For books, I am currently “stuck” on koreader on Android (which “only” supports OPDS-PS). I do most of my reading on a reMarkable currently, and that has no supporting client. Writing one is on my to-do list, but it’s a bit daunting of a task…

Here is a pretty good list of what is supported where.

I think I have set Suwayomi to download / convert to CZB, not for Kavita specifically, but because a lot of reader apps cannot handle loose images

Haven’t had any issues in that regard, so can’t really say, sorry. I have two folders (Mangas and ebooks) on my NAS, and in Kavita, created a library for each.

You absolutely can edit metadata, although I personally haven’t had the need yet. I use readarr and suwayomi for “obtaining” books and manga, respectively, and what they come up with is usually just fine.

I went through essentially the same thing a couple months ago. Tried Calibre (and Calibre server) since everyone recommended it.

Really disliked it. Calibre is great for converting ebooks, but has shit management and webserving capabilities.

I ended up with Kavita and am super happy. On the web client, both management and actual reading are a pleasure. Any phone/tablet client supporting OPDS works perfectly to read/download your manga/books from the server.

And a select few clients go a step further, supporting Kavita’s API, which allows for 2-way sync (effectively, syncing reading progress between all your devices).

Yeah but conduit is so stale, it might as well be discontinued

I still find it hilarious that since dd-wrt and OpenWrt are just… Linux, you could install Super Mario Bros on there. I checked, nobody seems to have tried.

Oh, definitely, but there are varying degrees of difficulty, esp. with what kinds of packages / package management you have available :D

Ah, that make sense. Is Wireguard P2P?

Yes, in the sense that each node/device is a peer. But the way I’d suggest you configure it in your case is more akin to a client/server setup - your devices forward all traffic to the “server”, but it never takes initiative to talk “back” to them, and they do not attempt to communicate with each other. Unless you have a separate usecase for that, of course.

You both are perfect for each other, so don’t screw it up!

❤️

Closing in on 8 years

I’m actually surprised nobody suggested simply using the Pi with OpenWrt as my own router. Though, that would make it hard to host Jellyfin.

A brief internet search shows that surprisingly, hosting Jellyfin on OpenWRT should work… No idea how well though. Come to think of it, having OpenWRT on the pi might make it a lot easier to configure, with graphical settings available and so on.

Could you explain Wireguard vs. Tailscale in this scenario?

I’ve never used tailscale, I’m afraid. Normally I would say: just use whatever seems easier to set up on your device/network; however, note that tailscale needs a “coordinate server”. No actual traffic ever goes through it, it just facilitates key exchanges and the like (from what I understand), but regardless, it’s a server outside your control which is involved in some way. You can selfhost this server, but that is additional work, of course…

Thank you all so much for your help! This is likely the solution I will go with, combined with another one, so again thank you so much!

Glad I could help, after being so unhelpful yesterday :)

P.S. I don’t care if you wrap an ethernet cord around her finger, get going!

Eh… Marriage is not really common in either of our families. We agreed to go sign the papers if there ever is a tax reason, lol. Sorry if that’s a bit unromantic :D Nice rings though ^^

Hi again.

How about the following idea:

Set up ProtonVPN on the raspberry pi.

On all other devices (or at least those you want to use Jellyfin on), switch from using Proton to using Wireguard. Unlike your phone, the raspberry pi has no trouble running multiple VPNs. I think the ProtonVPN limitations in regard to not allowing split tunneling don’t apply here, since all outgoing traffic will still go via Proton.

Essentially, the Pi would function as a proxy for all of your traffic, “and also” host Jellyfin. You would still connect to http://192.168.20.10:8096/ (or whatever) on your devices, but that address would only resolve to anything when you are connected to the pi via Wireguard. No HTTPs, but “HTTP over Wireguard”, if you will.

Nots that this requires you trusting the pi to the same degree that you trust your phone.

For your static devices (PC, TV) this should solve the problem. Devices which you take with you, like your phone, unfortunately will loose internet connectivity when you leave your home until you switch off Wireguard, and switch on Proton, and not be able to connect to Jellyfin when you return home, until you switch them back.

Essentially, you would have a “home” VPN and a “on the go” VPN, though you never need to connect to both. There might be ways to automate this based on WiFi SSID on Android, but I have not looked into it.

The Pros:

• this should meet all your requirements. No additional expenses, no domain, no dynDNS; no selfsigned certificate or custom CA; traffic is never unencrypted; works on all common devices.
• Wireguard is sufficiently lightweight to not bog down the pi, normally
• this is actually well within the intended use-cases for Wireguard, so no “black magic” required in configuring it
• if you ever do decide to get a domain, you can configure everything to always be connected to your pi via Wireguard, even on the go! Not required though.

The Cons:

• when you are new to selfhosting, Wireguard is a bit daunting to set up. It is not the easiest to debug (don’t worry, it’s easy to tell IF it is working, but not always WHY it isn’t working). Some manual route handling is probably also required on the pi. It should definitely be doable though, but might turn this Jellyfin thing from a weekend project to a 2 week project…
• I have no experience with how well the pi runs Jellyfin. If the answer is “barely”, then adding multiple concurrent Wireguard sessions might be a bad experience. Though in this case, you could only switch Proton to Wireguard whenever you want to watch Jellyfin.
• the manual switching might be annoying, but that is the price to pay here, so to speak

Edit: someone else already mentioned setting up your own trusted network with a second router. IMO that is the better, more hassle-free option IF you are willing to shell out the money. My suggestion is the “free” version of that, essentially 😄

Hi again. Sorry for being so rude yesterday. Your new post actually clears the situation up a lot.

We might have an idea for you, will comment on the new post.