Introducing Isoloom
Why we stopped writing the same environment five times, and what a spec that describes behavior instead of infrastructure makes possible.
Isoloom started inside a lab platform. Each lab existed twice: once as a Docker Compose file for laptops, once as a Vagrantfile with one VM per service. Then came a Proxmox version, then a cloud one. Every copy was a little different, and the differences only showed up when a learner hit them.
Describe the behavior, not the plumbing
The fix wasn't a better template. It was to stop describing infrastructure and start describing behavior: which machines exist, which networks they sit on, which network may reach which, and which services answer. Everything that's the same from the outside goes in one file. How each machine is built (a container, or a VM with its services installed natively) is a separate, per-machine choice.
From that, the targets follow. If every machine can be a container, the environment can run on Docker. If every machine can be a VM, it can run on local VMs, Proxmox and the cloud. A Windows domain controller has no container form, so an environment containing one is never offered on Docker, instead of producing a file that half works.
What v0.1 does
Version 0.1 is the format and its checks: isoloom validate finds mistakes and says how to fix
them, isoloom targets works out where a spec can run, and isoloom resources adds up what it
needs. The generators come next: Compose and Vagrant first, then Proxmox.
The spec is in the reference, and three complete environments are in the examples.