Terraform State Command Builder

The Terraform State Command Builder assembles a correct terraform state command so you never have to remember the exact argument order for list, rm, pull, push and mv. State commands are powerful and easy to get wrong: removing the wrong resource address or mixing up the mv source and destination can disrupt your infrastructure, so a small, validated builder is a worthwhile safety net. You pick the subcommand, supply the resource addresses or the mv endpoints, and the tool produces the precise CLI line with proper quoting for addresses that contain spaces. Validation runs per subcommand, so rm refuses to run without at least one address and mv refuses without both a source and a destination. Everything happens locally in your browser; nothing is uploaded and no Terraform process is started. The result is a command you can copy into a runbook, paste into a terminal, or hand to a teammate with confidence that the syntax is right. It is particularly useful during incident response, when you need to move or remove a resource from state after a failed apply, and during clean-up, when decommissioned resources should be purged from state without a full rebuild. Because the builder never executes anything, it is safe to experiment with and to use as a teaching aid for engineers learning how state commands behave before they touch a real environment.

• All subcommands - list, rm, pull, push and mv are supported.
• Multiple addresses - rm accepts several resource addresses, one per line.
• mv endpoints - separate source and destination fields for the move subcommand.
• Smart quoting - addresses containing spaces are wrapped in quotes automatically.
• Per-subcommand validation - required arguments are enforced before the command is built.
• Copy / Download / Print - get the command wherever you need it.
• Stats row - shows the subcommand and the number of arguments.
• Word-wrap toggle - switch the preview between scroll and wrap.
• Incident friendly - build rm and mv commands during recovery without guessing the exact syntax under pressure.
• Runbook ready - the exact command can be pasted straight into a change ticket.

1. Pick a subcommand from the dropdown - list, rm, pull, push or mv.
2. Enter addresses if required - for rm, put one resource address per line; for mv, fill the from and to fields.
3. Load the sample if you want a ready-made mv example filled in.
4. Click Build command to assemble the CLI line.
5. Review the preview and check the stats row for the subcommand and argument count.
6. Toggle word wrap if the line is long on a small screen.
7. Copy the command to your clipboard or download it as a shell snippet.
8. Run it carefully - state commands are destructive, so double-check addresses before executing.
9. Print the command for a runbook or change record if needed.
10. Confirm intent - remember that list and pull are read-only, while rm and mv change state, so double-check the subcommand.
11. Share it - paste the command into a pull request or ticket so the change is auditable by reviewers.

Example 1 - list. Selecting list with no addresses produces terraform state list, which enumerates every resource in the state.

Example 2 - mv. Choosing mv with aws_instance.foo and aws_instance.bar yields terraform state mv aws_instance.foo aws_instance.bar, renaming the resource address in state without touching real infrastructure. For rm, several addresses on separate lines are appended to the command in order, so you can clean up many resources at once.

Example 3 - pull and push. Choosing pull or push with no addresses produces terraform state pull or terraform state push, which download or upload the entire state file and are handy after manual corrections or a backend migration.

• Correct syntax - arguments are assembled per subcommand, so ordering mistakes disappear.
• Validated - missing required arguments are reported before you run anything.
• Private - everything runs in the browser with no connection to Terraform.
• Portable - copy, download or print the command for a runbook.
• Safer - a clear, quoted command reduces the chance of a typo against production state.
• Auditable - a recorded command makes state changes easy to review afterwards.
• Teaching - newcomers can see exactly how each subcommand is formed before running it.