Self-Hosting a Production SaaS on Mini PCs: A High-Availability Infrastructure Guide

Running a Production SaaS on 3 Mini PCs Under My Desk

SayThat.sh runs its entire production infrastructure on three Intel i5-10500T mini PCs located under a physical desk. This self-hosted cluster provides 36 CPU cores and 56 GB of RAM for a one-time hardware investment between $360 and $750. The system achieves full high availability for database, cache, and ingress for a monthly electricity cost of approximately $11.

Why This Matters

Cloud-native abstractions often mask the underlying mechanics of distributed systems, leading to high monthly recurring costs and limited visibility into failure modes. By self-hosting on bare metal using k3s and CloudNativePG, developers can achieve sub-millisecond local network latency and significant cost savings compared to AWS or Vercel, which would cost between $200 and $400 monthly for an equivalent high-availability setup. This model demonstrates that production-grade performance is attainable on consumer hardware when paired with professional orchestration tools. Moving beyond cloud security theater, this approach requires direct ownership of the security posture and disaster recovery. Implementing actual high availability—tested via physical node disconnection—ensures the system can handle failovers in 5 to 30 seconds without manual intervention, proving that mission-critical SaaS can thrive on consumer-grade hardware with proper orchestration. It challenges the industry assumption that managed services are mandatory for production reliability.

Key Insights

• High availability is achieved using k3s with embedded etcd across three nodes, allowing any single node to fail without service interruption.
• CloudNativePG manages a two-instance PostgreSQL 15 cluster with streaming replication and automatic failover triggered within 5 to 30 seconds.
• Redis Sentinel provides cache persistence with three instances, electing a new master in approximately 5 seconds using ioredis Sentinel-aware connections.
• Networking is secured via Cloudflare Tunnel replicas, eliminating the need for port forwarding or public IPs by routing traffic through encrypted tunnels.
• The backup strategy employs a three-tier DR model, including continuous WAL shipping via Barman Cloud Plugin to an off-cluster MinIO instance.
• Infrastructure automation is handled by 15 Ansible roles and 14 playbooks, ensuring idempotent cluster bootstrapping and deployment.
• Distributed block storage is managed by Longhorn, providing replicated storage across NVMe drives with sub-millisecond latency.

Practical Applications

• Use Case: Deploying distributed block storage using Longhorn across multiple nodes. Pitfall: Unclean node detachment can cause ext4 corruption; requires blacklisting iSCSI devices in multipath.conf.
• Use Case: Continuous Integration using in-cluster Docker BuildKit with registry cache. Pitfall: Containerd cache may ignore imagePullPolicy: Always; requires pinning deployments to exact SHA256 digests.
• Use Case: Security enforcement using 18 Kubernetes NetworkPolicy objects. Pitfall: Relying on aspirational policies without enforcement; requires k3s 1.34 with kube-router for actual ingress/egress restriction.

References:

• https://dev.to/saythatsh/running-a-production-saas-on-3-mini-pcs-under-my-desk-43n3