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.

AFAIK I’m neurotypical… No, trains of thought like these are common (see also other respondents on here), and they can also happen in the blink of an eye. It’s just that when the question or comment has formed, I’ll make a mental note to either ask/mention it later after the current topic has concluded, if I think the other person also has interest in hearing it, or to google it later if not. Or to just drop the thought if I come to the conclusion that it doesn’t matter all that much to myself either.

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

No