Forem: Terrateam

7 Best Terraform Cloud Alternatives for 2025

Terrateam — Tue, 18 Mar 2025 22:27:31 +0000

7 Best Terraform Cloud Alternatives for 2025

HashiCorp's pricing model change has prompted organizations to look for alternatives to Terraform Cloud. Several powerful options have emerged, offering cost predictability and control over infrastructure automation, extending beyond basic Terraform use.

Modern DevOps teams need tools that save costs, provide reliable state management, smooth CI/CD integration, and policy enforcement. The right tool can improve productivity and resource effectiveness.

This article reviews seven Terraform Cloud alternatives, focusing on deployment models, operational needs, and integration features. Each tool’s strengths help you choose the best fit for your organization's requirements.

Factors in Selecting Alternatives

Evaluate tools by looking at deployment models, operational needs, and integration features. Self-hosted options offer more control and security but require existing infrastructure management skills and data sovereignty requirements. SaaS solutions provide quick deployment and reduce operational overhead.

Key features to consider are state management, workspace organization, and CI/CD integration. Reliable state locking and versioning are important. Supporting multiple environments and team structures impacts operational success. Tools should support automated plan generation and apply operations and drift detection within CI/CD pipelines. GitOps lets teams manage infrastructure changes through pull requests, facilitating code review and maintaining a change audit trail.

Alternatives for Infrastructure Automation

Terrateam: GitOps-First Terraform Automation

Terrateam is a GitOps-first alternative to Terraform Cloud, built for teams automating infrastructure in GitHub. It integrates directly with pull request workflows, enforcing code reviews and automating Terraform, OpenTofu, Pulumi, CDKTF, and more. Everything runs within GitHub without requiring an external UI, keeping your workflow simple and secure. State files remain within your infrastructure, and advanced workflow features support complex, multi-step deployments. For teams using GitHub, Terrateam provides a lightweight and scalable alternative without the complexity of extra tooling.

Atlantis: Open-Source Self-Hosted GitOps

Atlantis automates Terraform workflows through pull requests, maintaining clear audit trails. It integrates with Git repositories, offering a standardized workflow for reviewing and applying changes. Its self-hosted nature requires ongoing maintenance.

Terrakube: 100% Open-Source Platform

Terrakube provides a solution with private registry support and custom workflows, integrating with major VCS systems and allowing extensive customization. It suits teams wanting full control over infrastructure management. Recent updates include workspace importers for Terraform Cloud migrations and OpenTofu integration.

Burrito: Lightweight GitOps Automation

Burrito manages Terraform code through CI/CD pipelines. Its lightweight nature and GitOps alignment suit teams wanting simple workflows with effective drift detection. Burrito runs within infrastructure, providing security and control over operations.

Airplane: Infrastructure Automation with Terraform

Airplane enhances Terraform's workflow capabilities with integration and automation features. It uses CI/CD pipelines and tool integration to automate deployments efficiently, making it suitable for teams needing reliable infrastructure.

Teller: Secrets Management and Automation

Teller manages secrets and integrates seamlessly with Terraform automation, securely managing sensitive information and ensuring real-time secret population. It supports CI/CD integration, detecting secret drift before deployment, maintaining secure and efficient process.

EnvZilla: Open-Source Environment Automation

EnvZilla, though not widely documented, aligns with automation needs by promoting environment management and streamlining workflows for Terraform configurations. Its features and integrations are comparable with other discussed alternatives.

Selecting the Right Tool

Your choice depends on specific needs and constraints. Teams focused on GitHub integration might prefer Terrateam or Atlantis. Organizations requiring enterprise features and multi-framework support might find Airplane or Terrakube advantageous. If cost control is a priority, select a solution with comprehensive cost estimation and policy integration.

Start by assessing core requirements like state management, policy enforcement, and collaboration features. Test chosen solutions in controlled environments for compatibility with workflows. Successful implementation depends on setup and team adoption, so invest in training and establishing clear infrastructure automation processes.

Deploying an AWS EKS Cluster with Terraform and GitHub Actions

Terrateam — Tue, 11 Mar 2025 19:58:22 +0000

This guide shows you how to automate EKS cluster deployment using Terraform and GitHub Actions. You'll learn to create a production-ready Kubernetes environment with networking, security, and scaling capabilities.

VPC and Network Architecture

Create a dedicated VPC for the cluster.

