kilolock.dev

Querying State with `kl`

This is one of the clearest examples of what Kilolock gives you beyond vanilla Terraform.

With a normal backend, state is usually a blob you inspect indirectly. With Kilolock, you can query what Terraform wrote in a more structured way.

Inventory by resource type

kl query "SELECT type, COUNT(*) FROM resources GROUP BY type ORDER BY 2 DESC"

That is useful when you want a fast inventory view across a large state.

Run a saved SQL file

kl query -f docs/queries/inventory_by_type.sql --format csv
kl query -f docs/queries/drift_current.sql --format json

This is useful for repeatable operator checks, CI reporting, and team-shared diagnostics.

Inspect a single resource

kl query resource --address time_sleep.slow_a

That gives you a much more focused inspection path than opening a whole state blob and searching through it manually.

Inspect resource history

kl query history --address time_sleep.slow_a

This is where Kilolock becomes meaningfully different from plain Terraform backend usage. You are not just storing the last state version. You are inspecting state evolution.

Why this matters

These workflows are especially useful when:

a state is large
several engineers share it
you need faster operational visibility than a full Terraform cycle
you want repeatable diagnostics that can live in SQL files