Why does the S3 backend need a DynamoDB table?

The `dynamodb_table` argument enables state locking, DynamoDB acts as a distributed lock so two `terraform apply` runs against the same state file can't corrupt it by running concurrently. Since Terraform 1.6+, `encrypt = true` is included by default, which this generator also sets explicitly.

Can I use variables inside a backend block?

No, Terraform backend configuration is deliberately static, it can't reference variables, locals, or data sources, since it has to be resolved before the rest of the configuration is even parsed. Every value the generator produces is a literal string for that reason.

What does the Kubernetes backend actually store state as?

It stores the state as a Kubernetes Secret in the given namespace, with `secret_suffix` appended to the generated secret's name so multiple workspaces or environments can use distinct secrets within the same cluster.

Is the Postgres backend still supported?

Yes, the `pg` backend stores state in a PostgreSQL database using a `conn_str` connection string; it remains a valid option for teams already running Postgres who'd rather not stand up S3/DynamoDB or GCS for state storage.

Terraform Backend Config Generator (S3, GCS, Kubernetes, Postgres)

Overview

Introduction

Remote state backend blocks are short, but every backend type wants a slightly different set of arguments, and getting the field names wrong just means Terraform init fails with an unhelpful validation error.

This tool generates a correct backend block for S3, GCS, Kubernetes, or PostgreSQL from a small type-specific form, so the right fields are always present.

What Is Terraform Backend Generator?

A generator for Terraform's `terraform { backend "<type>" { } }` block, covering the four most common remote state backends: S3 (with DynamoDB locking), GCS, Kubernetes, and PostgreSQL.

Each backend type shows only the fields it needs, S3 shows bucket/key/region/dynamodb_table, GCS shows bucket/prefix, Kubernetes shows secret_suffix/namespace, and Postgres shows a single connection string.

How Terraform Backend Generator Works

You pick a backend type, which switches the form to show only the fields relevant to that backend, then fill in the required values.

The tool validates that every required field for the selected type is filled in, then renders a `terraform { backend "type" { ... } }` block with those fields as literal strings, exactly as Terraform's static backend configuration requires.

When To Use Terraform Backend Generator

Use it when setting up remote state for a new Terraform root module and you want the correct field set for your chosen backend without checking documentation for each one.

It's also useful when migrating a module between backend types (e.g. local state to S3, or S3 to GCS) since you can generate the new block and compare it side by side with the old one.

Often used alongside Terraform Config Generator.

Features

Advantages

Shows only the fields the selected backend type actually needs, instead of one generic form covering four different backends' arguments.
Always includes `encrypt = true` for the S3 backend, matching current Terraform security guidance for state file encryption at rest.
Validates every required field is filled in before generating, catching a missing bucket or connection string immediately.

Limitations

Doesn't cover every Terraform backend type (e.g. azurerm, consul, http), only the four most commonly used ones.
Backend blocks can't use variables by design, so this tool can only produce literal, static configuration, you'll need to hand-edit per environment (dev/staging/prod) or use `-backend-config` flags for that.

Examples

S3 backend with DynamoDB locking

Input

backendType: s3, bucket: my-app-tfstate, key: prod/network.tfstate, region: us-east-1, dynamodbTable: terraform-locks

Output

terraform {
  backend "s3" {
    bucket         = "my-app-tfstate"
    key            = "prod/network.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

encrypt = true is always included for the S3 backend regardless of input, matching Terraform's recommended default for state file encryption.

Best Practices & Notes

Best Practices

Use a distinct `key` (S3) or `prefix` (GCS) per environment so dev, staging, and prod state files never collide in the same bucket.
Restrict IAM/service account permissions on the state bucket and lock table to only the principals that run Terraform, since the state file often contains sensitive resource attributes in plaintext.
For the S3 backend, enable versioning on the state bucket separately from this generator, so you can recover from an accidental state corruption.

Developer Notes

Backend configuration blocks are one of the few places in Terraform's language that cannot reference variables, locals, or data sources, they're parsed and resolved before the rest of the configuration during `terraform init`, so every field this generator produces is deliberately rendered as a literal string rather than an expression.

Terraform Backend Generator Use Cases

Setting up remote state for a new Terraform root module
Migrating an existing module from local state to a remote backend
Standardizing backend block formatting across a team's modules

Common Mistakes

Trying to reference a variable inside the backend block, which Terraform rejects since backend configuration must be static.
Reusing the same S3 `key` across multiple environments, causing one environment's Terraform run to silently overwrite another's state.

Tips

Run this after the Terraform Generator so your new module already has a resource to manage before you wire up remote state for it.

Terraform Backend Generator