Forem: kvendingoldo

How to create AWS Serverless Valkey via OpenTofu

kvendingoldo — Fri, 01 Aug 2025 11:01:50 +0000

Introduction

AWS introduced Amazon ElastiCache Serverless in November 2023. However, many developers still rely on the older hosted Redis clusters - which can be a real pain in the back to manage and scale.

In this tutorial, we will set up ElastiCache Serverless with the Valkey engine by using OpenTofu.

Open Source stack focus

This guide is based entirely on an open source stack:

Valkey instead of Redis. Redis is still technically open source, but due to the license change (SSPL), it is no longer a safe or sustainable option for many applications. Valkey is the community-driven alternative that remains completely open.
OpenTofu instead of Terraform for the same reason: Terraform is no longer entirely open source due to the transition to the BSL license.

Despite that, you can still use Redis and Terraform if they suit your needs in scope of this guide.

Prerequisites

Before you begin, make sure you have the following set up:

AWS Account with the sufficient IAM permissions to create ElastiCache resources. If you don't already have it, you can sign up for an AWS Free Tier account.
AWS CLI installed and configured with valid credentials. You can follow the official AWS CLI setup guide if needed.
A working directory for your code. In this guide, I’ll use directory elasticache_guide

Install OpenTofu to your machine

Since we’ll be working with OpenTofu, the first step is installing it.

Instead of installing OpenTofu directly, we’ll use tofuutils/tenv — a powerful version manager for OpenTofu, Terraform, Terragrunt, Terramate, and Atmos, written in Go.

We're starting with tenv because OpenTofu evolves rapidly, and having a version manager makes it much easier to switch between versions and stay up to date.

To install tenv follow the instructions in the tenv GitHub README for your operating system. Once tenv is set up, you can install a specific version of OpenTofu by running:
$ tenv tofu install 1.10.3

That’s it — you now have OpenTofu ready to use!

Create AWS Elasticache OpenTofu module

In this guide, we’ll adhere to Terraform and OpenTofu best practices by creating a dedicated OpenTofu module to provision ElastiCache Serverless.

If you're new to the Terraform modules or want a refresher on best practices, check out Terraform Module Best Practices by DevOpsCube article.

Let’s walk through the process step by step.

Step 1

Create a new directory for the module inside your working folder:

$ mkdir -p elasticache_guide/modules/elasticache_serverless

Step 2

Inside the elasticache_guide/modules/elasticache_serverless directory, create a file named main.tf. This file provides a basic specification of the ElastiCache cluster.

resource "aws_elasticache_serverless_cache" "this" {
 count = var.create ? 1 : 0

 engine = var.engine
 name   = var.cache_name

 dynamic "cache_usage_limits" {
   for_each = length(var.cache_usage_limits) > 0 ? [var.cache_usage_limits] : []
   content {
     dynamic "data_storage" {
       for_each = try([cache_usage_limits.value.data_storage], [])
       content {
         maximum = try(data_storage.value.maximum, null)
         minimum = try(data_storage.value.minimum, null)
         unit    = try(data_storage.value.unit, "GB")
       }
     }

     dynamic "ecpu_per_second" {
       for_each = try([cache_usage_limits.value.ecpu_per_second], [])
       content {
         maximum = try(ecpu_per_second.value.maximum, null)
         minimum = try(ecpu_per_second.value.minimum, null)
       }
     }
   }
 }
 daily_snapshot_time      = var.daily_snapshot_time
 description              = coalesce(var.description, "Serverless Cache")
 kms_key_id               = var.kms_key_id
 major_engine_version     = var.major_engine_version
 security_group_ids       = var.security_group_ids
 snapshot_arns_to_restore = var.snapshot_arns_to_restore
 snapshot_retention_limit = var.snapshot_retention_limit
 subnet_ids               = var.subnet_ids
 user_group_id            = aws_elasticache_user_group.main.id

 timeouts {
   create = try(var.timeouts.create, "40m")
   delete = try(var.timeouts.delete, "80m")
   update = try(var.timeouts.update, "40m")
 }

 tags = var.tags
}

Step 3

Create the access.tf file. Here, we will manage ElastiCache users.

resource "random_string" "auth_user_password" {
 for_each = { for k, v in var.access_users : k => v if try(v.generate_password, false) }

 length           = 16
 special          = false
 override_special = "/@£$"
}

#
# Regenerate auth_user / access_u2g_mapping
#
locals {
 access_users = {
   for k, v in var.access_users : k => {
     generated_name = format("%s-%s", var.cache_name, k)
     access_string  = v["access_string"]
     auth_type      = v["auth_type"]
     engine         = v["engine"]
     passwords      = try(v["generate_password"], false) ? [random_string.auth_user_password[k].result] : try(v["passwords"], null)
   }
 }
}

resource "aws_elasticache_user" "main" {
 for_each = local.access_users

 user_id       = each.value["generated_name"]
 user_name     = each.value["generated_name"]
 access_string = each.value["access_string"]
 engine        = each.value["engine"]

 authentication_mode {
   type      = each.value["auth_type"]
   passwords = each.value["passwords"]
 }

 tags = var.tags
}

resource "aws_elasticache_user_group" "main" {
 user_group_id = var.cache_name
 engine        = var.engine

 tags = var.tags

 lifecycle {
   ignore_changes = [user_ids]
 }
}

resource "aws_elasticache_user_group_association" "main" {
 for_each = local.access_users

 user_group_id = aws_elasticache_user_group.main.user_group_id
 user_id       = aws_elasticache_user.main[each.key].user_id

 depends_on = [
   aws_elasticache_user.main,
   aws_elasticache_user_group.main
 ]
}

Pay attention, that when you’re working with AWS ElastiCache Serverless, there are two primary ways to access and manage your cluster:

IAM Authentication: Authenticate connections to ElastiCache for Valkey using AWS IAM identities. This method improves your security posture and simplifies administrative tasks, especially when operating within the AWS ecosystem.
Traditional password-based authentication: Each cache user has a long-lived password that is used directly with the AUTH command to authenticate client connections. This method is straightforward but requires careful credential management to maintain security.

Step 4

Create the outputs.tf file. It’s the default file for OpenTofu module outputs.

output "arn" {
 description = "The amazon resource name of the serverless cache"
 value       = try(aws_elasticache_serverless_cache.this[0].arn, null)
}

output "create_time" {
 description = "Timestamp of when the serverless cache was created"
 value       = try(aws_elasticache_serverless_cache.this[0].create_time, null)
}

output "endpoint" {
 description = " Represents the information required for client programs to connect to a cache node"
 value       = try(aws_elasticache_serverless_cache.this[0].endpoint, null)
}

