That base set is what’s the problem, I don’t think places sell that, they might either sell you an assembled keyboard, or the PCB and connectors for you to solder and add your controller, switches, key caps, etc.

Honestly look for something preassembled in the form factor you want with hot swappable switches. For example my old keyboard was a RedDragon k530 with brown switches is an excellent 60% model that you can get with your preferred switches and if you want to change them in the future (I for example changed mine for some silent ones, plus added some padding and o-rings to make it extra quiet).

If you want split ortholineal keyboards the Moonlander is a great choice, although I never got one because they’re too expensive and shipping is not great to Europe. Personally I quite enjoyed soldering my own crkbd kit, but I know it’s not for everyone.

Lots of questions, let’s take it one step at a time. You have a domain, now you can point it to your public IP, so that whenever someone tries to access example.com they ask their DNS server and it replies with 10.172.172.172 (which btw is not a valid public IP). Now that request will hit your router, you need to configure your router to redirect ports 80 and 443 to 192.168.200.101, that way the request to example.com gets to your local machine.

Ok, so now you need your local machine to reply on that port, I recommend using Caddy it’s very easy to setup, but NGIX is the more traditional approach. A simple Caddy config would look like:

example.com {
    respond "Hello"
}


jellyfin.example.com {
    handle {
        reverse_proxy http://192.168.200.101:1020/
    }
}

So after the request reaches Caddy it will see that the person tried to access, example.com and respond with a “Hello”.

If instead you had tried jellyfin.example.com the DNS would have sent you to 10.172.172.172, your router would send that to 192.168.200.101, Caddy would then send it to 192.168.200.101:1020, which is Jellyfin so that would get returned.

There are some improvements that can be made, for example if both caddy and Jellyfin are docker you can share a network between them so Jellyfin is only exposed through caddy. Another possibly good idea is to add some authentication service like Authelia or Authentik to harden stuff a little bit. Also as you might have noticed Caddy can forward stuff to other computers, so you can have one machine on your network exposing multiple services on multiple machines.

If you’re using jellyfin as the url, that’s an easily guessable name, however if you use random words not related to what’s being hosted chances are less, e.g. salmon.example.com . Also ideally your server should reply with a 200 to * subdomains so scrappers can’t tell valid from invalid domains. Also also, ideally it also sends some random data on each of those so they don’t look exactly the same. But that’s approaching paranoid levels of security.

They did that with most of my subdomains

The stack might be anywhere, mine has DOCKGE_STACKS_DIR=/home/services because that’s where I keep my stack. That’s the only value, there aren’t 2, so not sure what you meant in the other comment with “they match 99% of the time”

You don’t need to, as long as our stack is all in one folder you just point it to that folder and it will work

Ok, so you said put together your own keyboard, that involves soldering. However it’s very likely you don’t need to.

Finding which switches you like is a good first step, as a general rule I think there’s only 3 types of switches you should worry about, let’s call them Red, Brown and Blue since that’s the colors Cherry MX uses for them so they’re sort of the standard. Red are fully linear, i.e. they feel the same from start to bottom. Browns have a small bump midway through (when the switch activates). Blues are like Browns but they also make a click sound. Only choose colicky switches if you have a room for yourself, they can be VERY annoying to other people, be considerate. That being said it’s personal preference, I personally like Browns although I have used Reds and honestly I don’t feel that much of a difference.

Next important is figuring out the size you want, do you plan on moving it a lot? If so a smaller form size might be better.

Then there are some ergonomics, personally I love Split ortholinear keyboards, you can buy premade ones but for me it was cheaper to build one for myself, but I’m okay with soldering. That being said if you’re going to solder, I STRONGLY recommend you get a nice modern USB-C pen style soldering iron, I bought a cheap one from Amazon and it was very difficult to use, didn’t heated up properly and had a very large tip (the small one never got hot enough to melt the solder).

