Manual
How to write a script, describe it, run it, and hand it to others: from one file on your machine to a catalogue with a gate in front of it.
Read it in order the first time: each page builds on the one before, and the first four are all a script needs. The rest is there when you need it.
Getting started
Install instamix, write a script, and run it.
Declaring files
file() is the core: everything else is a shorthand that calls it. And how a declared tree is written out, archived, or absorbed from playbooks you have.
Structure helpers
Playbooks, roles, collections, inventory and variables as calls: where the multi-file editing goes away.
Describing a script
Groups, variables with a shape, tags, and stages that run alone. The inventory, the group_vars and site.yml are written from what the script says it has.
Running
What run passes to ansible-playbook, where it builds, how a run is recorded and shown again, and the output other programs read.
Requirements
What a script needs from Galaxy and from the machine that runs it, and three ways to have it: an environment built with uv, a container, or a community base.
Profiles
One script, several deployments: a declaration inside with profile(...) only materializes when that profile is active.
Linting
Your own checks over the declared tree, the ones that come for free because the whole tree is in memory, and then ansible-lint.
Tests
Molecule scenarios, ansible-test targets and role test playbooks, declared next to what they test.
Editor support
imix lsp is a language server for the Ansible side of a script: problems where you wrote them, your roles installed, and Ansible inside the strings.
Settings
Options you’d pass every time can be defaults instead, in git-like config files: one for everything, one per repository.
Screening proxy
imix proxy serve stands between ansible-galaxy, uv and pip and the real Galaxy and PyPI. It caches what they download and serves only what a list of rules allows.
Repositories
A playbook repository is a git repository with instamix scripts in it. Nothing declares what it holds: the scripts describe themselves.
Hub, gate and MCP
An inventory per team, a catalogue compiled from the scripts, and an approval gate between a proposal and a run. imix serve runs any of it in one service.
Deploying
deploy/ has the hub and clockwork as one pod, the screening proxy as a second, a pod to each job as a component, and this site as another.
Examples
Scripts to read, in examples/: from a one-file hello world to a k3s cluster and the applications on it.
Development
Working on instamix itself: one tool to bootstrap, and a check that runs the tests on the oldest and the newest Python.