How to Automate with Atoms

Atoms describes how automation works — the two engines, the libraries, every atom in both its forms. These guides describe how to get a specific job done with them, grouped by the role that does it.

Everything here is automation: a flow, a script, or the same job shown as both. That is why the guides live inside Atoms rather than beside it — they are the worked examples for the reference above them.

Roles

Role	Covers
DevSecOps	Build machines, fleet builds, releases, provisioning, secrets, backups and routine operations
Developer	Writing, parameterising, validating, constraining and benchmarking scripts, and promoting them into flows

More roles follow — data engineer, AI engineer, solution architect.

A role is a job someone has, not a tool they use. “Scripting” was a group here once and is not one any more: it named a technique rather than anyone’s work. Guides live under the role that does them, and the reference they lean on is the rest of Atoms.

Every guide has the same shape

Section	What it gives you
Goal	What you will have when you finish, stated before anything else
Why bother	The pain it removes, so you can decide whether to read on
Steps	The solution built up one piece at a time, each step explaining why
The finished thing	The whole of it in one block, ready to run
Verify	How to know it worked, rather than assuming
Adapt it	What to change for your environment

The incremental build-up is deliberate. A finished flow pasted whole teaches you nothing about which part to change when it does not fit; one assembled a step at a time shows you where each decision lives.

Both surfaces, where both apply

Most jobs here can be done two ways — as a flow or as a script — because both reach the same atoms. Where that is true, the guide shows both:

Flow · Script

Pick a tab and the choice is remembered across the whole site. If you work in scripts, you see script examples everywhere until you switch.

Where only one form makes sense, the guide says so and says why. Some jobs are genuinely flow-shaped — anything that must survive a failure, spread across machines, or be resumed by somebody else. Some are genuinely script-shaped — anything that is really one calculation. See Flows and scripts for how to tell.

Conventions in these guides

Flows run the same way throughout:

kis flow -f <flow>.yaml

Scripts run the same way throughout:

kis script run <script>.<js|lua|go|star|wasm>

Values you must change for your own environment are always at the top — flow vars: or script arguments, never buried in a step. Hosts, users, key paths and versions are placeholders (deploy.example.com, /path/to/key) and never real infrastructure.