I recently had a weird bug with Jellyfin, are you by chance using a domain name? Try accessing Jellyfin using direct IP, e.g. http://192.168.1.123:8096/

There are great apps that provides a way of organizing such libraries which you should do to have stuff organized regardless of problems with JF. They’re called Sonarr for tv shows and Radarr for movies, they also provide other features, but their media organization is great

No need to apologize, it’s a weird choice from Plex, I would have never guessed that this is how it works if I hadn’t suffered outages myself, and I’m amazed that not many people call them out on this, it seems completely against what most self-hosting people are looking for, but they seem to defend Plex with teeth and nails.

First of all I agree with most of your a, b and c points, just would like to point out that while it’s true that Docker containers provide an extra level of security they’re not as closed down as people sometimes believe, but as a general rule I agree with everything you said.

But you’re wrong about the way Plex works, this is a quote from their documentation:

So, your Plex Media Server basically “relays” the media stream through our server so that your app can access it since the app can’t connect with your server directly.

If that’s not clear enough:

Your security and privacy is important to us. When you have enabled secure connections on your Plex Media Server, then your streaming will continue to be secure and encrypted even when using our Relay feature. (When using secure connections, the content is encrypted end-to-end and tunneled through our Relay. The connection is not terminated on our servers and only your Plex Media Server has the certificate.)

So it’s very clear data is streaming through their relay server, which goes back to my original point of I expect that to be a paid feature, it’s using bandwidth from their relay servers.

As for the security again you’re wrong, authentication happens on the Plex remote server, not on your local one, which is why you can’t use Plex without internet (part of my dislike for them). So you connect to Plex remote server and authenticate there, you then get a client that’s talking to the remote server, even if someone was able to bypass that login they would be inside a Plex owned server, not yours, they would need to then exploit whatever API exists between your home server and that one to jump to your machine, so it’s an extra jump needed, again similarly to having Authelia/Authentik in front of Jellyfin.

You are, authentication on the VPS, you’re relying on Jellyfin authentication against the internet. Correct me if I’m wrong, but this is your suggested setup: [home server] Jellyfin -> [remote server] Reverse Proxy -> [remote machine] users. Let’s imagine a scenario where Jellyfin has a bug that if you leave the password empty it logs you in (I know, it’s an exaggeration but just for the sake of argument, an SQL injection or other similar attacks would be more plausible but I’m trying to keep things simple), on your setup now anyone can log into your Jellyfin and from there it’s one jump to your home server. On Plex’s solution even if Plex authentication gets compromised the attacker only got access to the remote server, and would now need to find another vulnerability to jump to your Plex at home.

Putting something like Authelia/Authentik on a VPS in front of Jellyfin is a similar approach, but the Jellyfin client can’t handle third party authentication AFAIK

For remote streaming they do, here are their docs on it https://support.plex.tv/articles/216766168-accessing-a-server-through-relay/

From that documentation:

So, your Plex Media Server basically “relays” the media stream through our server so that your app can access it since the app can’t connect with your server directly.

No, the article only mentions the feature by name, the docs for the feature mentions the relay https://support.plex.tv/articles/216766168-accessing-a-server-through-relay/

Using a relay server to separate online from home connection

It’s not, not directly at least, and that’s what everyone is ignoring here. You probably understand the value on Authelia/Authentik but you’re failing to see that the Plex relay server is taking that same mantle here, so even if someone managed to compromise the relay server it’s still not on your home server, whereas exposing jellyfin directly to the internet only requires one service to be compromised.

In some way is different from directly, on Plex you’re behind a relay server so it’s akin to being behind a VPS running Authentik/Authelia in front of the service on your home. Compromising the relay server does not necessarily compromises your home server, so it’s not direct like putting Jellyfin on a reverse Proxy would be.

That exposes Jellyfin to the internet

That exposes Jellyfin to the internet, so it’s not the same feature

That exposes Jellyfin to the internet, so it’s my option 1.