> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Features in v170

> Overview of OpenTofu v1.7.0 introducing state encryption to protect state and plan files and a removed block to forget resources without destroying the underlying infrastructure

Let's look at the key features introduced in OpenTofu v1.7.0 and how to use them safely. This release focuses on state protection and flexible state management, with two notable additions:

* State encryption for protecting state and plan files at rest (local and backend).
* The `removed` block to forget resources from state without destroying the underlying infrastructure.

These are features the community has asked for to improve security and operational control over infrastructure as code.

![A presentation slide titled "Upcoming Features" showing two feature cards: an orange "State Encryption" card with a lock icon and a purple "Removed Block" card with a document-and-trash icon.](https://mintcdn.com/kodekloud-c4ac6d9a/6iY8H-GlEe_e7L62/images/OpenTofu-A-Beginners-Guide-to-a-Terraform-Fork-Including-Migration-From-Terraform/OpenTofu-Beyond-Basics/Features-in-v170/upcoming-features-state-encryption-removed-block.jpg?fit=max\&auto=format\&n=6iY8H-GlEe_e7L62\&q=85\&s=3b0386f3b73807db7ddb8436c0ec85d7)

## Overview

* State encryption ensures `tfstate` and plan artifacts are stored encrypted at rest, both for local storage and when using a backend. It also works with the OpenTofu remote state data source.
* The `removed` block provides a safe method to stop OpenTofu from managing a resource while leaving the resource intact in the provider.

For more background on OpenTofu concepts and commands, see the official OpenTofu documentation: [OpenTofu Documentation](https://opentofu.io/docs/) (reference).

## State encryption

State encryption protects sensitive data that may be present in state or plan files. Before you enable encryption on an existing state, make a full backup of your current state file (for example, `terraform.tfstate` or any backend snapshot). Enabling encryption without retaining the key will make existing and future encrypted state and plan files unrecoverable.

Encryption makes your state and plan files unreadable without the corresponding key. Always back up your state and ensure you securely store the encryption key before enabling encryption.

### Example: AES-GCM with PBKDF2 key provider

This HCL example configures OpenTofu to use a PBKDF2-derived key provider and AES-GCM encryption. Important: when migrating an existing unencrypted state, include an empty `fallback {}` block so OpenTofu can read the prior unencrypted data during the migration step. Remove `fallback {}` after the migration is complete.

```hcl theme={null}
terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = "" # Enter a passphrase here
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method   = method.aes_gcm.my_method
      fallback {} # Keep this empty fallback while migrating from unencrypted state. Remove after migration.
    }
  }
}
```

Best practices and important notes:

* Store your passphrase (or derived key) in a secure secret manager or key vault. If you lose it, encrypted state and plan files cannot be decrypted.
* After validating the migration to encrypted state, remove the `fallback {}` block to stop accepting the legacy unencrypted format.
* Test the full workflow (plan/apply and remote state reads) in a non-production environment before rolling out to production.

### Migrating back to an unencrypted state

Reverting to an unencrypted state is supported but requires explicit configuration: set the target unencrypted method and include the prior encryption method in `fallback` during migration. As with enabling encryption, back up state, validate changes, and verify recoverability after migration.

## The removed block

The `removed` block is for cases when you want to stop managing a resource with OpenTofu but keep the actual resource running with the provider.

Typical workflow:

1. Create and apply a managed resource as usual.
2. Remove the resource block from your configuration when you no longer want OpenTofu to manage it.
3. Add a `removed` block that points to the resource address via the `from` attribute.
4. Run `tofu plan` and `tofu apply` — OpenTofu will remove the resource from state without issuing a destroy to the provider.

Use `removed` when you need to hand off management of a resource to another tool or manage it manually. Always test the removal in a safe environment and keep state backups.

### Example: create then stop managing a local file resource

1. Define a managed resource:

```hcl theme={null}
resource "local_file" "test" {
  filename = "test.txt"
  content  = "hello world"
}
```

2. Create the resource:

```bash theme={null}
tofu init
tofu apply
# Confirm creation when prompted; this will create test.txt with "hello world".
```

3. Stop managing the resource but retain the file:

* Remove the `local_file.test` resource block from your configuration.
* Add the `removed` block that refers to the resource address.

```hcl theme={null}
removed {
  from = "local_file.test"
}
```

4. Run a plan to confirm the state change:

```bash theme={null}
tofu plan
```

OpenTofu will indicate that the resource is being forgotten from the state (no destroy will be performed on the underlying resource). After `tofu apply`, the resource is removed from the state file but the physical file `test.txt` remains on disk.

## Quick reference table

| Feature | Purpose | Notes / Example |
| -: | - | - |
| State encryption | Protect state and plan files at rest | Example: AES-GCM with PBKDF2 key provider (see example HCL above). Back up state and keys. |
| Removed block | Remove resource from state without destroying it | Use `removed { from = "resource_address" }` after deleting resource block from config. |

## Summary and recommendations

* OpenTofu v1.7.0 brings state encryption (AES-GCM example shown) and the `removed` block for safer operational control.
* Always back up state files and securely store encryption keys before enabling encryption.
* Test encryption and removal workflows in a non-production environment, verify remote state reads, and remove `fallback {}` only after successful migration verification.
* Refer to the OpenTofu docs for more details and provider-specific considerations: [OpenTofu Documentation](https://opentofu.io/docs/).

> **[Watch Video](https://learn.kodekloud.com/user/courses/opentofu-a-beginners-guide-to-a-terraform-fork-including-migration-from-terraform/module/5a06d90f-8a8a-49a9-99d6-30b70e37bc83/lesson/42e8ddd9-581a-4a43-a1c0-dea11db5470f)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.