From 6cb48b4a6dccad3fc7d5117c076a733d9e1e602a Mon Sep 17 00:00:00 2001 From: thesabear Date: Sun, 23 Aug 2026 10:58:21 +0300 Subject: [PATCH] readme updates --- README.md | 47 ++++++++++++++++++++++++----------------------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index 22358ba..23745c8 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,30 @@ I'm a curious, self-taught technologist who runs a real, multi-host homelab as a production-grade playground: a Proxmox hypervisor cluster hosting a fleet of VMs/LXCs, a two-zone Caddy reverse-proxy design fronted by Authentik SSO, self-hosted Gitea with Ansible-driven scheduled maintenance, and Terraform+Packer provisioning for bootstrapping new hosts from hardened, minimal images. What started as a hobby project has grown into a full-on journey into DevOps, automation, infrastructure, and security. +# thesabear's Homelab + +Most homelabs are a media server with some extra apps bolted on. This one is a platform: the same categories of systems a company's platform/security team owns — secrets management, zero-trust network segmentation, self-hosted CI/CD, human-gated fleet orchestration, a self-built SOC — run at homelab scale, for real, 24/7, by one person. + + + + + + + + + +
11
fleet hosts		53
compose stacks		15
documented systems		4
trust boundaries		13
automated maintenance flows
+ +## The decision that shows the most + +Most self-hosted setups have one trust boundary: "you're on the LAN, you're trusted." That's the easy answer, and it's wrong — a single compromised container can reach everything else with no further resistance. The other easy answer, mutual TLS on every single connection with no exceptions, is also wrong: real overhead, real certificate-lifecycle burden, on traffic that doesn't need it — exactly the kind of complexity that gets quietly disabled under pressure, which is worse than never building it. + +This fleet runs **four trust boundaries, each calibrated to who's actually on the other end** — public internet traffic, human browsers on personal devices, machine-provisioned containers, and non-HTTP infra traffic each get a different control, matched to their real risk, not a blanket policy applied everywhere or nowhere. Enforced by **three independent routing authorities** instead of one central router, specifically so a failure or misconfiguration in any single one only ever takes out its own third of the traffic — never all of it at once. It didn't start this way, either: the public proxy used to be its own VM, and the internal service-to-service model used to be a flat, unauthenticated mesh with no boundary at all. Both got replaced deliberately, trading operational simplicity for a smaller blast radius. + +Full breakdown — the boundary-by-boundary reasoning, the routing-authority failure table, all 8 traffic laws: [docs/architecture-overview.md](docs/architecture-overview.md). + +This repo is a sanitized showcase of the systems behind that platform — the actual engineering decisions and tradeoffs, not just a list of installed apps. Every real IP, hostname, and internal domain has been stripped or genericized throughout. + My long-term goal is to build a career in IT — specifically in environments where learning never stops and innovation is part of the culture. --- @@ -50,29 +74,6 @@ I'm entirely self-taught. Every tool, trick, concept, and workflow in my repos i ![Bash](https://img.shields.io/badge/Bash-Scripting-lightgrey?style=for-the-badge&logo=gnu-bash) --- -# thesabear's Homelab - -Most homelabs are a media server with some extra apps bolted on. This one is a platform: the same categories of systems a company's platform/security team owns — secrets management, zero-trust network segmentation, self-hosted CI/CD, human-gated fleet orchestration, a self-built SOC — run at homelab scale, for real, 24/7, by one person. - - - - - - - - - -
11
fleet hosts		53
compose stacks		15
documented systems		4
trust boundaries		13
automated maintenance flows
- -## The decision that shows the most - -Most self-hosted setups have one trust boundary: "you're on the LAN, you're trusted." That's the easy answer, and it's wrong — a single compromised container can reach everything else with no further resistance. The other easy answer, mutual TLS on every single connection with no exceptions, is also wrong: real overhead, real certificate-lifecycle burden, on traffic that doesn't need it — exactly the kind of complexity that gets quietly disabled under pressure, which is worse than never building it. - -This fleet runs **four trust boundaries, each calibrated to who's actually on the other end** — public internet traffic, human browsers on personal devices, machine-provisioned containers, and non-HTTP infra traffic each get a different control, matched to their real risk, not a blanket policy applied everywhere or nowhere. Enforced by **three independent routing authorities** instead of one central router, specifically so a failure or misconfiguration in any single one only ever takes out its own third of the traffic — never all of it at once. It didn't start this way, either: the public proxy used to be its own VM, and the internal service-to-service model used to be a flat, unauthenticated mesh with no boundary at all. Both got replaced deliberately, trading operational simplicity for a smaller blast radius. - -Full breakdown — the boundary-by-boundary reasoning, the routing-authority failure table, all 8 traffic laws: [docs/architecture-overview.md](docs/architecture-overview.md). - -This repo is a sanitized showcase of the systems behind that platform — the actual engineering decisions and tradeoffs, not just a list of installed apps. Every real IP, hostname, and internal domain has been stripped or genericized throughout. ## Architecture at a glance