Terraform Backend Block Generator
Generate secure remote state backend blocks for AWS S3, GCS, Azure, and HCP Terraform with locking and encryption.
terraform {
backend "s3" {
bucket = "company-tfstate-us-east-1"
key = "production/app/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "company-tfstate-locks"
workspace_key_prefix = "workspaces"
}
}bucket = "company-tfstate-us-east-1" key = "production/app/terraform.tfstate" region = "us-east-1" encrypt = true dynamodb_table = "company-tfstate-locks"
terraform init -backend-config="bucket=company-tfstate-us-east-1" -backend-config="key=production/app/terraform.tfstate"
Do it offline:$
How to use it
- Select your remote state storage provider (AWS S3, Google Cloud Storage, Azure Blob Storage, HCP Terraform, or Consul).
- Enter the bucket or container name and state file path key.
- Configure state locking (such as DynamoDB table name in AWS S3) to prevent concurrent deployment collisions.
- Enable server-side encryption to protect sensitive infrastructure outputs, secrets, and connection strings stored in state.
- Optionally configure IAM assume-role ARNs or Azure AD authentication for credential-free CI/CD pipelines.
- Copy the generated HCL backend block, partial backend.hcl configuration, or terraform init CLI command.
Generate production-grade Terraform backend blocks and partial backend configurations for AWS S3, Google Cloud Storage, Azure RM, and HCP Terraform. Secure remote state with DynamoDB locking, AES256/KMS encryption, and role assumption.
How it works
Terraform uses state files (terraform.tfstate) to map real-world cloud resources to your configuration files and keep track of metadata.
By default, Terraform stores state locally. In team and production environments, remote backends store state in shared cloud object storage like S3, GCS, or Azure Blob.
State locking prevents concurrent terraform apply or plan runs by acquiring a lease in a distributed lock store (e.g. DynamoDB for S3, native blob leases in GCS and Azure).
Partial configuration allows omitting environment-specific parameters (like bucket name and key) from checked-in code, supplying them dynamically during 'terraform init -backend-config=...' in CI/CD pipelines.
Examples
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Common errors
FAQ
Why should I use DynamoDB state locking with an S3 backend?
Amazon S3 itself does not provide distributed locking primitives. If two engineers or two CI/CD jobs run 'terraform apply' simultaneously against the same state without locking, both operations will attempt to modify the infrastructure and overwrite the state file, leading to state corruption and orphaned resources. DynamoDB provides atomic conditional writes to ensure only one apply executes at a time.
What is partial backend configuration and why use backend.hcl?
Partial backend configuration allows you to define an empty or generic 'backend "s3" {}' block in your Terraform codebase while keeping environment-specific values (like bucket name, key, and region) in separate files like 'backend.hcl'. This allows you to reuse the exact same Terraform code across dev, staging, and prod environments simply by passing '-backend-config=path/to/backend.hcl' during 'terraform init'.
Does Terraform state contain plaintext secrets?
Yes. Any sensitive resource attributes—such as database passwords, TLS private keys, IAM access tokens, and API credentials—are stored unencrypted in the JSON state file. This makes server-side encryption (SSE-S3 or AWS KMS CMK), strict S3 bucket access policies, and TLS-only bucket policies critical security requirements.