resource "aws_vpc" "eks_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "eks-vpc"
  }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.eks_vpc.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name                              = "eks-private-${count.index + 1}"
    "kubernetes.io/role/internal-elb" = "1"
  }
}

Private subnets host the worker nodes while public subnets handle incoming traffic through load balancers. The subnet tags enable automatic discovery by Kubernetes for internal load balancer placement.

EKS Cluster and Node Groups

The EKS cluster consists of a control plane for managing Kubernetes components and worker nodes for running workloads:

resource "aws_eks_cluster" "main" {
  name     = "eks-cluster"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.27"

  vpc_config {
    subnet_ids              = aws_subnet.private[*].id
    endpoint_private_access = true
    endpoint_public_access  = true
  }

  depends_on = [
    aws_iam_role_policy_attachment.eks_cluster_policy
  ]
}

resource "aws_eks_node_group" "main" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "eks-node-group"
  node_role_arn   = aws_iam_role.eks_nodes.arn
  subnet_ids      = aws_subnet.private[*].id

  scaling_config {
    desired_size = 2
    max_size     = 4
    min_size     = 1
  }

  instance_types = ["t3.medium"]
}

The EKS Blueprints for Terraform provide production-ready modules to accelerate cluster deployment. Breaking the configuration into modules improves maintainability:

module "vpc" {
  source = "./modules/vpc"
  # VPC configuration parameters
}

module "eks" {
  source = "./modules/eks"
  # EKS configuration parameters
  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnet_ids
}

Automating Deployments with GitHub Actions

Workflow File

Create a workflow file in .github/workflows to define the deployment process:

name: Terraform AWS Workflow

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

jobs:
  terraform:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions
          aws-region: us-west-2

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        if: github.event_name == 'pull_request'
        run: terraform plan -no-color

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve

State Management

Store Terraform state in S3.

terraform {
  backend "s3" {
    bucket         = "terraform-state-bucket"
    key            = "eks/terraform.tfstate"
    region         = "us-west-2"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
    use_lockfile   = true
  }
}

Managing Production

GitOps and Add-on Management

Deploy ArgoCD using the EKS Blueprints framework:

module "kubernetes_addons" {
  source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons"

  eks_cluster_id = module.eks_blueprints.eks_cluster_id

  enable_argocd = true
  enable_metrics_server = true
  enable_cluster_autoscaler = true
  enable_aws_load_balancer_controller = true

  argocd_helm_config = {
    values = [templatefile("${path.module}/values.yaml", {})]
  }
}

Monitoring and Scaling

Implement automatic scaling based on resource utilization:

resource "aws_autoscaling_policy" "cluster_autoscaling" {
  name = "eks-cluster-autoscaling"
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    target_value = 75.0
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
  }
  autoscaling_group_name = aws_eks_node_group.main.resources[0].autoscaling_groups[0].name
}

Next Steps

Automating EKS with GitHub Actions is a reliable way to manage your new cluster. For teams looking to improve their infrastructure workflows, check out Terrateam (OSS) which provides a GitOps-first approach to managing Terraform in GitHub.

Building a CI/CD Pipeline for Terraform with GitHub Actions (Step-by-Step Guide)

Terrateam — Thu, 06 Mar 2025 19:24:09 +0000

Manual Terraform operations are slow and create bottlenecks. Each deployment requires careful coordination and multiple operations. Automating these operations through a CI/CD pipeline streamlines this tedious process. Research from HashiCorp shows that organizations using automated Terraform workflows deploy infrastructure changes 89% faster than those relying on manual processes.

This guide shows you how to build a CI/CD pipeline using GitHub Actions to automate your Terraform operations. You'll learn how to set up secure authentication with AWS using OpenID Connect (OIDC), manage remote state, and create workflows that automatically validate and apply infrastructure changes. By the end, you'll have a production-ready pipeline that runs format checks and plans on pull requests, then applies changes automatically when code merges to main.

Setting Up the Foundation

Before building your pipeline, you need a GitHub repository for your Terraform configurations and an AWS account for deploying resources. Your repository should follow infrastructure-as-code best practices with clear documentation and structured Terraform files.

Remote State Management

Teams need a reliable system to store and manage Terraform state files. AWS S3 provides remote state storage and locking to prevent concurrent modifications. Configure your system in your Terraform configuration:

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket"
    key            = "terraform.tfstate"
    region         = "us-west-2"
    use_lockfile   = true
    encrypt        = true
  }
}

Secure AWS Authentication

