Not that I should even bother, but:

If my recommendations reflect a common consensus in this community, then perhaps there is good reason they are popular, no? In my case, I personally know the person who runs the VPS I rent and do actively trust them. I know that situation isn’t going to be the same for everyone, but if you don’t fully trust your VPS provider, there’s a reason TLS forwarding and ZTT solutions like Tailscale exist.

And sorry my writing isn’t to your expectations, I guess.

My use case has containers and reverse proxy all rootless on a given machine. TLS certs pulled at proxy level. I explicitly group small clusters of relevant services per machine. Authentik and other utilities live on one machine. Things like Jellyfin and Navidrome on another, etc.

The real way to achieve the same using user isolation rather machine isolation (given you’d be having multiple reverse proxies on one machine) is to have a second layer reverse proxy with no TLS or anything, simply handling the routing to the then off-port HTTPS connections published at system level.

For my public-facing stuff, the reverse proxy on my VPS does roughly the same thing, taking my HTTPS connections and either directly forwarding, or decrypting and rewriting the cert to a wildcard one I use if I need packet filtering or other tech for a given service. Having well-defined network ranges and reverse proxies being assigned static addresses (container-level networking or otherwise) helps significantly when working out your trusted proxies config at each layer.

I have a few practices, technologies that I leverage across my systems, network for selfhosting.

First, the principles I follow:

• Least access — Limit exposure of ports, services to as limited an audience as possible.
• Don’t put all your eggs in one basket — Spread your service deployments out across different machines, or at least different users on the same machine. Group relevant services together as seen fit, but don’t deploy everything in the same place.
• Security through obscurity is bad — What I mean is make your process for deploying and maintaining applications easy to read and understand the context. Software versions, customizations, and other tweaks should be easy to find and understand.
• Mind your secrets — Seriously, don’t engage in practices that may lead to exposed secrets. Keep files that may have them out of your git repos. Read your logs before pasting them or feeding them to another application. If it can be done, automate secret deployments where possible.
• Understand your tech — Learning stuff in the context of LAN is perfectly fine and I encourage doing so. For anything that you plan to bring to any wider network though, please do the recommended reading about each component you are using. Security mistakes often come from glossing over something that wasn’t apparent, but was important. Yes, this will slow down your work to a crawl if you’re used to just pulling Docker images and deploying at-will. I still recommend to take the hit in speed in order to do things as right as possible the first time.

Now, onto the actual technologies and practices I use:

First off, as hinted above, I make heavy use of containerized applications. OCI (commonly referred to as Docker) containers are a convenient way for developers to package their applications, but also offer some affordances in security if you leverage the tools well. I personally use Podman as my tool of choice for many reasons, but one of them being the relatively sane rootless setup that is ready to use out of the box. This means that can be started up at user-level (without root permissions and with user-level restrictions), which is great in case of an exploit to escape the sandbox occurs. Combine this with pairing relevant applications together on different users, and an actual semblance of a security model starts to form in mitigating the potential disaster from a rogue container. If you use multiple users on a system, make sure they are isolated users who should not be able to even read another user’s files; don’t give users free sudoers access. I also utilize multiple different machines for different processes, which works as well.

Secondly, I utilize Quadlets, a way to write podman container, pod, network definitions as SystemD units, and be able to hook them in with other SystemD units. I love this approach for many reasons, including having declarative definitions of most of my deployment stack. Certainly makes redeployments, migration, and restoration a breeze when tracked with git. More importantly for security, an easy-to-read set of config files makes managing selfhosting significantly more predictable and boring, which is how it should be. Any question I might have about how something is setup I can find within a minute every time. Less guessing, less searching, more informed decisions; which is crucial to making less mistakes that could have security implications. Practically speaking, there are more than just Quadlets: Docker compose, Kubernetes definitions, Helm charts, and others all exist with their various strengths and weaknesses. Pick what works for you.

With actually exposing stuff to the internet (or at least a broader network), I do limit my machines’ reach where possible. I have the capability to, but do not directly port forward anything from my home router. I rent a small VPS with minimal latency to my location that I use as a forwarding proxy for public services. I have a wireguard tunnel on my home router to the VPS that I let access specific IP ranges that contain my static IP server IPs only, with firewall rules on the router to back the access grant in the tunnel config. From there, I forward traffic to the VPS’s public IP with FirewallD on the edge, or have traffic sit behind a reverse proxy on said VPS.

With most traffic though (especially with services I don’t completely trust to leave exposed), I restrict who and what may gain access to said services. If the model works for you, Zero Trust Tunneling / Mesh Network solutions like Tailscale, Netbird, or Netmaker are of high recommendation. For many of these, they allow you to connect end-user devices and serving devices together over a dynamic Wireguard tunnel (or similar) to share services that normally wouldn’t be as suitable sitting on the open internet. I personally run a selfhosted instance of Headscale which also sits on the edge VPS, and acts as my Tailscale control server and sole traffic relay for connections that can’t be direct peer to peer. Most of my services sit behind the requirement of being in the virtual network, while some I configure dual-offering. I should note that using Tailscale and others that offer direct peer-to-peer will directly expose your devices’ public IPs to others in the network that can interact.