output "full_engine_version" {
 description = "The name and version number of the engine the serverless cache is compatible with"
 value       = try(aws_elasticache_serverless_cache.this[0].full_engine_version, null)
}

output "major_engine_version" {
 description = "The version number of the engine the serverless cache is compatible with"
 value       = try(aws_elasticache_serverless_cache.this[0].major_engine_version, null)
}

output "reader_endpoint" {
 description = "Represents the information required for client programs to connect to a cache node"
 value       = try(aws_elasticache_serverless_cache.this[0].reader_endpoint, null)
}

output "status" {
 description = "The current status of the serverless cache. The allowed values are CREATING, AVAILABLE, DELETING, CREATE-FAILED and MODIFYING"
 value       = try(aws_elasticache_serverless_cache.this[0].status, null)
}

output "access_users" {
 value = local.access_users
}

Step 5

Create the variables.tf file. It’s the file for OpenTofu module variables, where we pre-defined some default values.

variable "create" {
 description = "Determines whether serverless resource will be created."
 type        = bool
 default     = true
}

variable "cache_name" {
 description = "The name which serves as a unique identifier to the serverless cache."
 type        = string
 default     = null
}

variable "cache_usage_limits" {
 description = "Sets the cache usage limits for storage and ElastiCache Processing Units for the cache."
 type        = map(any)
 default     = {}
}

variable "daily_snapshot_time" {
 description = "The daily time that snapshots will be created from the new serverless cache. Only supported for engine type `redis`. Defaults to 0."
 type        = string
 default     = null
}

variable "description" {
 description = "User-created description for the serverless cache."
 type        = string
 default     = null
}

variable "engine" {
 description = "Name of the cache engine to be used for this cache cluster. Valid values are `memcached` or `redis`."
 type        = string
 default     = "redis"
}

variable "kms_key_id" {
 description = "ARN of the customer managed key for encrypting the data at rest. If no KMS key is provided, a default service key is used."
 type        = string
 default     = null
}

variable "major_engine_version" {
 description = "The version of the cache engine that will be used to create the serverless cache."
 type        = string
 default     = null
}

variable "security_group_ids" {
 description = "One or more VPC security groups associated with the serverless cache."
 type        = list(string)
 default     = []
}

variable "snapshot_arns_to_restore" {
 description = "The list of ARN(s) of the snapshot that the new serverless cache will be created from. Available for Redis only."
 type        = list(string)
 default     = null
}

variable "snapshot_retention_limit" {
 description = "(Redis only) The number of snapshots that will be retained for the serverless cache that is being created."
 type        = number
 default     = null
}

variable "subnet_ids" {
 description = "A list of the identifiers of the subnets where the VPC endpoint for the serverless cache will be deployed."
 type        = list(string)
 default     = []
}

variable "timeouts" {
 description = "Define maximum timeout for creating, updating, and deleting serverless resources."
 type        = map(string)
 default     = {}
}

variable "tags" {
 description = "A map of tags to add to all resources"
 type        = map(string)
 default     = {}
}

#
# Access
#
variable "access_users" {
 default = {}
}

Step 6

Create the versions.tf file. It’s metadata file with OpenTofu and providers versions.

terraform {
 required_version = ">= 1.0"

 required_providers {
   aws = {
     source  = "hashicorp/aws"
     version = ">= 5.77"
   }
 }
}

That’s it - you’ve created your own module for managing AWS ElastiCache Serverless! Now, let’s move on to building the dependent infrastructure that we will use this guide.

Create dependent AWS infrastructure

The AWS ElastiCache module is insufficient for our guidance; to use the cluster, we must construct additional infrastructure such as vpc, subnets, kms, and security groups. Let's build all of it in the elasticache_guide/main.tf file:

module "vpc" {
 source  = "terraform-aws-modules/vpc/aws"
 version = "~> 5.0"

 name = "kvendingoldo-demo-elasticache-serverless"
 cidr = "10.0.0.0/16"

 azs             = ["us-east-1a", "us-east-1b"]
 private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]

 enable_dns_hostnames = true
 enable_dns_support   = true
}

module "security_groups" {
 source  = "terraform-aws-modules/security-group/aws"
 version = "~> 5.0"

 name        = "kvendingoldo-demo-elasticache-serverless"
 description = "Security group for ElastiCache Serverless"
 vpc_id      = module.vpc.vpc_id

 security_group_rules = {
   ingress_self = {
     type        = "ingress"
     from_port   = 6379
     to_port     = 6379
     protocol    = "tcp"
     self        = true
     description = "Allow self-traffic"
   }
   egress_all = {
     type        = "egress"
     from_port   = 0
     to_port     = 0
     protocol    = "-1"
     cidr_blocks = ["0.0.0.0/0"]
     description = "Allow all egress"
   }
 }
}

module "kms_elasticache_serverless" {
 source  = "terraform-aws-modules/kms/aws"
 version = "~> 1.0"

 alias       = "kvendingoldo-demo-elasticache-serverless"
 description = "KMS key for ElastiCache Serverless encryption"

 enable_key_rotation = true
}

module "elasticache_serverless" {
 source = "./modules/elasticache_serverless"

 engine     = "valkey"
 cache_name = "kvendingoldo-demo-elasticache-serverless"

 cache_usage_limits = {
   data_storage = {
     maximum = 2 # 2Gb
   }
   ecpu_per_second = {
     maximum = 2000 # Approximate for 2 vCPUs (1000 per vCPU)
   }
 }

 daily_snapshot_time = "22:00"
 description         = "Valkey serverless cluster for kvendingoldo demo"

 kms_key_id           = module.kms_elasticache_serverless[0].key_arn
 major_engine_version = "7"
 security_group_ids = [
   module.security_groups["elasticache_serverless"].id
 ]
 subnet_ids = module.vpc.private_subnets

 snapshot_retention_limit = 7

 access_users = {
   "admin-iam" = {
     access_string = "on ~* +@all"
     engine        = "valkey"
     auth_type     = "iam"
   }
   "admin-pwd" = {
     access_string     = "on ~* +@all"
     engine            = "valkey"
     auth_type         = "password"
     generate_password = true
   }
 }
}

output "elasticache_serverless_endpoint" {
 value = module.elasticache_serverless.endpoint
}

output "elasticache_serverless_users" {
 value = module.elasticache_serverless.access_users
}

As you can see, this file partially uses community modules from the Internet to create the VPC, KMS, and security group. If you like, you can use native AWS Terraform resources instead.

Apply the OpenTofu code

Before applying our AWS resources, we need to initialize OpenTofu. During this step, OpenTofu will create the state file and download all required providers.

To do this, run the following command:

