Analysis updated 2026-06-24
Study how an internal PaaS control loop works in Go
Provision short-lived Postgres containers via an HTTP API
Practice async worker patterns with Redis Streams consumer groups
Prototype a Docker to Kubernetes provisioner swap behind one interface
| markandrewkamau/infraforge | aasheeshlikepanner/vase | alexzielenski/controller-runtime | |
|---|---|---|---|
| Stars | 0 | 0 | — |
| Language | Go | Go | Go |
| Last pushed | — | — | 2022-04-20 |
| Maintenance | — | — | Dormant |
| Setup difficulty | moderate | moderate | hard |
| Complexity | 3/5 | 4/5 | 4/5 |
| Audience | developer | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Needs Go 1.26, Docker daemon access for the worker, and three terminals running broker, worker, and a curl poll loop.
Infraforge is a small, self-built Platform-as-a-Service that fits on a single laptop. Its purpose is educational: the author wanted to study how large internal developer platforms work, with Atlassian's Micros named as the reference example, and built a miniature version from scratch in Go to exercise the same control loop. A user describes a desired resource over HTTP, the system files the request, an asynchronous worker picks it up, and a real, network reachable Postgres container is created and reported back with its connection details. The README walks through that loop in six steps. A client posts a JSON body like service_name checkout, resource postgres to the broker on port 8080. The broker validates the request, writes a job record into Redis with a 24 hour TTL, pushes a reference to that job onto a Redis Stream, and returns immediately with a job id. A separate worker process is reading from that stream as part of a consumer group, which gives at least once delivery. When it pulls a job, it shells out to the docker CLI to run a postgres:16-alpine container named infraforge-pg-<jobID> on a random port bound to 127.0.0.1, then writes the outcome, ready or failed, back into Redis. The client polls GET /v1/provision/<id> until it sees ready, at which point the response carries a connection object. The code is partitioned so each concern is replaceable behind an interface. cmd/broker and cmd/worker are the two entry points. Inside internal there is an api package with HTTP handlers, a model package with shared Job, Status, and ConnectionInfo types, a store package that ships both an in-memory and a Redis-backed implementation of the same interface, a queue package for Redis Streams, a provisioner package whose current implementation drives docker but whose interface allows swapping in Kubernetes later, and a worker package that contains the control loop and is tested with fakes. A docker-compose.yml file brings up Redis. A GitHub Actions workflow runs go vet, go build, and go test with the race detector on every push. Quick start is three terminals: make deps-up and make broker, make worker in the second, and curl in the third to post a provision request and poll for status. Once a database is ready, docker exec into the infraforge-pg-<jobID> container with psql talks to it. make clean-pg removes every Postgres container the system created, and make deps-down stops Redis. All runtime settings are environment variables.
A small self-built PaaS in Go that provisions ephemeral Postgres Docker containers via an HTTP broker, a Redis Streams queue, and an async worker. Built as an educational miniature of Atlassian Micros.
Mainly Go. The stack also includes Go, Redis, Docker.
Setup difficulty is rated moderate, with roughly 30min to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.