or Terraform can delete your data

Not specified by the original author.

TL;DR

Set termination_protection to true on every production Aiven service in your Terraform config. It does not protect everything though: logical databases, topics, and other nested configs can still be removed even with protection on.

Steps

1. Set termination_protection to true on every production Aiven service in your Terraform config. That blocks Terraform from deleting the service. It does not protect everything though: logical databases, topics, and other nested configs can still be removed even with protection on. Always run terraform plan first and scan it for any action that deletes or replaces a stateful service before you apply.

When to use

You are seeing this: That blocks Terraform from deleting the service. Use this skill when you run into "Set termination_protection on Aiven services or Terraform can delete your data".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (terraform provider index): documents the gotcha that recreating a stateful Aiven service with Terraform deletes the service and all its data before creating it again. Changing properties like project or resource name triggers a replacement, and agents driving Terraform runs can wipe production data with a routine apply.

Verified resolution: Set termination_protection to true on every production Aiven service in your Terraform config. That blocks Terraform from deleting the service. It does not protect everything though: logical databases, topics, and other nested configs can still be removed even with protection on. Always run terraform plan first and scan it for any action that deletes or replaces a stateful service before you apply.

Source URL: https://github.com/aiven/terraform-provider-aiven/blob/HEAD/docs/index.md

Not specified by the original author.

TL;DR

Set deletionprotection = false on the resource in config. 2. terraform apply to record the change. 3. terraform destroy (or remove the resource) now proceeds. Do not set deletionprotection = false across the whole config "to make destroy work".

When to use

You are seeing this: Meaning: the resource was created with deletionprotection = true (the default for things like Cloud SQL instances). Use this skill when you run into "Terraform google provider refuses destroy: deletionprotection defaults".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Steps

1. Meaning: the resource was created with deletion_protection = true (the default for things like Cloud SQL instances). Terraform will not destroy it until you explicitly lower the guard.
2. Fix:
3. Set deletion_protection = false on the resource in config.
4. terraform apply to record the change.
5. terraform destroy (or remove the resource) now proceeds.
6. Do not set deletion_protection = false across the whole config "to make destroy work". The protection exists so a wrong workspace or a typo does not nuke production data. Flip it per resource, destroy, and consider flipping it back if the resource is recreated.
7. Agent traps:

• Destroying a whole environment in CI and hitting this on the database: expected. Handle it as a deliberate step, not an error to route around.
• The state file still lists the resource after a failed destroy. Do not hand-edit state to remove it; fix the config and re-run.
• Some resources have additional guards (like bucket force_destroy for non-empty buckets). Read the specific resource's docs; each guard has its own flag.

5. Verify: terraform plan -destroy shows the resource planned for destruction with no protection error before you approve the real destroy.

Verified 2026-09-26 on the google provider docs: deletion_protection is documented on protected resources (e.g. Cloud SQL) with destroy blocked until disabled. This is provider-documented safety behavior.

Not specified by the original author.

TL;DR: terraform destroy is the most irreversible command in the toolchain. The safe workflow treats it like apply: plan the destroy, review every line, require approval, then destroy the plan. Never as a casual cleanup. Check for: stateful resources (databases, buckets, key vaults), resources shared with other workspaces (look for anything another config references), and anything whose name you do not recognize.

The fix

TL;DR: terraform destroy is the most irreversible command in the toolchain. The safe workflow treats it like apply: plan the destroy, review every line, require approval, then destroy the plan. Never as a casual cleanup. Check for: stateful resources (databases, buckets, key vaults), resources shared with other workspaces (look for anything another config references), and anything whose name you do not recognize.

When

Decommissioning an environment, removing an ephemeral workspace, tearing down a failed experiment. Never as a casual cleanup.

Steps

1. terraform plan -destroy -out=destroy.tfplan. This is a full plan in destroy mode: every resource listed for deletion.
2. Review the destroy plan line by line. Check for: stateful resources (databases, buckets, key vaults), resources shared with other workspaces (look for anything another config references), and anything whose name you do not recognize.
3. Get explicit human approval for the destroy plan. This is the approval gate; the plan file is the artifact being approved.
4. Back up anything stateful first: snapshots, exports, bucket copies. "We can recreate it" is not a backup.
5. terraform apply destroy.tfplan. Watch it complete; do not walk away from a destroy.

Rules for agents

1. Never terraform destroy -auto-approve. The flag exists; using it on destroy is never justified.
2. -target with destroy is for surgical removal of one resource, not for avoiding review. A targeted destroy still needs its own plan review.
3. If the destroy plan includes resources you did not expect, stop. Unexpected entries mean the config or workspace is not what you think; destroying first and asking later is irreversible.
4. After destroy, verify in the console that the critical resources are actually gone AND that nothing shared was affected. Then remove the workspace/config so nobody re-applies it by accident.

When to use this

• This covers exactly what the title says: Terraform workflow.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Terraform; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Terraform behavior.

plan -destroy creates a destroy plan; apply with the plan file executes exactly the reviewed destroy set. Verified against live docs 2026-09-26.