Terraform State Encryption Planner

The Terraform State Encryption Planner helps you design a Terraform 1.10+ state encryption setup without leaving the browser. Pick a key provider - AWS KMS, GCP KMS, Azure Key Vault or a local passphrase - supply the key reference, and the tool assembles a ready-to-adapt terraform { encryption { } } block alongside a planning checklist that covers both the state file and saved plan files. State encryption is a newer, experimental Terraform capability, and getting the block syntax and key-provider wiring right the first time saves a round trip through documentation and trial-and-error applies.

Terraform state routinely contains sensitive values - database passwords, private keys, connection strings, and other outputs marked sensitive that still land in plaintext inside the state file by default. Encrypting state at rest closes that exposure for anyone who can read the backend storage (an S3 bucket, a Terraform Cloud workspace, a shared network drive) but should not be able to read secrets embedded within it. The planner keeps everything local: the key reference you type - an ARN, a resource ID, a passphrase placeholder - is only used to build the sample block in your browser, never transmitted anywhere.

Because encryption configuration varies meaningfully by key provider (different attribute names, different required fields, different method blocks for AWS KMS versus GCP KMS versus Key Vault versus a bare passphrase), the planner also acts as a quick reference across providers, so teams standardizing across multiple clouds can compare the shape of each provider's block side by side before committing to one.

• Four key providers - AWS KMS, GCP KMS, Azure Key Vault, and a local passphrase provider.
• Sample encryption block - a ready terraform { encryption { } } block covering both state and plan.
• Method selection - aes_gcm method wiring appropriate to the chosen key provider.
• Planning checklist - ordered setup and operational steps to follow before rollout.
• Backend naming - optionally label the backend the encryption applies to.
• Provider-specific fields - only the fields relevant to the selected provider are shown.
• Private by design - no cloud calls, no pricing or key-management API contacted.
• Copy / Download / Print - take the plan and block into a PR or runbook.
• JSON export - a machine-readable copy of the plan for automation or documentation tooling.
• Version-aware guidance - notes that state encryption requires Terraform 1.10 or newer.

1. Pick a key provider - AWS KMS, GCP KMS, Azure Key Vault or passphrase.
2. Enter the key reference - an ARN, resource ID, vault/key name, or passphrase placeholder.
3. Optionally name the backend the encryption configuration should apply to.
4. Click Generate plan to build the checklist and the sample encryption block.
5. Review the checklist - confirm each planning and rollout step before you apply it.
6. Copy the block into your root module alongside your existing backend configuration.
7. Copy as JSON if you want to feed the plan into internal documentation or automation.
8. Download or print a copy for a change-management ticket or design review.
9. Test in a non-production workspace first - confirm terraform plan and apply succeed with encryption enabled before rolling out broadly.
10. Re-run whenever you switch key providers or rotate keys, to regenerate the matching block.

Example - choose aws_kms and paste a KMS key ARN to get a sample key_provider "aws_kms" block with kms_key_arn and an aes_gcm method applied to both state and plan.

Example - choose azure_keyvault and supply a Key Vault name and key name to get the matching key_provider "azure_keyvault" block with the vault and key attributes filled in.

Example - choose gcp_kms with a key resource path to get a key_provider "gcp_kms" block referencing the project, keyring, and key name.

Example - choose pbkdf2 passphrase mode for a quick local or CI setup where a managed KMS is not yet available, with a clear reminder to store the real passphrase in a secrets manager rather than in version control.

Example - naming the backend as remote_state_encryption produces a checklist item confirming that name is referenced consistently across every module that reads the encrypted state via terraform_remote_state.

• Secure by default - encrypts sensitive values inside state and saved plans at rest.
• Guided setup - the checklist reduces missed steps during a first-time rollout.
• Provider comparison - see the shape of AWS KMS, GCP KMS, Key Vault and passphrase blocks side by side.
• Safe to use - no data leaves the browser and no cloud or key-management API is called.
• Faster rollout - skip hunting through changelogs for the correct 1.10+ syntax.
• Team-friendly - copy, download or print the plan for a design review or runbook.
• Automation-ready - export the plan as JSON for internal tooling.
• Reduces drift - a consistent block reduces divergence between environments.
• Version aware - flags that state encryption needs Terraform 1.10 or newer before you attempt it.
• Free and offline - no account, subscription or network connection required.