Every infrastructure starts with a boot sequence.
This is ours.
Most cloud tooling treats infrastructure like a pile of resources you provision and then wire together afterward — a VPC here, an IAM role there, a database bolted on once someone remembers it's needed. Cloud iNIT inverts that. It treats a running platform the same way a Linux kernel treats a running machine: as a sequence of stages that has to complete, in order, before anything is considered "up."
In practice that means every environment — a student's sandbox, a demo, a production rollout — comes online through the same nine-stage path: base image, network, identity, secrets, compute, data, observability, ingress, and finally traffic. Nothing downstream of a stage starts until that stage reports healthy. There's no "it's probably fine, the app started" — the boot log either shows a stage completing or it doesn't.
The payoff of that constraint is boring on purpose. Drift becomes visible because every re-run reproduces the same order. Debugging a broken environment means reading the log backward from the first stage that didn't come up clean, instead of guessing across a dozen dashboards. And because the same sequence runs for a solo sandbox as for a multi-region deployment, what you practice on a laptop is exactly what runs later — not a simplified stand-in for it.
Every stage declares what it depends on and what it exposes. The engine won't start stage 5 (compute) until stage 4 (secrets) has written its output — so a missing credential fails loudly at stage 4, not as a mystery crash three stages later.
AWS, Azure, and GCP each expose the same nine stages under provider-specific plumbing. The console normalizes the differences — you learn the sequence once and it maps onto whichever provider a project actually uses.
A background reconciler re-walks the boot sequence on a schedule. If stage 6 (data) has quietly diverged from what stage 4 last wrote to secrets, it's flagged and, where policy allows, corrected automatically rather than left for someone to notice in an incident.
If you're working through an AWS, Azure, or GCP curriculum, the sandbox gives you a disposable environment that behaves like production instead of a cut-down teaching stand-in — the same IAM, networking, and observability stages you'd hit on the job, without a cloud bill you have to babysit.
Without a dedicated platform engineer, most small teams either over-provision "just in case" or under-provision and get paged at 2am. A fixed boot sequence means the same nine stages run whether it's one service or twelve, so the platform doesn't get more fragile as it grows.