$ tofu init

Next, let's see what OpenTofu plans to do by generating an execution plan using the following command:

$ tofu plan

After reviewing the plan, it’s finally time to apply our configuration using the following command:

$ tofu apply -auto-approve

Once completed, OpenTofu will display the details of the provisioned ElastiCache Valkey instance.

Connect to the cluster

Step 1: Get an endpoint

As mentioned earlier, you’ll see the connection details in the OpenTofu output. Alternatively, you can retrieve the endpoint using the AWS CLI with the following command:

aws elasticache describe-serverless-caches --query "serverlessCaches[?cacheName=='kvendingoldo-demo-elasticache-serverless'].endpoint"

Step 2: Connect by redis-cli

Valkey is compatible with Redis clients. You can use your preferred client to connect to the endpoint on the default Redis port 6379. In my case, I use redis-cli:

redis-cli -h <serverless_endpoint> -p 6379 -a <your_password>

Run a simple command to confirm connection: ping

You should get a response: PONG

Cleaning up resources

After the checking that everything works you can destroy the created resources when they are no longer needed to avoid unnecessary costs by the following command

$ tofu destroy -auto-approve

This will remove the ElastiCache instance and all related resources.

Conclusion

In this guide, we walked through creating a dedicated OpenTofu module to provision AWS ElastiCache Serverless with the Valkey engine, following best practices for infrastructure as code. We covered setting up OpenTofu, building reusable modules, and connecting to your Valkey instance.

By leveraging OpenTofu and Valkey, you gain a fully open source and flexible solution for managing serverless caching on AWS, helping you avoid licensing pitfalls and maintain control over your infrastructure.

Feel free to extend the module to fit your needs and explore additional automation opportunities. If you have any questions or want to dive deeper into related topics, just let me know!

Happy caching!

Fix InvalidParameterValueException for AWS Lambda docker images built by GitHub Actions

kvendingoldo — Mon, 31 Mar 2025 09:37:00 +0000

If you're using GitHub Actions to build Docker images for AWS Lambda functions, you might encounter the following error:

InvalidParameterValueException: The image manifest, config or layer media type for the source image \*\*\*.dkr.ecr.\*\*\*.amazonaws.com/myrepository/myimage:latest is not supported.

This error is confusing at first glance — especially if you’ve successfully used the same image with EKS, ECS or other docker-based environments. Here’s what’s going on under the hood.

TL;DR

GitHub Actions (docker/build-push-action@v4) builds OCI images by default with provenance and sbom enabled. However, AWS Lambda only supports Docker v2 manifests — not OCI. To fix the error, disable those features in your GitHub action step:

provenance: false 
sbom: false

Root Cause: OCI vs Docker Image Format

Starting with version 4, docker/build-push-action builds images using the OCI format by default. OCI (Open Container Initiative) is the modern standard that is supported by AWS ECR. However, AWS Lambda does not support OCI image manifests. Lambda only accepts the older Docker v2 schema: application/vnd.docker.distribution.manifest.v2+json

That’s why your image may push to ECR fine but still fail at deployment to Lambda with InvalidParameterValueException error. After pushing the image to ECR, you will see something like this in the metadata:

Why Lambda Doesn’t Support OCI

While ECR and ECS support OCI images, Lambda does not— and here’s why:

Lambda implemented container image support in 2020, using the Docker v2 image spec, which was the most stable and frequently used format at the time.
Performance and security constraints: Lambda is designed for quick cold starts and strict security. Supporting full OCI manifests (particularly with SBOMs and provenance metadata) may raise complexity, slow down startup, or expose new attack vectors.
Lambda is not a general container runtime: Lambda's runtime mechanism is restricted, unlike ECS or EKS, which are designed to execute arbitrary containers. Supporting a wider range of image formats is not a priority.

Solution

To remedy the image manifest format issue, modify the docker/build-push-action@v4 step in your GitHub job file as follows:

- name: Build and push Lambda image
 uses: docker/build-push-action@v4
 with:
   context: .
   push: true
   tags: |
     latest
   provenance: false
   sbom: false

Setting both provenance: false and sbom: false disables features that require OCI format, thereby enabling Docker v2 manifest compatibility.

This results in your image being built with the proper media type,application/vnd.docker.distribution.manifest.v2+json which Lambda can consume without trouble.

What are `provenance` and `sbom` options?

In GitHub Actions, the Docker Buildx plugin now enables two features by default:

provenance: true — enables Software Supply Chain Provenance, which attaches build metadata to the image (as per SLSA standards).
sbom: true — enables generation of SBOMs (Software Bill of Materials), a key part of software supply chain security.

Service Compatibility Overview

Final Thoughts

While OCI represents the future of container image standards, AWS Lambda has yet to catch up to it. If you're deploying Lambda functions using GitHub Actions, make sure your image builds are Docker-compatible via modifying the provenance and sbom settings.

Top Terraform/OpenTofu tools to Use in 2025

kvendingoldo — Tue, 04 Feb 2025 08:20:56 +0000

Overview

Infrastructure-as-Code (IaC) has become a trusted approach for managing and provisioning infrastructure. As the field evolves, the number of IaC tools continues to grow, with frequent updates, new features, and improvements being introduced.

One of the most popular tools in this space is Terraform, a leader in the IaC ecosystem. There is a wide range of smaller tools that work alongside Terraform, adding extra features and making it even more powerful.

In this article, we’ll dive into the top most useful Terraform tools for 2025—a curated selection of tools that stand out for their active maintenance, ongoing development, and exceptional user experience.

Pay attention, that last year, Terraform changed its license, leading the community to create a fork called OpenTofu, licensed under MPL-2.0 license. All the tools discussed in this article are fully compatible with both Terraform and OpenTofu and can be used together in mixed environments.

Ready to dive in? Let’s explore these tools and how they can supercharge your IaC workflows.

tenv

tenv is a version manager for Terraform, OpenTofu, Terragrunt, and Atmos, written in Go developed by tofuutils team. It simplifies the management of multiple tool versions. Initially developed as a successor to tfenv and tofuenv, tenv reduces the complexity of versioning, allowing developers and DevOps professionals to focus on building and deploying infrastructure without worrying about versioning issues.

While many users rely on asdf for version management, tenv is specifically tailored for the Terraform ecosystem. It offers advanced features such as HCL parsing for precise version detection and seamless management across supported tools. Besides that tenv is faster, platform-independent (thanks to its binary delivery), and prioritizes enhanced security through features like checksum and signature verification.

Key Features