OpenID Connect (OIDC) eliminates the need for storing long-lived AWS credentials in GitHub. GitHub Actions generates short-lived tokens to assume AWS roles, reducing security risks and simplifying credential management.

To set up OIDC:

Create an OIDC provider in AWS IAM using the address https://token.actions.githubusercontent.com.
Create an IAM role with this trust policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::ACCOUNT-ID:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:organization/repository:*"
                }
            }
        }
    ]
}

Creating GitHub Actions Workflows

GitHub Actions uses YAML files in the .github/workflows directory to define CI/CD pipelines. Two workflows are going to be created: one for pull request validation and another for applying changes to production.

Pull Request Validation

Create terraform-plan.yml to run whenever a pull request is created or updated:

name: 'Terraform Plan'
on:
  pull_request:

jobs:
  terraform:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-west-2

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1

      - name: Terraform Init
        run: terraform init

      - name: Terraform Format
        run: terraform fmt -check

      - name: Terraform Plan
        run: terraform plan -out=tfplan

      - name: Add Plan Comment
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `#### Terraform Plan Output
            \`\`\`
            ${process.env.PLAN_OUTPUT}
            \`\`\`
            `;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })

Production Deployment

Create terraform-apply.yml to run when changes merge to main:

name: 'Terraform Apply'
on:
  push:
    branches:
      - main

jobs:
  terraform:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-west-2

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1

      - name: Terraform Init
        run: terraform init

      - name: Terraform Apply
        run: terraform apply -auto-approve

Improving the Pipeline

Add these features to improve your pipeline's functionality and visibility:

Status Badges

Add this badge to your README.md to show pipeline status:

