What if you could combine the native simplicity of Docker Compose with the decentralized targeting and reliability of HashiCorp Nomad?
Meet Gubernator (or gbnt
), a "Goldilocks" container orchestrator written in Go. In this post, I want to share how I took Gubernator from a single-node API to a fully decentralized, multi-node VM cluster with autonomous DNS resolution and local ingress routing—all co-authored alongside Antigravity, Google DeepMind's agentic AI pair programmer.
Kubernetes is the undisputed king of container orchestration, but for small-to-medium projects, homelabs, or edge deployments, it represents massive operational overhead. Docker Swarm is simple but lacks fine-grained task scheduling constraints.
Gubernator is designed to fill that sweet spot:
gbnt
binary acts as the Central Manager (holding the centralized SQLite state) and the Worker Agents.To test the orchestrator realistically, we provisioned three Multipass Ubuntu VMs:
gbnt-manager
(192.168.252.8
)gbnt-worker1
(192.168.252.9
)gbnt-worker2
(192.168.252.10
)
graph TD
Host[Mac/Laptop Host OS] -->|Resolves *.gbnt via local resolver| CoreDNS_Manager
subgraph Manager VM [gbnt-manager: 192.168.252.8]
CoreDNS_Manager[gbnt-coredns]
Mgr[gbnt-manager API & DB]
Caddy_Mgr[gbnt-caddy]
end
subgraph Worker 1 VM [gbnt-worker1: 192.168.252.9]
Agent1[gbnt Agent]
Caddy1[gbnt-caddy]
CoreDNS1[gbnt-coredns]
Cont1[App Containers]
end
subgraph Worker 2 VM [gbnt-worker2: 192.168.252.10]
Agent2[gbnt Agent]
Caddy2[gbnt-caddy]
CoreDNS2[gbnt-coredns]
Cont2[App Containers]
end
Mgr -->|Orchestrates| Agent1 & Agent2
CoreDNS_Manager -->|Synchronizes Records| CoreDNS1 & CoreDNS2
Caddy1 -->|Routes to local| Cont1
Caddy2 -->|Routes to local| Cont2
One of the biggest challenges in multi-host networking is how to route web traffic to containers without over the Manager.
Instead of routing all external traffic through a single ingress proxy on the Manager, we built a fully decentralized routing scheme:
hello-app.gbnt
) pointing directly to the IP of the Worker VM hosting the container.This means if hello-app.gbnt
is deployed on gbnt-worker2
(192.168.252.10
):
192.168.252.10
.gbnt-worker2
on port 80.172.17.0.2:80
).What makes this project unique is that 100% of the Go code, GORM integrations, Flutter dashboard widgets, and cluster setups were co-authored with Antigravity, Google DeepMind's agentic AI coding assistant.
Unlike simple autocomplete or chat windows, Antigravity acts as a pair programmer with agentic capabilities:
bridge
and gbnt-monitor-net
) had their IPs concatenated (e.g., 172.17.0.2172.19.0.7
). Antigravity traced the container IP extraction logic, proposed a fix, and validated the parser.Observability is built-in. By running gbnt monitor init
, the Manager spins up a complete telemetry stack connected via a dedicated network gbnt-monitor-net
:
Gubernator proves that you don't need a heavy orchestrator like Kubernetes to manage multi-host Docker deployments. By combining Go, SQLite, CoreDNS, and Caddy, we created a lightning-fast, decentralized orchestrator.
Pair-programming with an agentic coder like Antigravity allowed me to focus on high-level architecture while the AI handled refactoring, cross-compilation, VM deployment, and frontend updates.
If you are interested in building lightweight orchestration systems, check out the Gubernator repository and start building!
Have you built or used lightweight orchestrators? Let me know in the comments below!
#devops
#docker
#golang
#ai
#pairprogramming
#antigravity