Versatile Version Management
- Supports managing multiple versions of Terraform, OpenTofu, Terragrunt, and Atmos.
- Allows easy switching between tool versions to suit different project requirements.
Simple Installation
- Simple installation via Homebrew, Choco, Nix, Yay, Scoop, APT, Snapcraft, Docker or many more package managers and options.
Performance & Cross-Platform Compatibility
- tenv is written in Go. It supplies an extensive list of features such as fast speed, efficiency, and uniform support for all main operating systems, including Linux, MacOS, Windows, FreeBSD, OpenBSD, and Solaris.
Signature Verification
- Verifies downloads using cosign and PGP (via gopenpgp), ensuring the integrity and authenticity of tool binaries.
Semver 2.0.0 Compatibility
- Tenv utilizes go-version for semantic versioning and HCL parsing to extract version constraints from files like required_version in Terraform/OpenTofu or Terragrunt HCL files.
Backwards Compatibility
- Fully supports version files used by tfenv (.terraform-version), tofuenv (.opentofu-version), asdf (.tool-versions), and so on.
Callable as a Go Module
- Includes a Semver compatibility promise via the tenvlib wrapper package for seamless integration (details available in TENV_AS_LIB.md).
- Can be used as a library to download OpenTofu with minimum dependencies.

Link: https://github.com/tofuutils/tenv

Aiac

Aiac is an Artificial Intelligence Infrastructure-as-Code Generator developed by Firefly.ai. Implemented as a library and command-line tool (CLI), Aiac leverages Large Language Models (LLM) to generate Infrastructure as Code (IaC) templates, configurations, utilities, queries, and more.

The CLI allows users to ask a model to generate templates for different scenarios (e.g. "get terraform for AWS EC2" or “generate GKE autopilot terraform code”). It composes an appropriate request to the selected provider, and stores the resulting code to a file, and/or prints it to standard output.

Users can define multiple "backends" targeting different LLM providers and environments using a simple configuration file. This automation significantly reduces the time and effort required for routine tasks, empowering cloud engineers to focus on high-value work.

Key Features

Support for Multiple LLM Providers: It includes OpenAI, Amazon Bedrock and Ollama.
Versatile Code Generation: Terraform code / CICD pipelines / OPA policies / Dockerfiles and more.
Simplified Workflow: Allows users to generate IaC templates using simple prompts, and automatically composes requests to the selected LLM provider and saves the output to a file or prints it to standard output.
Time-Saving Automation: Helps to reduce cloud engineers time by simple prompts that do a typical toil.

Link: https://aiac.dev

Atmos

Atmos is a cutting-edge framework designed by Cloud Posse specifically for native Terraform, enabling teams to streamline and optimize their infrastructure management processes.

With Atmos, you can break down your cloud architecture into reusable components, implemented using Terraform "root modules." These components are seamlessly tied together using stack configurations defined in YAML, offering a clear and organized way to manage complex infrastructure setups.

This tool promotes a modular, scalable, and efficient approach to infrastructure management, making it ideal for handling even the most intricate deployments.

Key Features

Terminal UI: A polished interface that simplifies interaction with Terraform, workflows, and commands.
Native Terraform Support: Streamlines orchestration, backend generation, and varfile creation while maintaining full compatibility with vanilla Terraform.
Stacks: Provides a powerful abstraction layer, defined in YAML, for orchestrating and deploying components efficiently.
Components: A flexible abstraction for deployable units, such as Terraform "root" modules, promoting reusability and scalability.
Vendoring: Supports immutable infrastructure by pulling dependencies from remote sources for consistent deployments.
Custom Commands: Extends Atmos’s capabilities by integrating custom commands into stack configurations for enhanced flexibility.
Workflow Orchestration: Comprehensive lifecycle management for cloud infrastructure, from initiation to maintenance.

Link: https://github.com/cloudposse/atmos

Terragrunt

Terragrunt is a widely used open-source tool, often referred to as a "thin wrapper" for Terraform. It enhances Terraform’s capabilities by providing additional tools to keep your configurations DRY ("Don't Repeat Yourself").

Developed by Gruntwork, Terragrunt simplifies managing remote states, handling multiple environments, and executing custom code before or after running Terraform. Beyond these features, it helps maintain a clean, organized codebase, making infrastructure as code more manageable and efficient.

Key Features

DRY Principle: Adheres to the "Don't Repeat Yourself" principle, it simplify Terraform configurations by reducing repetitive code. This approach enhances code maintainability and improves human readability.
Remote State Management: Efficiently manages Terraform's remote state configurations, ensuring stability and scalability. Terragrunt can automatically organize and store state files in popular storage solutions like AWS S3, Google Cloud Storage, Azure Blob Storage, or any other Terraform-supported backends.
Dependency Handling: Simplifies the management of complex module dependencies, especially when execution order is critical.
Multi-Module Efficiency: Optimizes workflows for large-scale deployments involving multiple modules, making it easier to handle extensive infrastructure setups.
Environment-Specific Configuration: Supports the creation of environment-specific configurations (e.g., dev, staging, prod) using HCL (HashiCorp Configuration Language) interpolation, enabling consistent and organized environment management.
Secrets Management: Integrates seamlessly with external secrets management tools like AWS Secrets Manager and HashiCorp Vault, ensuring sensitive data is handled securely.
Configurable Hooks: Supports pre- and post-Terraform hooks, allowing you to execute custom scripts or commands before or after running Terraform commands for greater flexibility and automation.

Link: https://terragrunt.gruntwork.io

Checkov

Checkov is a robust static code analysis (SCA) tool designed for Infrastructure as Code and software composition analysis (SCA). It ensures that your Terraform and other IaC configurations are secure and compliant before deployment.

Similar to Terrascan, Checkov utilizes a Python-based policy-as-code framework, differing from the Rego syntax used in OPA. Its extensive support for multiple technologies makes it a popular choice for teams managing complex cloud and containerized environments.

Key Features

Extensive Built-in Policies: Over 1000 built-in policies cover security and compliance best practices for major cloud providers like AWS, Azure, and Google Cloud.
Versatile Technology Support: compatible with a wide range of technologies, including: Terraform, Terraform Plan, Terraform JSON, CloudFormation, AWS SAM, Kubernetes, Helm, Kustomize, Dockerfile, Serverless framework, Ansible, Bicep, ARM, OpenTofu and more.
Comprehensive Analysis: Uses graph-based scanning to identify misconfigurations, security vulnerabilities, and compliance issues across your IaC.
Support of Terraform and Terraform plan analysis
SCA Capabilities: Performs software composition analysis to detect vulnerabilities in open-source packages and container images.
Secrets Detection: Identifies exposed secrets using techniques like regular expressions, keyword matching, and entropy-based detection.
CI/CD Integration: Seamlessly integrates with CI/CD pipelines, enabling pre-deployment security checks for continuous delivery workflows.
Provides output in multiple formats: CLI, CycloneDX, JSON, JUnit XML, CSV, SARIF, GitHub markdown, and links to remediation guides.

