How CozyHawk works · Blueprint #1 walkthrough
One governed change, start to finish.
This is one real change, end to end, walked through Blueprint #1: the governed cloud foundation. Every screen below is the real product.
One loop, one gate
Every change travels the same loop, and feedback sends it around again until it's approved. Destroy travels it too. The nine steps below walk it in detail.
Propose change
Configure
Run plan · locked
Review
Approved
Apply
Evidence
Start from a blueprint or a selection of modules
Pick a blueprint: a battle-tested combination of catalog modules with recommended settings. Or pick your own modules, or describe what you need and let CozyHawk compose one. Nothing is created yet, and nothing will be without a plan, a review, and your approval.
Tune the configurations in the editor
Every module arrives with smart defaults a senior platform engineer would pick: CIDR blocks, guardrails, permission sets, session durations. Keep them or change them, in a guided form or straight in the code: one editor across the whole platform. What you tune is the exact infrastructure as code your selection composes to, upstream module source and version in plain sight, headed for your Git. Your code, not our black box.
Propose the change
Wrap your configuration in a proposed change: the form you submit is where the evidence record starts. Two ways in: build the configuration right there inside the proposed change, or compose it first in the configurations area and pull it in. Either way, the proposal states what is changing before anything runs.
3. Propose the change
The proposed-change form: your configuration pulled in, on the record before anything runs.
Run the plan: it locks the exact code
Plans are free and un-gated: run as many as you like. A successful plan locks the exact code and binds the change to that run. What you review next is exactly, provably, what will apply.
Review the change
The reviewer sees the plan output, the locked code, and every file the change touches: exactly what it provisions, before it deploys. Working solo? You self-review, and it’s recorded, so the paper trail starts on day one.
Approval opens the gate
Review unlocks apply, and approval isn’t a blanket yes. Only the approved change can deploy, in the environment you choose, and nothing else. Until an approval exists, apply stays locked. You’re looking at the gate doing its job.
Apply through the gate, and watch it run
With review approved and an environment granted, apply opens, for that change, in that environment. The run streams into the workspace as real terminal output: each unit landing, in order, to your own cloud.
Evidence, for everything that ran
Every run leaves one durable record: who proposed the change, who approved it, the exact plan, every file it touched, and exactly what it created. “What changed, who approved it, did it succeed” always has an answer, exportable when someone asks.
Destroy passes the same gate
Tearing down is a change like any other, through the same gates: you propose it, run the plan of the destroy, the review approves it, and only then does the destroy itself run, gated and recorded. A platform you can’t safely take down isn’t a platform. Leaving is always possible, and we built for it.
The same loop for every change after, and for destroy.
Propose, configure, plan, review, approve, apply, evidence. The discipline you just read is the product. There is no other path to your cloud.