I’ve given this a read.
https://homelabstarter.com/homelab-networking-basics/

Covers the basics, explains them well & technically, and points to “further learning”.

I’d start with learning some networking basics.
Subnets, default gateways, DNS, routes, VLANs.

Then get another computer to install proxmox on.
Learn VMs, SSH, firewalls, basically Linux. Probably VPNs as well.

Then set up a VM and play with docker & docker-compose.

And that’s most of the tooling to be able to self host anything. A VM with docker, set up the docker compose of what you want, boom: done.
Some projects are more of a “full of” kinda thing (like home assistant), which would be its own VM

Yeh, exactly.
And the “dynamic DNS” part handles your public IP address changing with 0 pain.
You either buy a domain (like example.com), or there are free domain name providers that give you a subdomain (like mycooldomain.example.com) of one of their domains.
You then run an additional service on your home server that checks what the current public IP address is. If it changes, it notifies the DNS responsible for your domain/subdomain, which then points to your new public IP.
To connect to your VPN, you only ever care about “mycooldomain.example.com” and never the underlying IP address.

…
As long as your ISP isn’t running CG-NAT of course 😵‍💫

“Frank”, it I don’t think that name is in the same ballpark as you are looking for.

Mumble is fantastic.
I designed and implemented a very complex voice system for an old guild. Like 100 people, 8 groups of 15, group leader’s private chat, priority speech all that. It worked so well, and never failed.
This was many many years ago, to be fair.
I wish it’s positional audio was more supported.

Mumble was awesome. It probably still is, to be fair

Wireshark*

I love cli and config files, so I can write some scripts to automate it all.
It documents itself.
Whenever I have to do GUI stuff I always forget a step or do things out of order or something.

Pretty much any mikrotik is a fantastic piece of kit to have.
It is so unbelievably versatile.
I love the various mikrotik routers, switches and APs I have. I use them all the time for little ad-hoc networks and projects and stuff.
You will learn a lot about networking when using them.

But Unifi is a hell of a lot easier to use, and I have not found anything I can’t do on unifi (but I don’t do bgp, mlag, etc at home).

Oh, and on the “fail often” thing…
Get a basic/old/free pc/laptop and install Proxmox on it.
Loads of tutorials out there, but the basic installer will get you to a “I’m learning” stage.

Create a VM, install Debian, play around.
Then: create a new VM, install Debian, create a snapshot, play around until it does what you want, restore the snapshot, do the steps that got you from vanilla to what you want. Create snapshots along the way as checkpoints. Snapshot, tinker, restore snapshot, advance.

Proxmox is amazing for learning VMs and server things

Raspberry pis are an easy intro to actually using computers (instead of using something like windows).
Raspbian is great (based on Debian) and there is a HUGE community for it.

