kl rollback and kl state
These are the repair-oriented commands.
They are powerful, and they are intentionally more explicit than the happy-path plan/apply workflow.
Strict Terraform-compatible states and environments have one extra rule:
- native KL repair/mutation workflows are blocked early
- the CLI tells you to use a Terraform-compatible wrapper flow instead
This applies both to existing strict states and to new states inside environments whose default lock mode is vanilla.
kl rollback
kl rollback replays an old state version, or one historical resource address, as a new write.
It is dry-run by default.
Whole-state rollback example
kl rollback big-state --to=@2
This previews what would happen if you restored the state from two versions back.
To actually perform it:
kl rollback big-state --to=@2 --apply --yes
Resource rollback example
kl rollback resource big-state --address time_sleep.slow_a --to @1
Use this when one address needs repair but a whole-state rewind would be too broad.
Important warning
kl rollback rewinds KiloLock’s state bookkeeping. It does not roll back cloud resources by itself.
That is why preview-first behavior matters.
kl state rm
kl state rm removes one exact address from state.
In state-engine mode it is preview-first. Otherwise it falls back to Terraform compatibility mode.
Example
KL_PROTOCOL=state-engine kl state rm big-state --address time_sleep.slow_b
To actually write:
KL_PROTOCOL=state-engine kl state rm big-state --address time_sleep.slow_b --apply --yes
Use it when:
- state contains an address that should no longer be tracked
- you want exact-address operator repair
But not on strict Terraform-compatible states. In that case the native command is rejected early.
kl state mv
kl state mv moves one exact address to another.
Example
KL_PROTOCOL=state-engine kl state mv big-state \
--from time_sleep.slow_a \
--to module.demo.time_sleep.slow_a
To actually write:
KL_PROTOCOL=state-engine kl state mv big-state \
--from time_sleep.slow_a \
--to module.demo.time_sleep.slow_a \
--apply --yes
Use it when:
- an address rename happened
- a resource moved under a module path
- you need an exact-address repair without broader mutation
Again, this native lane is intentionally disabled for strict Terraform-compatible states/environments.
Suggested repair workflow
kl query history big-state --address time_sleep.slow_a
kl rollback resource big-state --address time_sleep.slow_a --to @1
terraform plan
Or for exact-address maintenance:
KL_PROTOCOL=state-engine kl state mv big-state --from old.addr --to new.addr
terraform plan
If the state must stay in strict Terraform-compatible mode, use the Terraform-compatible path instead of KL_PROTOCOL=state-engine.