Lastly, I can note that while there have been many efforts with various solutions to try and make selfhosting as mindlessly easy as possible, I don’t recommend running many of them for a very specific reason. Much like how I hate people using LLM chatbots in place of their own brains to try and solve problems, having some container management platform take the initial setup out of selfhosted applications and attempt to abstract away as much of finer details as possible can lead to a fast initial deployment, but certainly not a secure one long-term. I do believe there are many practices and details one should learn about their selfhosting setup (such as networking, firewalls, what each app depends on, how best to upgrade them, when to pin application versions, etc.). Having a platform take that away in the beginning will only lead to problems later down the line when those funny little details start to become more important. Only learning about those details when the problems start to occur becomes a much more monumental hurdle to cross than simply learning the details as you set things up for the first time.

Final Notes

This comment is quite large, even by my standards. Yet, I am sure I have missed something somewhere. I will be happy to reply to any specifics about either technology or practice if I missed anything.

Generally, your auth provider (assuming setup correctly) should be one of the most secure components of your internet-exposed setup. That being said, vulnerabilities can and do occur. Adding a combination of Crowdsec, OWASP CRS, other ModSecurity rulesets, and/or fail2ban will add a degree of migitation of potential exploits by blacklisting known bad actors/active bad behavior.

Above all, you should have a plan to keep aware of updates to your publicly-exposed software and be able to deploy those updates in a timely fashion.

I think the biggest one in recent (past year) would have been the upgrade tree to nvidia-open, which would break 10-series and older support without changing package on affected systems. Definitely a lot of the more recent breakages are not large-scale problems, but they do still exist.

As has been noted in the ArchWiki that is expected to be read by users, one should always check for package-related news before upgrading their Arch system. This is because package changes and breakages that require user intervention do occur, and ignoring them can sometimes leave a broken system. Arch isn’t really hard after getting over the bootstrap hurdle, but simply requires more upkeep effort than most point release distros would.

Based on OP’s edit, that looks correct. Unless OP checks the topology and can make the claim that drives from the main chipset are the slow ones, secondary chipset drives will tend to perform slower, and the ASMedia ASM1061 has several reports online of poor to trash performance compared to baseline.

Best bet if the full performance is necessary out of every drive would be finding a decent quality PCI-E SATA III riser card that doesn’t use a known flawed driver chip rather use the two ‘extra’ ports on the motherboard.

Originally when I started the move to Linux in 2015, I did it because Windows 10 was wholly incompatible with my ISP. I lived through dial-up, HEO satellite, HSPA, LTE, fixed wireless, and currently fiber. During the period with dealing with HEO satellite, every provider at the time in the US (WildBlue/Exede/Viasat, Hughesnet) had alright speeds at best paired with a very aggressive soft monthly data cap (10 GB, eventually 26GB in like 2018), that would revert the speed capabilities back to 32-96kbps. Upgrading from Windows 7 to Windows 10 was largely a mistake for many reasons, but one of them was the sheer frequency, size, and aggressive nature of how Windows 10 tried to download and apply updates automatically. Windows 10’s frequent auto updates would easily eat several gigabytes each month of the tiny data cap. The rest of the amount of idle networking Windows 10 did also didn’t help during throttled periods, eating up most of the bandwidth available from just one workstation. Knowing that Windows 10 wouldn’t be another Windows 8 and that Microsoft would go forward with 10, I decided to seriously look into alternatives.

Eleven years later, I have virtually no restrictions in hardware nor networking. Despite that, I still use Linux exclusively. Nowadays, there is little to no compromise in using a Linux-based system for many general tasks. Certain niches vary in usability on Linux, especially if the niche is cemented in certain proprietary software. Modern Linux-based systems (both distro and desktop environment) are just more polished than the experience to be had on Windows 10 or Windows 11. Many common frustrations when using Windows (device driver installation, printers, drawing tablets, HDR, system updates, software updates, system maintenance, lack of dark patterns, error message clarity, etc.) are things that a modern Linux system deals with a lot less, to a lesser extent, or just not at all. After spending many years learning both Windows and Linux, Linux systems are just more functional and easier to use.

Starting with confirmation of what others have said, yes you can use compose tools with Podman and Podman can hook directly with Docker Compose (the tool), but it really isn’t recommended. Compatibility with compose now is better than it used to be, but there are still edge cases. For a lot of projects that just pre-write a compose file that they expect to cover the general use case of their container, you’re best to take the compose file and write it out to Quadlet unit(s).