Link: https://github.com/bridgecrewio/checkov

Trivy

Trivy is a comprehensive, all-in-one open-source security scanner developed by aquasecurity and designed to detect vulnerabilities (CVEs), misconfigurations, secrets, and generate SBOMs across a wide range of resources, including code repositories, Terraform code, binary artifacts, container images, and Kubernetes clusters.

By integrating Terraform misconfiguration scanning into its robust ecosystem, Trivy empowers teams to proactively identify and resolve vulnerabilities, ensuring secure and compliant infrastructure deployments. Its ability to streamline security checks across various stages of development and deployment makes it an indispensable tool for modern DevOps workflows.

Key Features

Misconfiguration Detection: Scans for security misconfigurations in Kubernetes clusters, Terraform files, Dockerfiles, and other IaC templates.
Integrated IaC Security: Combines the capabilities of tfsec with Trivy’s broader security features, offering a unified tool for scanning Infrastructure as Code templates, including Terraform, Kubernetes manifests, and Dockerfiles.
Pre-Deployment Validation: Ensures that Terraform configurations are secure and compliant before deployment, reducing risks in production environments.
Vulnerability Scanning Identifies known vulnerabilities in:
- Container images
- Filesystems
- Repositories
- Cloud services like AWS S3 and Lambda.
Cloud Security Scanning: Supports scanning cloud services for security misconfigurations and vulnerabilities, ensuring robust cloud infrastructure security.
Comprehensive Database: Leverages a frequently updated vulnerability database, ensuring that the latest CVEs and security advisories are included in scans.
Rich Ecosystem: Offers seamless integration with CI/CD pipelines, enabling automated security checks during development and deployment stages.
Community and Support: Backed by Aqua Security and a vibrant open-source community, Trivy benefits from continuous updates, extensive documentation, and dedicated resources

Link: https://aquasecurity.github.io/trivy/

Infracost

Infracost empowers teams to adopt a shift-left approach for cloud cost management by providing cost estimates for Terraform resources before deployment. It also evaluates compliance with FinOps best practices, ensuring alignment with Well-Architected Frameworks from cloud vendors and your organization's tagging policies. This proactive approach saves money, fosters cost-conscious discussions early in the development workflow, and prevents cost surprises after deployment.

As cloud spending continues to be a significant concern for organizations, understanding the financial impact of infrastructure changes is more critical than ever. Infracost provides precise cost estimates for Terraform-managed resources, enabling informed decision-making before deploying changes. With support for AWS, Azure, and Google Cloud, it integrates seamlessly into your engineering processes, offering detailed cost breakdowns in development environments, terminals, VS Code, or pull requests.

Key Features

Cost Awareness: Displays detailed cost breakdowns directly within development environments such as Terminals, Visual Studio Code, GitHub Pull requests
CI/CD Integration: Extends functionality through Infracost Cloud, offering centralized cost dashboards,cost policies management, integrations with tools like Jira
Proactive Budget Management: Identifies cost impacts early in the development process, promoting effective budget control and informed decision-making.
Policy Enforcement: Supports Tagging policies and FinOps policies to ensure adherence to your organization’s best practices and standards.

Link: https://github.com/infracost/infracost

Tfmigrate

Tfmigrate is a powerful tool designed for Terraform state management, optimized to complement GitOps workflows. It simplifies state changes by enabling users to write state commands like move (mv), remove (rm), and import in HCL, making state migrations structured, version-controlled, and transparent.

With Tfmigrate, teams can maintain clean and well-organized Terraform states, making it easier to manage and scale infrastructure while ensuring safe and efficient state modifications.

Key Features

State Migration: facilitates seamless resource migration between Terraform states, ideal for mono-repo setups used in managing and refactoring complex infrastructures.
Dry Run Mode: allows users to simulate state operations using a temporary local state. This ensures safe migrations by previewing changes without impacting remote states.
GitOps-Friendly Workflow: supports writing Terraform state mv/rm/import commands directly in HCL. Users can plan and apply these changes as part of their version-controlled workflows.
Monorepo Style Support: enables resource movement across Terraform states, simplifying tasks like splitting or merging states during refactoring.
Dry Run Migration: simulates state migrations with a temporary local state and validates the changes by running terraform plan to ensure there are no unintended modifications before updating the remote state.
Migration History: tracks applied migrations and ensures all unapplied migrations are executed in sequence, providing an auditable and organized approach to state changes.

Link: https://github.com/minamijoyo/tfmigrate

Tfmv

tfmv is a powerful CLI tool specifically designed to simplify the process of renaming Terraform resources, data sources, and modules, while automatically generating the necessary moved blocks.

This ensures seamless state transitions and minimizes manual intervention, making tfmv an indispensable tool for teams looking to refactor and reorganize their Terraform configurations efficiently.

Key Features

Resource Renaming: Simplifies the process of renaming resources, data sources, and modules in Terraform configurations.
Automatic Moved Blocks: Generates moved blocks to ensure smooth state transitions during resource renaming.
Streamlined Refactoring: Makes it easier to refactor Terraform code, improving maintainability and reducing manual effort.

Link: https://github.com/suzuki-shunsuke/tfmv

TFLint

TFLint is a pluggable linter for Terraform, designed to help developers enforce coding standards and detect potential issues in their configurations. By ensuring that Terraform code is clean, optimized, and compliant with best practices, TFLint reduces errors and improves the quality of infrastructure as code before deployment.

Key Features

Error Detection: TFLint entifies potential issues, such as:
- Invalid instance types for major cloud providers like AWS, Azure, and Google Cloud.
- Misconfigurations that could lead to deployment failures.
Syntax Warnings: It aerts developers about:
- Deprecated Terraform syntax.
- Unused declarations, ensuring clean and efficient code.
Custom Rules: Supports plugins for defining custom rules, allowing teams to tailor linting checks to their specific coding standards and policies.
Best Practices Enforcement: Encourages adherence to best practices, including naming conventions and consistent configuration styles, improving maintainability and readability.
Cloud Provider Support: Delivers specialized linting for cloud providers such as AWS, Azure, and GCP, ensuring compatibility and optimal configurations.

Link: https://github.com/terraform-linters/tflint

Terratest‍

Terratest is a Go library developed by Gruntwork for testing Infrastructure as Code. With first-class support for tools like Terraform, Packer, Docker, Kubernetes, and major cloud providers such as AWS, GCP, and Azure, Terratest enables developers to write automated tests to validate their infrastructure.