So yeh, it’s a great started for $25, as long as you have a PSU and SD Card. And an hdmi cable + monitor + keyboard at your disposal (and a mouse if you are installing a desktop environment (IE something like windows, whereas headless is a full screen CLI).
And don’t get your hopes up for a windows replacement.

But… Why not run a Virtual Machine? If you have a windows machine, run VirtualBox, create a VM and install Debian on it?
That’s free. You can tinker and play.
And the only thing you are missing from an actual raspberry pi is that it isn’t a standalone device (IE your desktop has to be on for it to be running), and it doesn’t have GPIO (ie hardware pins. And if this is your goal, there are other ways).

If you really really want a computer that is on all the time running Linux (Debian, a derivative (like raspbian) or some other distro) - aka a server - then there are plenty of other options where the only drawback is lack of GPIO (which, in my experience, is rarely a drawback).
And that is literally any computer you can get your hands on. Because the raspberry pi trades A LOT for its form factor, the ethernet speed is limited, the bus speed is limited (impacting USB and ethernet (and ram?)), the SD card is slower and will fail faster than any HDD/SSD. The benefit is the GPIO, the very low power draw, and the form factor - rarely actually a benefit.

I’d say, play around with some virtual box VMs. See what you want, other than Fear Of Missing Out (things like PiHole? They run on Debian, or even in a docker container). Then see if you actually want a home server, and what you want to run on it.
It’s likely you won’t want a raspberry pi, but a $150 mini pc that can actually do what you want.

Ah, fair.

3x minisforums MS-01

A NAS as bare metal makes sense.
It can then correctly interact with the raw disks.

You could pass an entire HBA card through to a VM, but I feel like it should be horses for courses.
Let a storage device be a storage device, and let a hypervisor be a hypervisor.

especially once a service does fail or needs any amount of customization.

A failed service gets killed and restarted. It should then work correctly.
If it fails to recover after being killed, then it’s not a service that’s fully ready for containerisation.
So, either build your recovery process to account for this… or fix it so it can recover.
It’s often why databases are run separately from the service. Databases can recover from this, and the services are stateless - doesn’t matter how many you run or restart.

As for customisation, if it isn’t exposed via env vars then it can’t be altered.
If you need something beyond the env vars, then you use that container as a starting point and make your customisation a part of your container build processes via a dockerfile (or equivalent)

It’s a bit like saying “chisels are great. But as soon as you need to cut a fillet steak, you need to sharpen a side of the chisel instead of the tip of the chisel”.
It’s using a chisel incorrectly.

I would always run proxmox to set up docker VMs.

I found Talos Linux, which is a dedicated distro for kubernetes. Which aligned with my desire to learn k8s.
It was great. I ran it as bare-metal on a 3 node cluster. I learned a lot, I got my project complete, everything went fine.
I will use Talos Linux again.
However next time, I’m running proxmox with 2 VMs per node - 3 talos control VMs and 3 talos worker VMs.
I imagine running 6 servers with Talos is the way to go. Running them hyperconverged was a massive pain. Separating control plane and data/worker plane (or whatever it is) makes sense - it’s the way k8s is designed.
It wasn’t the hardware that had issues, but various workloads. And being able to restart or wipe a control node or a worker node would’ve made things so much easier.

Also, why wouldn’t I run proxmox?
Overhead is minimal, get nice overview, get a nice UI, and I get snapshots and backups

I’ve never installed a package on proxmox.
I’ve BARELY interacted with CLI on proxmox (I have a script that creates a nice Debian VM template, and occasionally having to really kill a VM).

What would you install on proxmox?!

In that case, maybe look into proxmox and VMs.
Then run docker inside a VM. Have multiple VMs of docker for different environments (eg a VM for containers that should only use a VPN, another for media server stuff, another for experimenting… Whatever)

Learning proxmox (or another hypervisor) is well worthwhile, because the base installer sets things up to just work for virtualization. And VMs are great for learning to run services.
Then you can spin up VMs for isolating environments, and have the benefit of oversight and management tools as well as snapshots. Snapshots means you can take a snapshot, tinker and break things, then roll back to a known good snapshot and try again.

I use proxmox on any bare metal before I start setting up VMs for services. Even if it’s just a single VM with the majority of resources allocated to it.

Is proxmox overkill for running a server for some docker containers? Yes.
Does it make things easier? IMO, yes. At least operationally safer/easier.

Imo, only services that require a VPN exit node should use a VPN exit node.

https://github.com/qdm12/gluetun
Is a well known VPN container that people use, and works with ProtonVPN.

I don’t know anything about how to do this, but a cursory search for “gluetun qbitorrent docker” suggests that gluetun gets network: "host". Any container that has to use a VPN exit node gets network_mode: "service:gluetun". A depends_on: {gluetun details} style option will ensure that any service that should use a VPN exit node will not run unless gluetun is running.

Then it’s getting the data out of the qbittorent container into whatever you are using as a media server.

Ah, gotcha.

So… You generally have to pay a VPN company to get access to their VPN exit nodes, and “hide” in among all the other traffic.
There is nothing you can self-host to do that.

ProtonVPN used to be a popular recommendation, however they are slipping out of favour due to behaviour over the last couple of years.
If you are looking for a VPN for anonymity, be careful of “review” articles posted on blogs owned by dodgy VPN providers.
I’m not sure who the “go to” VPN provider is these days.

If you rent a VPS (virtual private server) in order to run your own VPN exit node, and the VPS provider gets a letter regarding illegal activity, then your VPS will be deleted.
I don’t know of a VPS provider that will protect customers privacy WRT legal requests (maybe there are, but they will be exceptionally expensive).

So everyone pays a VPN provider that doesn’t keep logs in order to hide amongst the herd.

In order to make sure that your file downloading system uses a VPN instead of the default gateway for internet access is a huge field.
So you need to describe exactly the software you want to use the VPN exit node, and how it’s installed.
Because the solution could be host firewall, docker networking, isolated networks… Pretty sure there are many others.