Other differences not mentioned can include:

• Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as localhost, 127.0.0.1, or ::1. If you utilize pods for certain split-container applications, you may need to remap certain service ports as they can overlap and cause binding failures.
• Podman has multiple networking modes. If you use Podman at the system level (rootful) like Docker expects you to, you’re not really going to encounter any quirks with the default networking setup. Per-user Podman (rootless) defaults to using the Pasta backend for networking, which is still very highly performant, but is a bit clunky to configure (if ever actually necessary) and inter-pod communication can be difficult to get right. Alternatively, registering rootless pods with a bridge network makes inter-pod communication easy, but can cause problems if accurate source IPs are needed (e.g. upstream reverse proxies, accurate client IP logging, etc.).
• Because Podman is daemonless, there is also no persistent API socket loaded by default (an intentional security choice). For both rootful and rootless containers, you can enable this manually and mount it to containers that need it. For containers that expect docker.sock explicitly for API manipulation, your mount will need to reflect the name change of the podman.socket to what the container expects.
• Podman by default won’t shorthand container pulls from docker.io by default: a sin I see constantly done in so many compose files. When pulling a container from DockerHub, you need to put the docker.io/ prefix, just as you would but the appropriate prefix with Quay, Github, Gitlab, or any other distributor.
• Podman can optionally let you auto-update containers based on the release tag specified for the container.
• Because of Podman’s integration with SystemD, a lot of oddball integrations (external cron jobs, one-shot services, etc.) can be pulled together with extra SystemD units (services, timers, etc.).

Might take a little bit of effort to do a conversion if you’re locked into explicitly how Docker interacts with OCI containers, but over in the Podman camp you have two options.

• Cockpit with the Podman containers interface: a graphical web-based solution for managing podman containers and the rest of the system.
• Podman Quadlets: a config file-based way to manage Podman containers, volumes, pods, networks with custom SystemD units. Great if you want to version control your deployments.

Other than that, the more usable solutions I’ve tried of graphical Docker container management interfaces would be the ones in Unraid and Proxmox, though those solutions may not be suitable depending on your use case and have their own caveats to be aware of.

Coming back and checking the values file posted. Not sure why your authentik block won’t get used in your values file. Your current issue of non-starting is likely the Authentik server container starting successfully, but failing liveness while waiting for the worker container(s) that is definitely not spooling up with your current configuration.

Something to denote about Authentik itself that won’t be well-explained by the quickstart for the Helm chart itself is that Authentik is split into two containers: server and worker. For most environment variabless and mounted secrets, both the server and worker definitions should have them applied. The chart tends to handle most of the essential shared stuff in the authentik block to prevent the duplication, but secrets will likely need to be mounted for both volumes if using file or env references in the shared config, as well as most env overrides will need to be applied for both.

In my case I’m running an external Postgres DB and external cache plus a handful of other settings. As such, I have a decently sized values file. All of the env vars I was looking for in my case are provided in the chart, so I didn’t need to set any directly, but just through their counterparts in the values file.

I don’t use ArgoCD in my case, so I couldn’t really say if it would affect your deployment strategy in any way.

When I did my authentik setup through helm chart a while back, the only real problems I had were with learning blueprints and not so much with getting Authentik to do its thing.

The main things you should be checking given a liveliness probe failure is kubectl -n <namespace> describe pod <podname> to check the reason for failure. Additionally, kubectl logs -p -n <namespace> <podname> [container]. Will get you logs of the last run of the pod that has already failed, rather than the current run that may be soon to fail. Those two commands should point you pretty directly where your chart config has gone wrong. I can likely help as well if you are unsure what you are looking at.

Additionally, once you get things working, please go back and usw secrets properly with the chart. Authentik lets you sub many values for env vars or files, which combined with mounting secrets is how you can use them.

Iproute2 definitely does write things a bit compact. ip address show and shorthands state the routed local address space (192.168.1.x/24) and the actual /32 address (192.168.1.214) you are assigned as one unit. Additionally, it shows the broadcast address for the space. Ironically, ip route show may genuinely give you less confusing information, clearly splitting the actual route and showing your straight IPv4 address as src.

Typically in firewalling, you’d use /32 to target a singular IPv4 host. This is analogous to using /128 for IPv6 hosts. You can absolutely use /24, /16, /8, or any other mask really if you need to target a range of IP addresses for a rule to apply to. Technically, /32 is a range itself, just with a size of 1. There are CIDR calculators available to play around and see what different CIDR masks actually target.

The routing and firewalling is a bit different in terms of why certain CIDR masks are used. For the router, the /24 suffix is usually defined for itself on the LAN interface to denote the address space it may send route information to, and what addresses are controlled by the device. Almost certainly, (unless using a lower CIDR range and actually handing out /24 blocks to subsequent routers,) you are granting /32 IPv4 addresses to your devices from your router.

