I could not make sense of this work without research. After three years at CERN, back in Bilbao I decided to work on my own and keep researching and learning. I believe entrepreneurship is the ultimate professional challenge — and, at the same time, an expression of creativity and a claim to freedom.
Zetesis comes from the Greek ζήτησις, inquiry: find the cause before proposing the solution.
I manage the servers for my own projects and for some clients. Some sit in two houses and the rest are four rented servers on the internet. Almost all of their configuration lives in a single git repository, and a change to that repository reaches only the machine it concerns.
This post is the map: which machines there are, what each one is responsible for and how what runs on them gets deployed. The network that connects them, with VyOS, the tunnel between the houses and Tailscale, is the subject of the next one.
Two houses on one network and four servers on the internet
Each house has its own router, and a permanent encrypted tunnel between the two joins them into one network: from a machine in the first house I reach the ones in the second as if they were in the same room. The four servers on the internet are VPS, rented virtual machines with a public IP. The houses are not open to the internet; public traffic comes in through the VPS.
What each machine is responsible for
Machine
Where
Responsible for
How it is deployed
Production Kubernetes cluster
House 1
Zetesis RAG and the rest of my own applications
Argo CD
Platform Kubernetes cluster
House 1
Secrets (Infisical), images and charts (Harbor), the shared database, and metrics, logs and traces
Argo CD
Router
One in each house
Firewall, internet access and the tunnel between the houses
Configuration in git
Docker server
One in each house
Home automation and house services
Agent that checks git
NAS
House 2
Backups of everything else
By hand
Edge VPS
Internet
Receives web traffic and forwards it to the right service
Agent that checks git
Pre-production VPS
Internet
Pre-production of another product of mine
Agent that checks git
Two client VPS
Internet
Websites and forums
Agent that checks git
The machines by role, without their names.
Both clusters run Talos Linux and have a single node each. The production one runs in a virtual machine on Proxmox, and the platform one on a dedicated mini PC. The routers and the Docker servers are also Proxmox virtual machines, which lets several of them share one box.
Why responsibilities are kept apart
Keeping them apart means a failure stays where it happens. If pre-production goes down, production does not notice. If the platform cluster goes down, production applications keep running with the secrets and images they already have, although I cannot deploy anything new until it is back. And the backups live in the other house: if I lose the first one, the data is still in the second.
Keeping things apart is not high availability. Each cluster has a single node, and if that node stops, whatever runs on it stops too.
One folder per machine in a single repository
The configuration of these machines is in a git repository, with one folder per machine that says which containers run and at which version. To change something, I change the file and push it. There is no need to SSH into the server.
Who applies the change depends on the kind of machine. In the clusters it is Argo CD, which compares the repository with what runs in the cluster and fixes the difference. The Docker servers run doco-cd, an agent that checks the repository every three minutes and, if its folder changed, brings the containers up with the new configuration. The routers keep their configuration in the same repository, generated from templates.
When I release a new version of Zetesis RAG, CI opens a pull request in this repository with the new version, and once I accept it Argo CD deploys it. Every deployment is recorded as a commit, with its date and what changed.
Secrets are not in git in plain text
Passwords and keys come from Infisical. In the clusters External Secrets Operator delivers them, and the Docker servers get them from Infisical when they deploy. The little that has to be in git, such as the routers' secrets or what is needed to bootstrap a cluster from scratch, is encrypted with SOPS. I explained how this works in Kubernetes in Infisical and GitOps.
What is still done by hand
The Proxmox nodes and the NAS are configured by hand. If I had to rebuild one, the repository would not do it for me and I would have to repeat the steps. Each machine's name and more detail on every piece are in the Building a homelab from scratch series.
01
02
03
04