By automating infrastructure testing, Terratest ensures that your Terraform configurations and other IaC implementations work as intended, giving you confidence in your deployments. Gruntwork provides an official guide for testing infrastructure code with Terratest in four simple steps, making it accessible and efficient for teams.

Key Features

Automated Testing: Seamlessly integrates into CI/CD pipelines to detect issues early in the development lifecycle, reducing risks and improving deployment stability.
Programmatic Test Definition: Leverages the Go programming language for writing expressive, code-based test cases that interact directly with Terraform-managed resources.
Comprehensive Testing Coverage: Supports a range of testing levels, from unit tests and integration tests to end-to-end scenarios, ensuring a thorough validation of your infrastructure.
Multi-Cloud Support: Compatible with major cloud providers like AWS, Azure, and Google Cloud, enabling testing across diverse cloud platforms.
Infrastructure Testing Automation: Automates testing for Terraform, streamlining the validation of cloud resources and configurations for greater consistency and efficiency.
Early Issue Detection: Identifies potential problems before deployment, enhancing the reliability of your infrastructure and promoting stable, secure environments.
Broad Tool Compatibility: Works with tools like Terraform, Docker, Kubernetes, Packer, and more, making it suitable for a wide range of IaC workflows.

Link: https://terratest.gruntwork.io

Atlantis

Atlantis is a pull request automation tool purpose-built for Terraform, designed to enhance collaboration and standardize workflows in infrastructure management.

Supporting multiple version control systems (GitHub, Bitbucket, GitLab, Azure DevOps) and workflows for both Terraform and Terragrunt, Atlantis empowers teams to streamline their infrastructure workflows. Running as a Golang binary or Docker image, Atlantis can be deployed on platforms like VMs, Kubernetes, and Fargate. This self-hosted solution ensures that infrastructure changes are well-documented, reviewed, and executed consistently.

Key Features

Integration with CI/CD Systems
- Automatically triggers Terraform commands (e.g., plan, apply) for pull requests.
- Allows reviewers to make informed decisions by providing detailed outputs within the pull request.
- Seamlessly integrates with CI/CD pipelines for automated testing and deployment of Terraform changes.
- Posts the output of Terraform commands directly in pull requests.
Environment management
- Provides a locking mechanism to prevent conflicting operations during provisioning.
- Ensures stability by stopping concurrent changes in shared environments.
- Manages separate workspaces for environments like staging and production.
- Ensures changes are tested in staging before being applied to production.
Scaling Infrastructure Management
- Simplifies the process of managing increasing infrastructure complexity.
- Streamlines workflows for large-scale projects and multi-environment setups.
Self-Hosted Solution
- Runs entirely within your infrastructure, ensuring full control and security.
- Protects sensitive credentials by executing Terraform operations in isolated environments.
Custom Workflows and Policies
- Supports custom workflows and policies for Terraform commands.
- Enforces organizational standards, such as requiring approvals before applying changes.

Link: https://www.runatlantis.io

Burrito

Burrito is a TACoS (Terraform Automation Collaboration Software) Kubernetes Operator, purpose-built to manage and automate Infrastructure as Code within Kubernetes environments. Often described as the "ArgoCD for Infrastructure as Code", Burrito brings powerful automation and collaboration features to Terraform workflows, aligning them with Kubernetes-native practices.

Burrito is a tool for teams seeking to enhance efficiency, collaboration, and alignment between Terraform and Kubernetes.

Key Features

Continuous Planning and Applying: Automates Terraform workflows with built-in PR/MR (Pull Request/Merge Request) integration, eliminating the need to manually configure CI/CD pipelines for Terraform. Burrito handles:
- State lock management
- Terraform versioning
- Saving Terraform plan logs and results
- Auditing tool integration (e.g., Checkov)
Kubernetes-Native: Operates as a Kubernetes Operator, seamlessly embedding Terraform automation into Kubernetes environments for a unified workflow.
State Drift Detection and Resolution: Continuously plans and applies Terraform code to ensure infrastructure remains in sync with its configuration. Detects and resolves state drift early, a critical feature for teams with multiple collaborators working on the same Terraform codebase.
Terraform State Navigation: Features a curated UI for visualizing and navigating Terraform state, including resources and dependencies. This provides a clear understanding of the impact of changes before they are applied.

Link: https://github.com/padok-team/burrito

Terraform-docs

terraform-docs is an essential utility for generating clear, comprehensive, and up-to-date documentation from OpenTofu/Terraform modules in a variety of output formats. It automatically extracts and formats information about inputs, outputs, providers, and resources, ensuring that infrastructure-as-code (IaC) projects remain well-documented and easy to maintain.

By leveraging terraform-docs, teams can maintain transparency, simplify collaboration, and improve the manageability of their IaC projects.

Key Features

Automatic Documentation: Automatically generates detailed and accurate documentation directly from Terraform modules, minimizing manual effort.
Flexible Output Formats: Supports a wide range of output formats to suit different documentation needs, including: Asciidoc, Markdown, JSON, Pretty, TFVars (HCL and JSON), TOML, XML, YAML
Streamlined Workflows: Simplifies the process of maintaining consistent and accessible Terraform documentation across teams and projects.
Extensible: Supports plugins, allowing users to build custom formatters to tailor documentation generation to specific requirements.
CI-Friendly: Integrates seamlessly with CI/CD pipelines, enabling automated documentation generation in pull requests via GitHub Actions or other CI tools.

Link: https://terraform-docs.io

Terramate

Terramate CLI is an open-source Infrastructure as Code orchestration and code generation tool designed for Terraform, OpenTofu, and Terragrunt. Terramate simplifies and automates IaC workflows, making them more efficient, scalable, and manageable.

With Terramate, you can:

Simplify complex codebases by breaking large state files into manageable stacks, reducing runtime and blast radius, while keeping configurations DRY with native code generation.
Automate and orchestrate Terraform, OpenTofu, and Terragrunt workflows in any CI/CD system using Pull Request automation, GitOps blueprints, and workflow tooling with zero-configuration orchestration and change detection.

Key Features

Orchestration
- Run any command or workflow in stacks with unlimited concurrency.
- Configurable workflows tailored to specific IaC needs.
Change Detection
- Automatically execute only the stacks with changes.
- Detect changes in referenced Terraform/OpenTofu modules or Terragrunt dependencies for efficient updates.
Code Generation
- Generate HCL, JSON, and YAML code to maintain DRY principles.
- Supports global variables and functions to streamline stack management.
Automation Blueprints
- Pre-configured GitOps workflows for GitHub, GitLab, Bitbucket, and Atlantis.
- Enables Pull Request automation with plan previews, seamlessly integrating into your CI/CD pipelines.
Drift Management
- Detect and reconcile drift using scheduled workflows, ensuring infrastructure remains consistent with IaC definitions.
Observability and Insights
- Gain actionable insights and observability into stacks, deployments, and resources.
- Provides enhanced visibility for informed decision-making.