For your system firewall, 192.168.1.135/24 is identical to 192.168.1.0/24 as they are the same address space. You’re simply allowing from a subnet of hosts to accept from. Given the /24 mask is 255.255.255.0, it does not matter what the last number of the IPv4 address is, but the lowest possible number to match the mask is standard form. Without knowing what rule(s) specifically is being applied, I couldn’t tell you if your firewall rules are something that would affect hostname resolution of other hosts from your system or not.

In addition to the other reply on the fundamentals of why not in general, maybe we don’t recommend daily driving one of DHH’s pet projects.

If anyone is out of the loop of who DHH is, tons of people have covered the topic but I think Niccolò Venerandi has quite comprehensive and digestible coverage. If anyone cares to read or watch Nicco’s coverage.

1 + 2:

There’s not much involved in burning an ISO to a flash drive, booting from it, and installing typically. It is different in booting from one on a Mac. If you have an M-series Mac, you will be restricted mainly to anything with the experimental Asahi Linux kernel. If you have an Intel-based Mac, you should generally be good to go. Whenever booting a Linux installer, you’ll generally be able to check out the system before installing. It’s a good time to check things like backlight brightness and wireless capabilities are working out of the box on your distro of choice.

Accessing the boot menu on a Mac

3:

OpenSUSE Tumbleweed and Fedora are generally good picks. I recommend going for KDE unless you have a strong preference for how GNOME works. As good as the distros are, I generally recommend staying away from distros like Linux Mint (for now) as their implementation of the newer display system called Wayland is not yet complete for Cinnamon. Desktops like KDE and GNOME have functional implementations and will overall provide a solid experience.

4:

You’ll see mixed opinions all over the place with this. Personally, I do sit in the GrapheneOS camp at this point. If you don’t want to purchase a secondhand Google phone, I’d wait and see for the partnered device that GrapheneOS devs are in works with a currently undisclosed manufacturer on.

I’ll repeat the core points the GrapheneOS devs drone on about other Android OSP distributions, but without the hyperbole the devs constantly put in. Yes, e/OS does generally have security problems, some of which stem from the use of microG, and how microG just has to function on the device. It is a trade-off in security for some privacy gained. If you really don’t need anything of Google Play Services at all, you could always go for straight LineageOS without any Google services package installed at that point.

5:

By all means, older laptops can definitely still be functional for lighter or alternative tasks. Even if it’s not a good workstation anymore, could be fun to experiment with. Older phones (especially Android devices) really do have a set lifespan that I’d recommend to stop using them as daily drivers. When the manufacturers stop supporting them, they can be horrifically vulnerable devices as exploits are found over time. You might still get use out of it though without using its networking capabilities. It likely still has functional storage, screen, cameras, etc. If you’re lucky, you might be able to play around with straight Linux projects like PostmarketOS.

For new stuff, Linux-centric vendors can be nice (though a lot of them seem to just rebadge Clevo laptops with a decent markup) as a guarantee of good hardware support. Most business laptops make for good Linux laptops. I personally bought a Framework 13 a few years back and that’s my primary laptop. Though if you want to stay away from United States-based projects, your initial choices are probably a good fit. Additionally, you might lean more toward OpenSUSE than Fedora as well in the same principle.

Video capabilities aren’t currently enabled on the main instance. According to commenters in the meta issue, it is (mostly?) implemented and if you are selfhosting a Stoat server instance, you can enable it for that instance.

There does appear to be some level of curve within your bed mesh, but the skew of the bed definitely shows that the bed is not level across the X axis. If you have manual bed leveling, work on the adjustment across the X axis before taking new mesh samples. Mesh compensation will definitely do a decent job compensating for a skew even as large as four layers worth, but the dimensional accuracy of the bottom of your parts will take a good hit printing like that.

It does depend on the connection type, but the general rule is not completely, barring some connection types like DSL. Given it sounds like you have Fiber, DOCSIS, or similar; you likely fall under the general rule. That said, you can absolutely tune and test above the typical 10-15% safety margin many guides start with without actually incurring any noticeable bufferbloat. The 10-15% is usually a good value for ISPs that fluctuate heavily in available babdwidth to the customer, but for more consistent connections (or for those that overrate high enough that the bandwidth fluctuations sit out of range for what the customer is actually paying for), you can absolutely get much closer to your rated connection speed, if not meeting or even passing it.

The general process is to tune one value at the time (starting with the bandwidth allocations for your pipes), apply the changes, noting the previous value, and performing a bufferbloat test with Waveform’s or others’ testing tools. Optionally, (this will drastically slow down the process, but can be worth it) one should actually hammer the network with actual load for a good few hours while testing some real-world applications that are sensitive to bufferbloat. Doing this between tweaked values will help expose how stable or unstable your ISP’s connection truly is over time.