Brett: Write how-to guide with illustrations

2026-08-21T16:48:52Z

Write how-to guide with illustrations

New page

[[File:Spacelift-howto-hero.jpeg|thumb|center|500px|Config in, plan reviewed, confirmed, applied.]]
A simple walkthrough of how infrastructure actually gets deployed with Spacelift — the same process used to build the [[Spacelift|labs documented here]]. Written for anyone who already knows what Infrastructure as Code is and wants to see how Spacelift specifically fits into that workflow. Seven steps, no step skipped, nothing applied without a human saying so.

== Step 1: Write your infrastructure as code ==

Describe what you want — a server, a network, a database — as config files (OpenTofu or Terraform) in a Git repository. This is the "shopping list," not the click-through-a-console approach. It's also the part that makes every future change reviewable, since it's just a diff in a file.

== Step 2: Create a Spacelift stack ==

Point Spacelift at that repository and branch. A "stack" is Spacelift's unit of infrastructure — one stack usually maps to one deployable piece of your system (a network, an app, a database tier).

== Step 3: Attach cloud credentials, scoped on purpose ==

Connect the stack to your cloud account. Worth doing deliberately here: automation/read-only access and actual deploy access don't have to be the same credential. Keeping them separate means a compromised or overly-curious tool can look, but can't touch.

== Step 4: Push a change ==

Commit and push. Spacelift picks it up automatically and runs a '''plan''' — a full preview of exactly what would change, added, or destroyed. Nothing has touched the real infrastructure yet.

== Step 5: Read the plan like it matters ==

[[File:Spacelift-howto-confirm.jpeg|thumb|right|280px|The gate that keeps a bad plan from ever reaching production.]]
This is the step people skip when they're in a hurry, and the step that saves you when you are. The plan shows every resource being created, changed, or destroyed — read it the way you'd read a contract before signing it.

== Step 6: Confirm ==

Only after a human clicks confirm does Spacelift actually apply anything to the real account. This is the whole point: plan and apply are two separate, deliberate actions, not one button that does both. It's the difference between "this happened" and "I meant for this to happen."

== Step 7: Check the run history any time ==

Every run — who triggered it, what changed, whether it was confirmed or rejected — stays in Spacelift's history. Weeks later, "why did this change" has an actual answer instead of a guess.

== Why it's worth the extra step ==

None of this is exotic. It's the boring, unglamorous discipline that turns "I hope this doesn't break something" into an actual guarantee — whether the thing pushing the change is a person or, as in [[MAC|this case]], an AI agent working with real credentials. The gate is the same either way, and that's exactly the point.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:Technical Account Manager]]

How to Use Spacelift - Revision history

Brett: Write how-to guide with illustrations