Link: https://github.com/terramate-io/terramate

Terratag

Terratag is a CLI tool that simplifies the process of applying tags or labels across an entire set of OpenTofu/Terraform files. The tools is developed by env0, and designed to ensure consistent tagging for resources in AWS, GCP, and Azure environments, Terratag helps teams improve resource visibility, enforce tagging standards, and streamline cloud resource management.

Terratag is a must-have tool for teams looking to improve resource visibility and enforce tagging standards efficiently across their Terraform-managed infrastructure.

Key Features

Cross-Platform Tagging: supports tagging and labeling for resources across AWS, GCP, and Azure.
Automation-Friendly: easily integrates into existing workflows and CI/CD pipelines, enabling automated tagging processes and reducing manual effort.
Enhanced Resource Organization: Promotes better organization and management of cloud resources through consistent and standardized tagging practices, improving visibility and traceability.

Link: https://github.com/env0/terratag

Conclusion

That’s a quick overview of some of the most popular Terraform tools to help you manage your infrastructure management tasks effectively. As mentioned earlier, all the tools discussed in the article are also compatible with OpenTofu, which is especially useful for users affected by license-related concerns.

For staying up to date on new Terraform/OpenTofu tools, I recommend keeping watch of curated lists like as

I hope these tools will help you improve collaboration, enhance security, simplify processes, and make your Terraform/OpenTofu journey smoother and more efficient. Good luck!

Как настроить зеркало реестров для OpenTofu и Terraform

kvendingoldo — Thu, 26 Sep 2024 22:56:45 +0000

В конце августа проект OpenTofu сначала заблокировал доступ к своему реестру https://registry.opentofu.org для пользователей из России, а затем без ясного объяснения причин удалил несколько российских провайдеров (PR#817, PR#839). Это привело к тому, что даже зеркалирование официального реестра стало бессмысленным и сломало выполнение команды tofu init для всех, кто только что смигрировал с Terraform на OpenTofu.

Примечательно, что HashiCorp, который заблокировал доступ к реестру Terraform для российских пользователей еще в 2022 году, не пошел на столь радикальные меры и не удалял российских провайдеров из самого реестра.

В статье мы рассмотрим варианты обхода блокировки реестра провайдеров как для пользователей Terraform, так и для OpenTofu.

Обход блокировки registry.terraform.io

В случае Terraform, обход блокировки осуществляется через конфигурацию стандартного зеркала для реестра провайдеров. Для этого нужно создать файл .terraformrc в домашнем каталоге вашей операционной системы.

В самом файле нужно сконфигурировать зеркало следующим образом:

