Beyond the Hypervisor: Architecting the Self-Sufficient Stack (Gitea, Vaultwarden, Uptime Kuma)

In my first post, I covered the bones of the homelab--the Proxmox hypervisor, the pfSense firewall, and the pursuit of autonomy. But an infrastructure platform is only valuable when it hosts essential services. The real shift to self-sufficiency happens when you move from running virtual machines to replacing SaaS providers with your own applications.

This is Part Two: moving from infrastructure to applications. With Proxmox and pfSense providing the foundation, I deployed three critical services that replaced external dependencies: Vaultwarden for password management, Gitea for version control, and Uptime Kuma for monitoring. Each choice reinforced a core principle--if you can't control it, you don't truly own it.

Essential Service 1: Vaultwarden--Taking Ownership of Security

The single most important self-hosted app in my entire setup is Vaultwarden (the lightweight Bitwarden server implementation). Password managers are the foundation of digital security, and outsourcing that to a third party always felt like a contradiction in terms.

By self-hosting Vaultwarden on a dedicated, minimal VM within my lab, I immediately regained full control of my digital keys. While the Docker installation was simple, the real effort went into maximising resilience and security, starting with a robust backup strategy. This strategy automates daily exports of the encrypted SQLite database to both local NAS and an off-site encrypted backup via rsync. Since the database is encrypted at rest, the data is secure even in transit. Critically, I maintain a fully tested restore procedure--because a backup you haven't tested is just hope with a file extension. Rollbacks are entirely handled by scripts, making the process hands-off and minimising the risk of human error and data loss. I receive exception reports instantly if a backup fails or is interrupted.

Self-hosting Vaultwarden mirrors how I approach programme risk management: identify the critical dependency, assess the third-party risk, and build redundancy where it matters most. Security isn't outsourced; it's architected.

Essential Service 2: Gitea--Version Control, My Way

As an ops leader, documentation and code versioning are critical. While GitHub is excellent, hosting my personal repos and config files on my own Gitea instance offered a few advantages:

• Speed and Control: Local network access to repos is lightning fast.
• Privacy: Full control over my data with no third-party access, analysis, or changing terms of service.
• Learning: Setting up a Git server was a more effective way to learn Git than solely relying on GitHub's graphical user interface (GUI). This hands-on experience also clarified why enterprise organisations often host their own Git servers: to mitigate third-party risk.

Gitea sits alongside my main infrastructure stack, using Docker Compose for simple deployment and exposing its web interface via my Traefik reverse proxy, securing it with an SSL/TLS certificate--a necessary layer of professionalism for an internal service.

Essential Service 3: Uptime Kuma--Monitoring That Matters

You can't manage what you don't measure. When you're running 20+ services on multiple nodes, you need an early warning system. That's where Uptime Kuma comes in.

Uptime Kuma is a slick, open-source monitoring tool that constantly checks the health and response time of all my services--from the external-facing website to internal APIs. When something fails (and it always does eventually, constantly), Uptime Kuma hits my custom notification channel.

Uptime Kuma sends push notifications to my phone via Gotify when any service goes down, with configurable retry intervals and status pages for each monitor. A wise PMO lead once told me, you can't mitigate risks you don't see coming. Real-time monitoring isn't perfectionism--it's operational discipline.

With these three services running, the homelab shifted from an infrastructure project to a genuine alternative to SaaS dependencies.