Realistic Terraform plans without an account
Building or demoing infrastructure-as-code tooling means you need example terraform plan output, but you do not want to point it at real cloud credentials or state. This tool generates a believable plan using Terraform’s actual change notation and a correct summary line, all locally.
How it works
A seed drives a mulberry32 pseudo-random generator so the plan is reproducible.
- For each resource, an action is chosen: create, update, destroy, or replace.
- Lines use the real symbols. Created attributes show
+ name = value, updated attributes show~ name = old -> new, and destroyed attributes show- name = value -> null. - The summary tallies the actions:
Plan: 3 to add, 1 to change, 2 to destroy.
A replace (-/+) counts as both an add and a destroy, matching Terraform’s own arithmetic.
Terraform plan notation explained
Terraform uses four action symbols that this generator replicates exactly:
+(create) — a resource that does not yet exist in state will be created. All attribute lines show+ key = value.~(update in-place) — an existing resource will be modified without being destroyed. Changed attributes show~ key = "old_value" -> "new_value". Unchanged attributes are omitted.-(destroy) — a resource will be removed from infrastructure. All attributes show- key = value -> null.-/+(replace) — a resource must be destroyed and recreated because an attribute that cannot be updated in-place has changed (for example, changing an EC2 instance’s AMI). This counts as both a destroy and a create in the summary line.
The summary line format is exactly Plan: N to add, N to change, N to destroy. where the replace action increments both the add and destroy counters, which is why the sum of counters can exceed the number of resources.
Resource types that appear
The generator uses common AWS resource types that IaC developers recognise at a glance:
aws_instance— EC2 compute, with attributes likeami,instance_type, andsubnet_idaws_s3_bucket— storage, withbucket,acl, andversioningaws_security_group— network, with ingress and egress rule blocksaws_db_instance— RDS, withengine,instance_class, andallocated_storageaws_iam_role— identity, withnameandassume_role_policyaws_lambda_function— serverless, withfunction_name,runtime, andhandler
These are chosen because they appear in nearly every real-world AWS architecture, so the output looks immediately familiar to anyone who has worked with Terraform on AWS.
Practical tips
- Use a small resource count (3 to 8) for clean screenshots in documentation or blog posts.
- Use a larger count (20 to 50) to test how a CI dashboard, PR comment bot, or diff viewer handles a lengthy plan.
- Fix the seed in test fixtures so the generated output is deterministic across runs — useful for snapshot tests that assert on plan content.
- Because all output is local and no cloud credentials are involved, you can generate freely without AWS account access.