Why I Built Mateere Cloud Lab
How a genuine curiosity about infrastructure after ZCHPC grew from a single VPS running CloudPanel into a 4-node personal cloud lab hosting research, project platforms, and everyday services.
A Passion Project That Runs Real Workloads
Mateere Cloud Lab started from a simple drive: I wanted to understand infrastructure from the ground up, experiment freely, and have a reliable place to run my own tools. Rather than treating infrastructure as an afterthought, I wanted to learn how operating systems, networks, and container platforms behave under actual day-to-day use.
Over time, it grew from a hobby VPS into a multi-node environment that hosts my research projects (GeoCrop), development compute for platforms I lead (Next-Gen), and domestic services my family uses daily. It remains, at its heart, a grass-roots personal lab built out of passion for systems engineering.
The Evolution of the Lab
The chronological sequence of how the environment evolved from 1 machine to 4 nodes.
Zimbabwe Centre for High Performance Computing (ZCHPC)
My journey into infrastructure started during my time at the Zimbabwe Centre for High Performance Computing (ZCHPC). Working around large compute clusters, petabyte-scale storage arrays, and high-throughput networking opened my eyes to the world beneath the software. It was where I first saw how distributed systems, filesystems, and hardware interact under real load.
Developing a Passion for Infrastructure
Working with those systems sparked a genuine fascination with infrastructure and systems engineering. While I was building software, I found myself constantly drawn to how the underlying platforms worked—how the Linux kernel manages memory, how containers share resources, and how networks are stitched together. I wanted a lab of my own where I could experiment and run things freely.
Transitioning Out of ZCHPC
When I transitioned out of ZCHPC into independent engineering and software consulting, I wanted to bring that same appreciation for reliable, resilient systems into everyday projects. Real projects needed fast, dependable infrastructure without the million-dollar budgets of national computing centers.
The Single-Node Beginning
Mateere Cloud Lab started on a single Contabo VPS. To get things moving quickly, I installed CloudPanel on the host to manage websites, PHP backends, and an Odoo instance. It was straightforward, reliable, and did the job well for the early days.
More Projects Piling In
As more projects came in, that single VPS started filling up. Staging environments, databases, background cron workers, and personal experiments were all running on the same machine. Different services needed different runtimes and configurations, and managing everything directly on one host began to get crowded.
Confronting Limits & The Need for Consolidation
Soon I ran into the natural limits of running everything on one VPS: port contention, shared memory pressure, and the risk that one heavy task could slow down another service. Rather than spinning up random disjointed virtual machines, I decided it was time to properly containerize and orchestrate the environment.
Adopting K3s Orchestration
I chose K3s because it is lightweight and practical for a personal lab while remaining fully compliant Kubernetes. The key challenge was coexistence: I already had websites running via CloudPanel Nginx on the host VPS. By using SNI proxying on ports 80 and 443, I was able to run CloudPanel on the host alongside K3s Ingress-NGINX on the same server without taking anything down.
Expanding into a Multi-Node Lab
As compute demands grew, the single VPS expanded into a 4-node cluster combining Rocky Linux and Ubuntu nodes. I set up Flannel overlay networking for pod communication and created a custom DaemonSet to keep firewall rules in sync across nodes so cluster traffic flowed reliably.
Hosting Flagship Research: GeoCrop & Sen4Stat
With a stable multi-node lab running, I used it to host my research projects. GeoCrop—a crop classification platform for Zimbabwe—runs its machine learning inference workers, Redis task queues, Sentinel-2 satellite data ingestion, MinIO object storage, and TiTiler map services directly on the cluster. Alongside it, I hosted agricultural statistics pipelines inspired by Sen4Stat.
Next-Gen Platform (Lead Engineer & DevOps Engineer)
As Lead Engineer and DevOps Engineer on the Next-Gen school management system and platform, I utilized the lab for controlled development compute and staging. Using self-hosted Gitea for source control and isolated cluster resources, I deployed the Supabase backend stack (PostgreSQL, GoTrue authentication, Kong API gateway, and Realtime websockets) to develop, test, and validate the platform before production deployment.
Family Services & Mateere Cloud Lab Today
Today, Mateere Cloud Lab is a living 4-node environment running 185 workloads across 19 namespaces. Alongside research and project platforms, it hosts daily services for my family and farm: Nextcloud for family files, Jellyfin for streaming, Grocy and Mealie for household organization, and FarmOS for farm records. It is a genuine personal cloud lab that grew naturally from curiosity and necessity into an environment that powers both work and daily life.
Practical Technical Lessons
Architectural patterns learned through trial, error, and hands-on operation.
Sovereign GitOps
Pairing self-hosted Gitea with ArgoCD keeps deployments declarative and version-controlled. Changes to manifests are tracked in Git, making the environment reproducible without relying on third-party cloud services.
Host & Kubernetes Coexistence
Running CloudPanel on the host VPS while K3s Ingress-NGINX handles cluster services on the same public ports showed that existing host setups and modern container orchestration can share hardware smoothly.
Curated Showcase vs. Operational Cockpit
The public showcase consumes a sanitized telemetry snapshot, keeping the actual operational consoles—Prometheus, Grafana, and ArgoCD—safely protected inside the private Cockpit interface.
Real Telemetry Only
Every metric shown on this dashboard comes directly from Kubernetes API queries, Prometheus timeseries data, and Uptime Kuma checks. The lab reflects what is actually running.
Explore the Lab Architecture
See the interactive cluster topology, service routing flows, and the catalog of active services.