explaingit

markandrewkamau/infraforge

0GoAudience · developerComplexity · 3/5ActiveSetup · moderate

TLDR

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.

Mindmap

mindmap
  root((Infraforge))
    Inputs
      HTTP POST request
      Service name
      Resource type
    Outputs
      Job ID
      Postgres container
      Connection info
    Use Cases
      Study PaaS control loop
      Provision Postgres on demand
      Practice Go service patterns
    Tech Stack
      Go
      Redis Streams
      Docker
      Postgres

Things people build with this

USE CASE 1

Study how an internal PaaS control loop works in Go

USE CASE 2

Provision short-lived Postgres containers via an HTTP API

USE CASE 3

Practice async worker patterns with Redis Streams consumer groups

USE CASE 4

Prototype a Docker to Kubernetes provisioner swap behind one interface

Tech stack

GoRedisDockerPostgresHTTP

Getting it running

Difficulty · moderate Time to first run · 30min

Needs Go 1.26, Docker daemon access for the worker, and three terminals running broker, worker, and a curl poll loop.

In plain English

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.

Copy-paste prompts

Prompt 1
Walk me through cmd/broker in Infraforge and show where it validates incoming provision requests
Prompt 2
Add a new resource type beyond Postgres to the Infraforge provisioner interface and wire it through the worker
Prompt 3
Write a curl command that posts a provision request to the Infraforge broker on port 8080 and polls GET /v1/provision/<id> until ready
Prompt 4
Swap the Docker provisioner in Infraforge for a Kubernetes one and outline the package changes
Prompt 5
Trace what happens in Infraforge when the worker crashes mid-job and Redis redelivers via the consumer group
Open on GitHub → Explain another repo

Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.