![Terraform CI](https://github.com/{owner}/{repo}/actions/workflows/{workflow-name}/badge.svg)

Plan Output Comments

The workflow automatically posts Terraform plan outputs as comments on pull requests. This helps reviewers understand proposed changes without leaving the PR interface. The plan output uses formatted code blocks for readability and includes resource changes, additions, and deletions.

Automating with Confidence

A well-configured Terraform pipeline with GitHub Actions transforms infrastructure deployment from a manual process into a streamlined workflow. GitHub Actions' features enable teams to test across multiple environments and use specialized runners for complex deployments. The combination of OIDC authentication, remote state management, and automated plan reviews creates a secure and efficient process that reduces deployment time while maintaining high standards for infrastructure changes.

In addition, integrating open-source solutions like Terrateam can further improve your Terraform and GitHub workflows. Terrateam offers automated deployments, customized workflows, and features that strengthen security and compliance, making infrastructure management even more effective.

Migrating from Terraform to OpenTofu

Terrateam — Thu, 06 Feb 2025 19:50:48 +0000

OpenTofu maintains the core functionality that made Terraform successful while introducing important improvements. The project operates under community governance, ensuring features and fixes align with the community. All of the Terraform providers worked with OpenTofu with the OpenTofu registry.

Executing the Migration

The migration to OpenTofu is a straightforward process:

Install OpenTofu using your preferred package manager or download the binary from the OpenTofu releases page.
Update your scripts and CI/CD configurations to use the tofu command instead of terraform:

# Before
terraform init
terraform plan
terraform apply

# After
tofu init
tofu plan
tofu apply

For teams using Terrateam, update your .terrateam/config.yml:

engine:
  name: tofu
  version: 1.9.0

This configuration ensures Terrateam uses OpenTofu for all operations while maintaining your existing GitOps workflow.

Building for the Future

OpenTofu is more than just an alternative to Terraform. It brings the principles of open-source software and community-driven progress to infrastructure as code. The migration process is very simple to do and it's also possible to migrate back to Terraform. The long-term benefits of an open-source solution make OpenTofu a worthwhile investment for organizations committed to infrastructure as code.

5 Open Source Repositories to Level Up Your GitOps

Terrateam — Wed, 05 Feb 2025 15:57:03 +0000

Version controlling your infrastructure is a starting point. The real power comes from automating the deployment pipeline. Teams using GitOps deploy faster and recover from downtime and incidents faster, but this requires the right tools.

Git provides the foundation for GitOps, but teams need specialized tools to put it into practice. This article highlights five open-source projects that help with different parts of a GitOps workflow: feature management, infrastructure automation, and database migrations.

Flagsmith: Feature Flags

Flagsmith lets teams manage feature flags, and it integrates with GitOps workflows using Terraform. Feature flags can be stored in Git, ensuring changes go through the same review process as infrastructure updates.

from flagsmith import Flagsmith

flagsmith = Flagsmith(
    environment_key="your_key",
    default_flag_handler=lambda flag: False
)

# Fetch and embed flag states at runtime
flags = flagsmith.get_environment_flags()

In a GitOps setup, feature flags should be stored in Git and deployed alongside other code changes. Teams can enforce flag updates only when a corresponding application version is deployed. CI/CD pipelines (e.g., GitHub Actions, GitLab CI, or Terrateam) handle these updates.

With GitOps, every feature flag change is tracked in Git, making it easy to see what changed and roll back if needed.

Terrateam: Infrastructure Automation

Terrateam integrates Terraform and OpenTofu directly into pull request workflows. It validates infrastructure changes before merging and applies them after approval.

workflows:
  - tag_query: "dir:infrastructure/staging"
    plan:
      - type: env
        name: TF_VAR_example
        cmd: ["echo", "Set custom environment variable"]
      - type: init
      - type: plan
    apply:
      - type: run
        cmd: ["echo", "Running custom apply script"]
      - type: init
      - type: apply

parallel_runs: 3

cost_estimation:
  enabled: true

Terrateam integrates with GitHub Actions and Secrets, providing plan outputs and cost estimates directly in pull requests. It ensures ordered execution to prevent dependency-related failures and maintains a full audit trail of infrastructure changes.

ArgoCD: Kubernetes Deployment

ArgoCD brings GitOps to Kubernetes by continuously monitoring and syncing cluster states with Git.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook

ArgoCD helps maintain the desired state, with configurable sync policies. It supports PreSync, Sync, and PostSync hooks for deployment changes and allows rollbacks.

# Sync an application
argocd app sync guestbook

# Rollback to a previous version
argocd app rollback guestbook

FluxCD: Kubernetes Reconciliation

FluxCD runs as a Kubernetes controller, reconciling Git repositories with cluster states. It follows a pull-based model and scales across multiple clusters.

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: app-repository
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/org/repository
  ref:
    branch: main

FluxCD supports multi-tenant deployments using Kubernetes namespaces and Role-Based Access Control. It integrates with Helm and Kustomize.

Atlas: Database Schema Management

Atlas manages database schema changes in GitOps workflows using declarative schema definitions.

table "users" {
  schema = schema.main
  column "id" {
    type = int
    auto_increment = true
  }
  column "name" {
    type = varchar(255)
  }
  primary_key {
    columns = [column.id]
  }
}

Atlas integrates with CI/CD pipelines for schema validation and migration:

atlas migrate diff \
--dir "file://migrations" \
--to "file://schema.hcl" \
--name "add_users_table"

Building a Complete GitOps Pipeline

These tools work together to create a full GitOps pipeline. Flagsmith manages feature releases via Terraform, while Terrateam handles infrastructure changes directly through GitHub (and possibly GitLab in the future). ArgoCD and FluxCD ensure reliable application deployments via Kubernetes, and Atlas integrates database schema migrations.

These tools help you build automated, secure, and scalable GitOps pipelines. They're open-source, shaped by real-world usage and community contributions.

If these tools make your life easier, drop them a star on GitHub!

Using GitHub Secrets with Terraform

Terrateam — Tue, 04 Feb 2025 14:18:21 +0000

Protecting Terraform Secrets in GitHub Actions

GitHub Actions offers built-in secrets management that works well with Terraform deployments. This article shows you how to set up GitHub Actions for Terraform, store sensitive data securely, and use these secrets in your infrastructure code. You'll learn practical techniques to keep your automation pipelines running while protecting your credentials from exposure.

Setting Up GitHub Actions for Terraform

The hashicorp/setup-terraform action enables Terraform automation within GitHub Actions pipelines. Create a new workflow file in .github/workflows to run Terraform operations on pull requests and pushes:

name: 'Terraform CI'

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v3
      - name: Terraform Init
        run: terraform init
      - name: Terraform Plan
        run: terraform plan

Managing Secrets in GitHub Actions

GitHub Actions encrypts sensitive information at rest and ensures secrets remain inaccessible outside of workflows. To add secrets to your repository:

Go to your repository's Settings
Select "Secrets and variables" under "Security"
Click "New repository secret"

Reference these secrets in your workflow using the secrets context:

name: Terraform Plan
on: [pull_request]

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v3

      - name: Terraform Init
        env:
          TF_VAR_api_token: ${{ secrets.API_TOKEN }}
        run: terraform init

GitHub Actions automatically redacts secret values from logs and blocks access from untrusted forks or pull requests. The secrets context (${{ secrets.SECRET_NAME }}) ensures sensitive values remain protected during workflow execution.

Integrating Secrets with Terraform Code

Terraform state files store all configuration values, including secrets, in plaintext by default. Use the sensitive attribute to prevent accidental exposure in logs and outputs, but always use a secure backend (e.g. AWS S3 with encryption) to store state safely.

variable "api_token" {
  type        = string
  sensitive   = true
  description = "API token for authentication"
}

provider "aws" {
  region = "us-west-2"
}

For database credentials and other sensitive data:

variable "database_password" {
  type        = string
  sensitive   = true
  description = "Password for database access"
}

resource "aws_db_instance" "example" {
  password = var.database_password
  # Additional configuration...
}

AWS credentials should never be stored in Terraform variables. Instead, use IAM roles, AWS profiles, or environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) to authenticate securely.

