Rack Overview
Introduction
My homelab rack is the foundation of my entire infrastructure ecosystem. It is designed not just for experimentation, but as a production-grade learning environment where I build, deploy, and test real systems. The goal is to combine Kubernetes orchestration, CI/CD automation, and AI workloads into a unified environment that mirrors real-world engineering stacks at scale.
At the core of this setup is a Raspberry Pi-based K3s Kubernetes cluster, which handles container orchestration and service deployment. Supporting this is a dedicated development machine equipped with an RTX 3090 GPU running AI models in Docker containers. Together, these systems form a hybrid edge-and-local compute architecture that allows me to develop, test, and deploy seamlessly across environments.
Rack Architecture Overview
The rack is organized into three main layers:
- Compute Layer (Kubernetes Cluster)
- Development & AI Layer (GPU Workstation)
- CI/CD & Source Control Layer (Gitea + Runners)
Each layer plays a specific role in the overall system design.
Kubernetes Cluster (Raspberry Pi K3s)
The heart of the rack is a lightweight Kubernetes cluster built using K3s running on multiple Raspberry Pi nodes.
Key responsibilities:
- Running containerized applications
- Hosting microservices for my Bible app ecosystem
- Managing deployments via manifests and Helm charts
- Providing a sandbox for infrastructure testing
What makes this setup powerful is its simplicity and flexibility. K3s reduces overhead while still providing a fully functional Kubernetes experience. This allows me to simulate production deployments without requiring expensive infrastructure.
CI/CD System (Gitea + Runners)
My Git and deployment pipeline is built around a self-hosted Gitea instance running inside the cluster.
Key features:
- Source control for all infrastructure and application code
- Automated CI/CD pipelines using self-hosted runners
- Deployment automation directly into the Kubernetes cluster
Workflow:
- Push code to Gitea repository
- CI pipeline triggers build via runner
- Container images are built and stored
- Deployment manifests are applied to the cluster
This setup acts as the “glue” between development and production, allowing fast iteration without losing control of deployment stability.
AI Development Machine (RTX 3090 Workstation)
Outside the cluster, I maintain a dedicated development machine equipped with an RTX 3090 GPU.
This machine runs:
- Dockerized AI models
- Experimental inference pipelines
- Local testing environments for AI agents
- Model prototyping before production deployment
Rather than overloading the Kubernetes cluster with GPU workloads, I offload heavy AI computation to this system. This creates a clear separation between infrastructure services and compute-heavy ML tasks.
Application Ecosystem
Built on top of this rack is a growing ecosystem of applications, including:
- Bible study and comparison tools
- Devotional and journaling systems
- Social features (posts, reactions, debates)
- Game marketplace and interactive learning tools
- Ad system with creatives and bidding mechanics
- Livestreaming infrastructure using WebRTC and AWS IVS
All of these services are designed to be modular and deployed independently through Kubernetes.
Networking & Deployment Flow
The system follows a simple but powerful flow:
- Development happens locally or on the GPU machine
- Code is pushed to Gitea
- CI/CD pipelines build and test artifacts
- Kubernetes handles deployment and scaling
- Services communicate internally within the cluster network
This architecture ensures repeatability, scalability, and isolation between services.
Future Expansion
Planned improvements to the rack include:
- Expanding the Kubernetes cluster with additional nodes
- Adding GPU nodes directly into the cluster
- Improving observability (Prometheus + Grafana dashboards)
- Introducing service mesh for advanced traffic control
- Expanding AI inference services into cluster-native deployments
Conclusion
This homelab rack is more than just a collection of hardware—it is a full engineering platform. It combines distributed systems, CI/CD automation, and AI development into a unified environment that mirrors real-world infrastructure.
By integrating Kubernetes, Gitea, and a dedicated GPU workstation, the system allows me to move from idea to deployment quickly while still maintaining control over scalability and reliability. As it continues to evolve, the rack will serve as the backbone for increasingly complex applications, especially in AI, backend systems, and interactive platform development.
More in infrastructure-engineering
Continue exploring articles in this category.
Sep 7, 2025
K3s on Raspberry Pis
Step-by-step guide to setting up a K3s Kubernetes cluster on Raspberry Pi nodes — networking, configuration, a…
Sep 13, 2025
Hardware List and Costs
Full hardware list and cost breakdown for my ARM64 homelab Kubernetes cluster — Raspberry Pis, switches, stora…
Sep 20, 2025
Flashing Raspberry Pi OS
How to flash Raspberry Pi OS Lite and configure base settings for a production-ready Kubernetes homelab node f…
Case Study
Bible Verse — Case Study
Production SaaS Platform · Full-Stack · Founder & Sole Engineer
A domain-driven SaaS platform with five independently scalable system boundaries: scripture content delivery, RAG-backed AI study, real-time community interaction, async media processing, and infrastructure services — built and operated end-to-end.
Our Results
How We Built It
- RAG pipeline grounding AI responses in actual scripture rather than model memory
- Hybrid Llama / OpenAI routing — local inference for cost, API fallback for quality at the edge
- Non-blocking media processing — FFmpeg jobs enqueued via BullMQ, API never waits on transcoding
- Cross-instance real-time consistency via Redis pub/sub behind WebSocket and WebRTC layers
Lessons Learned
- Domain boundaries enforced at the service layer prevent coupling long before scale demands microservices.
- RAG retrieval quality matters more than model size — better embeddings outperform a larger model on poor context.
- Async queue design should be first-class, not bolted on; BullMQ worker isolation saved the request path repeatedly.
Stack
Written by
5+ years building production systems · AI, Backend & Infrastructure · Founder of Bible Logic
Full-stack engineer with 5+ years of hands-on experience designing and shipping production systems — from Nuxt 3 frontends and Nitro APIs to self-hosted Kubernetes clusters, RAG pipelines, and real-time AI applications. Everything I write comes from systems I've designed, deployed, and operated in production.

