The PuddingThe proof is in the deployment.

Open source lab infrastructure for developers

Your projects are different.
Your lab isn’t.

A growing, AI-generated collection of reusable infrastructure modules for lab environments on Proxmox.

Build, experiment, review, break and rebuild in infrastructure designed to keep experimentation away from public production systems.

Get started See the roadmap →

Why this exists

Stop rebuilding.

Projects repeatedly need databases, identity providers, key vaults, object storage, observability, CI, messaging, backups, etc. The Pudding turns those recurring needs into reusable infrastructure building blocks.

The goal is not to deploy every service everywhere. It is to provide a standard way to provision a lab with the services a project needs.

Quick start

From repository to disposable infrastructure.

git clone https://github.com/YOUR-ORG/devinfra.git
cd devinfra

# create your venv
python3 -m venv ~/venv/devinfra \
~/venv/devinfra/bin/pip install --upgrade pip \
~/venv/devinfra/bin/pip install pytest hypothesis pyyaml

# author the env file
~/venv/devinfra/bin/python scripts/installer/cluster_env_wizard.py \
--env-file cluster.dev.env

# platform prerequisites (identity, template, SDN fabric, host gateway).
~/venv/devinfra/bin/ansible-playbook \
  -i ansible/inventory/localhost.yml \
  ansible/playbooks/platform-bootstrap.yml \
  -e cluster_env_file=cluster.dev.env \
  -e bootstrap_scope=all \
  -e bootstrap_pve_identity=true

# bootstrap the secrets manager (module SVC-07)
~/venv/devinfra/bin/ansible-playbook \
  -i ansible/inventory/localhost.yml \
  ansible/playbooks/svc-07-bootstrap.yml \
  -e cluster_env_file=cluster.dev.env

How it works

Simple architecture. Reproducible infrastructure.

Proxmox VM/LXC instances are the infrastructure boundary, Terraform provisions them, Ansible configures them and Docker Compose runs them.

Just enough orchestration. Proxmox → VM/LXC → Docker Compose → Services. No Kubernetes.

Project roadmap

Growing with real projects.

The roadmap describes the road to the destination, not a claim that every module ships on day one. The platform grows in four deliberate stages.

1

Foundation

Platform foundation

Build the common machinery first.

  • GitLab-managed Terraform state
  • LXC/VM provisioning conventions
  • Dynamic Ansible inventory
  • Secrets bootstrap
2

Tier 1

Services most projects need

Build after the foundation.

Data, storage, identity, secrets, networking, CI/CD, observability, MQTT, AI/ML, OTA and backup.

See Tier 1 services →
3

Tier 2

Add when reuse becomes real

Demand-driven expansion.

A Tier 2 module becomes a candidate when at least two projects need the same capability.

See Tier 2 services →
4

Tier 3

Build for a real use case

Specialized and on demand.

Advanced or domain-specific infrastructure stays out of the core until somebody actually needs it.

See Tier 3 services →

Roadmap ≠ status. A tier describes the rollout priority. The repository remains the source of truth for what is available, in progress or planned.

Service catalog

Pick what your project needs.

Browse the planned building blocks. Tier indicates rollout priority, not whether a module is already implemented.

Roadmap catalogOnly modules explicitly marked Available should be assumed ready to use. Until repository status metadata is connected, Tier 1 is shown as Core rollout, not as completed.
Check implementation status on GitHub →

Built with generative AI

AI by default. Reviewed by humans.

The Pudding is intentionally AI-assisted from the start: modules, docs, templates and conventions are drafted with generative tooling and then checked against real constraints.

That keeps the project moving without pretending that generated output is automatically safe. The real value is in repeatable review, testing and isolation.

1Generate

Draft the module, docs and requirements.

2Review

Challenge the design before it reaches a project.

3Deploy

Run it in isolated, disposable developer infrastructure.

Experiment aggressively. Contain the blast radius.

Isolation reduces risk, it does not eliminate it.

AI-generated infrastructure can be wrong, insecure or incomplete. A compromised module could still reach network peers, credentials or the hypervisor if boundaries are weak.

The Pudding therefore treats isolation, review, disposable environments and minimal credentials as engineering guardrails—not as a claim that generated code is automatically safe.

What this project is not

Developer infrastructure, not a production promise.

  • A hardened production platform
  • A reference security architecture
  • A managed infrastructure product
  • A guarantee that AI-generated code can be trusted without review

Project principles

Opinionated where it helps. Transparent where it matters.

1

Open source first

Self-hosted components are the default. The project should remain inspectable and reusable.

2

European where practical

Credible European-governed or headquartered options are preferred. Exceptions are documented rather than disguised.

3

Shared or dedicated

Platform services can be shared; project-specific stacks can be fully isolated and destroyed with the project.

4

CI/CD-driven

No click-ops as a deployment strategy. Plans, changes and repeatable rebuilds belong in source control and pipelines.