Building Secure Infrastructure Automation

Proper secrets management isn't optional: it's a fundamental requirement for infrastructure automation. GitHub Actions' secrets management combined with Terraform's security features creates a strong framework for protecting sensitive data throughout the deployment pipeline.

Terrateam extends these capabilities with automated planning, cost estimation, and environment-specific policies. By implementing these practices and tools, teams can automate infrastructure deployments without compromising security. The result is a deployment pipeline that moves fast while keeping credentials locked down.

OpenTofu Feature Preview: State Encryption

Terrateam — Fri, 19 Apr 2024 14:48:09 +0000

Background

The original proposal for Terraform state encryption was created back in 2016 in the hashicorp/terraform repository. It was created by one of the core project maintainers. The Issue has been stale for years and there's even been an ignored pull request to implement the feature request.

It's clear that this feature request does not align with the HashiCorp roadmap and that they are ignoring the community. Odd considering the fact that they could easily use state encryption as an upsell and tie it into their Vault offering.

One can only speculate why this feature request has been ignored. Perhaps they don't think state encryption is important to a security story or that they think encryption at-rest is sufficient.

Introduction

In this blog post we'll briefly go over the new state encryption feature coming out in OpenTofu 1.7. This is a work-in-progress and various implementation details of the feature could possibly change.

Video

If you want to watch a video explaining all of the aspects of state encryption, check out the official video released by OpenTofu: https://www.youtube.com/embed/rR4IbhlRSkI?si=IRt95ACIDA6nTeyy

Why state encryption is important

When creating resources with OpenTofu, sensitive data or secrets are stored in the state file. The state file is in clear-text and unencrypted. This opens up the opportunity for someone with access to the state file to gain elevated access to another system using the clear-text sensitive data in the state file.

With data encryption, OpenTofu can be passed an encryption key to encrypt a state file or plan file. Environment variables or third-party key management systems such as AWS KMS, GCP Secrets Manager, or Azure Keyvault can be used to generate the client-side key. OpenTofu uses the key to encrypt not only the state file but also the plan file.

Since this is client-side encryption, an attacker would have to have access to the state storage and the encryption key to read sensitive data from the state file.

This improves an organizations security posture by following the standard layered security model.

Configuring encryption

The State encryption technical documentation goes into detail on how to configure state and plan encryption in your OpenTofu code.

Enable encryption

In order to use the new encryption feature, you must include encryption in the terraform block:

terraform {
  encryption {
    // Encryption options
  }
}

There are a few other options you must specify to enable encryption. These include configuring your key_provider and method. See State encryption for details. Official documentation to come
when 1.7 is released.

Gotchas

There are a few gotchas with this implementation that may change over time.

Encryption can only be configured globally.
Pre-configured encryption settings cannot be included in modules.
Encryption only protects state and plan files at-rest.
Encryption does not change the output shown by the tofu command (json/show/plan).
Encryption only protects against unauthorized access

Key rollover

Key rollover is the ability to transition from one encryption key method to another.

To facilitate a rollover, the fallback configuration block should be used when renaming key providers or methods.

Environment variables

Encryption can also be configured using environment variables for maximum flexibility. All of the configuration explained in the State encryption can be configured using the TF_ENCRYPTION
environment variable and passed to the tofu command.

Timeline

State encryption is slated to be released with OpenTofu 1.7. This will potentially be followed up by a state encryption library in OpenTofu 1.8.

Interesting links

Terrateam

Terrateam integrates seamlessly with OpenTofu. Schedule a demo to see OpenTofu and Terrateam side by side.