KiloLock Docs

CLI Commands

This section is the practical reference for kl.

Use it when you want to answer questions like:

  • What does this command actually do?
  • When should I use kl plan vs kl apply?
  • Is --target safe here?
  • Which environment variables affect CLI behavior?
  • What is the shortest meaningful example for this command?

Command map

Daily operator path

  • Plan builds a KiloLock plan spec from a Terraform configuration.
  • Apply applies that spec, or builds one implicitly from files or targets.
  • Status, history, and diff show what is happening now and what changed.
  • Rollback and state are the operator escape hatches when you need repair.

Inspection and analysis

  • Query runs read-only SQL or backend-native resource/history lookups.
  • Quota previews hard and soft quota outcomes before apply.
  • Refresh talks to providers directly and writes a new state version when drift is observed.

State management and metadata

Configuration

The common workflow

For most teams, the meaningful path looks like this:

kl plan -f slow_a.tf -o slow-a.plan.json
kl apply --plan-spec slow-a.plan.json --confirm-scope
kl status big-state
kl history big-state --limit 5

For a plain full-state workflow:

kl plan
kl apply

For investigation without mutation:

kl query "SELECT type, COUNT(*) FROM resources GROUP BY type ORDER BY 2 DESC"
kl diff big-state --from=@1 --to=current --summary
kl status big-state

Safety model

  • kl plan is where KiloLock predicts write scope, read scope, and reservation impact.
  • kl apply is dry-run capable, but mutating scoped workflows require explicit acknowledgements.
  • kl rollback is dry-run by default.
  • kl state rm and kl state mv are preview-first in state-engine mode.
  • kl quota exists to catch limit failures before the final state write.

If you are introducing KiloLock to a team, start with:

  1. kl plan
  2. kl apply --dry-run
  3. kl status
  4. kl history
  5. kl query