provider_installation {
  network_mirror {
    url     = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

После этого terraform init снова будет выполняться без проблем.

Обход блокировки registry.opentofu.org

Ситуация с OpenTofu является более сложным, чем с Terraform. Как уже упоминалось ранее, OpenTofu физически удалил метаинформацию о провайдерах из своего реестра. Это означает, что даже настроенное зеркало не сможет помочь при использовании свежих версий плагинов, которые не существовали на момент блокировки.

По умолчанию OpenTofu использует реестр registry.opentofu.org, если он не указан явно. К счастью, плагины для OpenTofu и Terraform в настоящее время взаимосовместимы, что дает возможность использовать реестр registry.terraform.io с заранее настроенным зеркалом. Для этого достаточно создать в домашнем каталоге вашей файловой системы файл .tofurc со следующим содержанием:

provider_installation {
  network_mirror {
    url     = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

После, измените блок terraform внутри вашего HCL кода. Для каждого описанного провайдера в параметр source необходимо добавить префикс registry.terraform.io/ . Пример блока для конфигурации OpenTofu:

terraform {
  required_version = "1.8.0"
  required_providers {
    yandex = {
      source  = "registry.terraform.io/yandex-cloud/yandex"
      version = "0.129.0"
    }
    tls = {
      source  = "registry.terraform.io/hashicorp/tls"
      version = "4.0.4"
    }
    random = {
      source  = "registry.terraform.io/hashicorp/random"
      version = "3.4.3"
    }
    null = {
      source  = "registry.terraform.io/hashicorp/null"
      version = "3.2.2"
    }
    aws = {
      source  = "registry.terraform.io/hashicorp/aws"
      version = "5.45.0"
    }
  }
}

Это изменение принудительно заставит OpenTofu использовать реестр Terraform через заранее настроенное зеркало.

Список доступных зеркал

Как вы, возможно, заметили, в примерах я использовал зеркало terraform-mirror.yandexcloud.net от компании Яндекс. Это зеркало не отличается высокой стабильностью и частотой обновлений, поэтому, помимо него, можно воспользоваться следующими альтернативами:

https://registry.comcloud.xyz/ (также доступен как https://registry.nationalcdn.ru/)
https://tf.org.ru/ (nm.tf.org.ru)
https://terraform-mirror.mcs.mail.ru/
https://terraform.cloud.ru/ (документация)

Tenv v2.0: The Importance of Explicit Behavior for Version Manager

kvendingoldo — Tue, 02 Jul 2024 10:46:07 +0000

The explicit behavior of IAC version managers is quite crucial. It is especially critical in the realm of Terraform and OpenTofu because tool upgrades might destroy or corrupt all managed infrastructure. To protect users from unexpected updates, all version managers have to work clearly and without any internal wizardry that cannot be explained without a deep dive into the sources.

Tenv is a versatile version manager for OpenTofu, Terraform, Terragrunt, and Atmos, written in Go and developed by tofuutils team. This tool simplifies the complexity of handling different versions of these powerful tools, ensuring developers and DevOps professionals can focus on what matters most — building and deploying efficiently. Tenv is a successor of tofuenv and tfenv.

In the process of tenv development, our team discovered quite an unpleasant surprise with Terragrunt and tenv, which may have created serious issues. On a fresh install of the Linux system, when one of our users attempted to run Terragrunt, the execution ended up utilizing OpenTofu instead of Terraform, with no warnings in advance. In the production environment, it might cause serious Terraform state corruption, but luckily it was a testing environment. Before we look at the root cause of this issue, I need to explain how the tenv works.

Tenv manages all tools by wrapping them in an additional binary that serves as a proxy for the original tool. It means you can't install Terraform or OpenTofu on an ordinary Linux machine alongside tenv (except NixOS case). At our tool, we supply a binary with the same name as the tool (Terraform / OpenTofu / Terragrunt / Atmos), within which we implement the proxy pattern. It was required since it simplifies version management and allows us to add new capabilities to automatic version discovery and installation handling.

So, knowing that tenv is based on a downstream proxy architecture, we are ready to return to the problem. Why was our user's execution performed using OpenTofu rather than Terraform? The answer has two parts:

Terragrunt started to use OpenTofu as the default IAC tool, however, this was not a major release; instead, it was provided as a patch and users didn't expect to have any differences in the behavior. The original problem may be found here.
When Terragrunt called OpenTofu in the new default behavior, it used tenv's proxy to check the required version of OpenTofu and install it automatically.

Although the TERRAGRUNT_TFPATH setting might control the behavior, users were unaware of the Terragrunt breaking change and were surprised to see OpenTotu at the end of execution. But why did OpenTofu execute if users did not have it in their system? Here we are dealing with the second issue that has arisen. At the start of tenv development, we replicated many features from the tfenv tool. One of these features was automatic tool installation, which is controlled by the TFENV_AUTO_INSTALL environment variable and is enabled by default. Tenv also has the TENV_AUTO_INSTALL variable, which is also was true by default unless the mentioned case hasn't been discovered.

Users who used Terraform / OpenTofu without Terragrunt via tenv may have encountered the auto-install when, for example, switching the version of the tool with the following command:

tenv tf use 1.5.3
tenv tofu use 1.6.1

The use command installed the required version even if it wasn’t present in the operation system locally.

After a brief GitHub discussion, our team decided to disable auto-install by default and release this minor change as a new, major version of tenv. We made no major changes to the program, did not update the framework of the language version, and only updated the default variable, deciding that users should understand that one of the most often utilised and crucial behaviors had changed.

It's interesting that during the discussion, we disagreed on whether users should read the README.md or documentation, but whether you like it or not, it's true that people don't read the docs unless they're in difficulty. As the tofuutils team, we cannot accept the possibility that a user will mistakenly utilize OpenTofu in a real-world production environment and break the state or the cloud environment.

Finally, I'd like to highlight a few points once more:

Implement intuitive behavior in your tool.
Consider user experience and keep in mind that many people don't read manuals.
Do not worry about releasing a major version if you made the breaking change.
In programming, explicit is preferable to implicit, especially when dealing with state-sensitive tools.

How to Manage Terraform Versions

kvendingoldo — Mon, 17 Jun 2024 20:32:07 +0000

The simplest method for handling Terraform versions is to tenv. tenv is a version manager for Terraform, OpenTofu, Terragrunt, and Atmos, written in Go. This versatile version manager simplifies the complexity of version control, helping to avoid spending time on IaC tools’ version management and ensuring developers and DevOps can focus on what is important the most - crafting innovative products and driving business value.

Why do I need Terraform version manager?

Managing a single Terraform project makes installing, upgrading, or switching to tools like OpenTofu straightforward. However, handling multiple projects with different Terraform versions can be challenging. Regular upgrades and tool switches require careful coordination to maintain functionality and stability across projects. The list of key challenges:

Version Compatibility: Different projects may need specific Terraform versions, which might not be backward compatible.
Dependency Management: Dependencies for each project must match the Terraform version of that project.
Environment Consistency: It becomes challenging to maintain consistency throughout the development, staging, and production environments.
Tooling and Integration: Various Terraform versions may require modifications to CI/CD pipelines and integrations.

tenv terraform version manager cover all described challenged under the hood in a single binary that helps to manage Terraform versions transparently.

🚀 tenv installation

MacOS

brew install tenv

Windows

choco install tenv

Linux

For Linux, you can install tenv version manager via packaged binaries (.deb, .rpm, .apk, pkg.tar.zst , .zip or .tar.gz format) by visiting the release page or by apk/yay/snap/nix package managers. To get more information about the Linux tenv installation, check README.md.

Manage Terraform versions via tenv version manager

Once you have tenv version manager installed, you can use it to install specific versions of Terraform. To install Terraform, do the following steps:

Open a terminal, go to the directory with Terraform code (if you have any) and execute the following command to install terraform version:

tenv tf install

Based on .tf code, tenv version manager automatically detect and install the necessary version of Terraform. If no version detected in sources, the latest version will be installed.

On the other hand, if necessary, a specific Terraform version can also be installed. Let's try to install Terraform 1.8.5:

tenv tf install 1.8.5

The install command also supports version constraints such as:

latest - the latest available stable version
latest-pre - the latest available version, including unstable ones
latest-allowed or min-required - tenv will scan your Terraform files to detect which version is maximally allowed or minimally required.

Now, verify the Terraform version. To do it, use the following command:

terraform version

That's it. No symlinks, additional commands or download required. To read about more installation cases for Terraform, you can check the official README.md file.

Support Us, Contact Us

If you like this post, support us, download tenv, try to use it and give us feedback in our official discussions channel!

Press a star 🌟 on GitHub if you like the tenv version manager.

Forem: kvendingoldo

How to create AWS Serverless Valkey via OpenTofu

Introduction

Open Source stack focus

Prerequisites

Install OpenTofu to your machine

Create AWS Elasticache OpenTofu module

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Create dependent AWS infrastructure

Apply the OpenTofu code

Connect to the cluster

Step 1: Get an endpoint

Step 2: Connect by redis-cli

Cleaning up resources

Conclusion

Fix InvalidParameterValueException for AWS Lambda docker images built by GitHub Actions

TL;DR

Root Cause: OCI vs Docker Image Format

Why Lambda Doesn’t Support OCI

Solution

What are provenance and sbom options?

Service Compatibility Overview

Final Thoughts

Top Terraform/OpenTofu tools to Use in 2025

Overview

tenv

Key Features

Aiac

Key Features

Atmos

Key Features

Terragrunt

Key Features

Checkov

Key Features

Trivy

Key Features

Infracost

Key Features

Tfmigrate

Key Features

Tfmv

Key Features

TFLint

Key Features

Terratest‍

Key Features

Atlantis

Key Features

Burrito

Key Features

Terraform-docs

Key Features

Terramate

Key Features

Terratag

Key Features

Conclusion

Как настроить зеркало реестров для OpenTofu и Terraform

Обход блокировки registry.terraform.io

Обход блокировки registry.opentofu.org

Список доступных зеркал

Tenv v2.0: The Importance of Explicit Behavior for Version Manager

How to Manage Terraform Versions

Why do I need Terraform version manager?

🚀 tenv installation

MacOS

Windows

Linux

Manage Terraform versions via tenv version manager

Support Us, Contact Us

What are `provenance` and `sbom` options?