Mike's Notes
Thoughts on Terraform and OpenTofu in the wake of the
HCP Terraform Free Tier being discontinued by IBM.
Alex asked Gemini about OpenTofu. The output was not verified and is appended below. (I used Google Translate to English)
Resources
References
Repository
-
Home > Ajabbi Research > Library >
-
Home > Handbook >
Last Updated
27/01/2026
Potential uses of OpenTofu
By: Mike Peters
On a Sandy Beach: 27/01/2026
Mike is the inventor and architect of Pipi and the founder of
Ajabbi.
Background
The original plan was for Pipi to use Terraform as
Infrastructure-as-Code (IaC) to deploy cloud infrastructure across
AWS, Azure, GCP, IBM, Oracle, and more. Then IBM announced that the
Terraform Free Tier is being discontinued. There is now an
open-source fork called OpenTofu, which is part of the
Cloud Native Computing Foundation (CNCF). OpenTofu has strong
community support. Pipi will now use OpenTofu.
Pipi as a code generator
A Pipi Agent could easily generate the highly structured
Terraform/OpenTofu code.
Potential Uses
-
The Pipi messaging system could use OpenTofu syntax as the
message format for internal messaging between Pipi Agents. The
needs are relatively simple compared to what is available. But more
capacity is available if needed.
Message examples
-
Tell the Namespace Engine (nsp) to shut down.
-
Tell the Factory Engine (fac) to make more
Workflow Engines (wfl) and where to deploy them.
-
Tell the Ontology Engine (ont) to import the latest version of
SNOMED.
-
The updated SNOMED Ontology availability would then trigger
many other engines to run updates to Workspace for Health
and User Documentation.
-
Tell the Workspace Engine (wsp) to build a
Hebrew-language/script generic model of the
Workspace for Screen.
-
Tell the Google Cloud Engine (GCE) to
deploy a Vietnamese-language/script customised Health System Workspace for a Hospital in Vietnam to GCP.
-
Tell the Physical Law Engine (pyw) to update with the latest
definitions from the Particle Data Group.
-
Dedicated Pipi Agents would use OpenTofu to deploy cloud
infrastructure to each cloud platform.
-
Apple Engine (ale)
-
AWS Engine (aws)
-
AZURE Engine (azu)
-
Digital Ocean Engine (dgo)
-
Google Cloud Engine (ggc)
-
IBM Engine (ibm)
-
Meta Engine (met)
-
Oracle Engine (ora)
-
(More will be added later; all are welcome)
OpenTofu Example
This code sample is from the OpenTofu Docs.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 1.0.4"
}
}
}
variable "aws_region" {}
variable "base_cidr_block" {
description = "A /16 CIDR range definition, such as 10.1.0.0/16,
that the VPC will use"
default = "10.1.0.0/16"
}
variable "availability_zones" {
description = "A list of availability zones in which to create
subnets"
type = list(string)
}
provider "aws" {
region = var.aws_region
}
resource "aws_vpc" "main" {
# Referencing the base_cidr_block variable allows the network
address
# to be changed without modifying the configuration.
cidr_block = var.base_cidr_block
}
resource "aws_subnet" "az" {
# Create one subnet for each given availability zone.
count = length(var.availability_zones)
# For each subnet, use one of the specified availability zones.
availability_zone = var.availability_zones[count.index]
# By referencing the aws_vpc.main object, OpenTofu knows that the
subnet
# must be created only after the VPC is created.
vpc_id = aws_vpc.main.id
# Built-in functions and operators can be used for simple
transformations of
# values, such as computing a subnet address. Here we create a
/20 prefix for
# each subnet, using consecutive addresses for each availability
zone,
# such as 10.1.16.0/20 .
cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 4,
count.index+1)
}
Yes, Mike! It's cool!
I talked a little bit with Gemini [1]. OpenTofu is a great tool
Alex
[1] https://gemini.google.com/share/4c550e83a230
OpenTofu: Features and Benefits
Some responses below were generated according to the creator's saved info
and preferences. Learn moreOpens in a new window 27 January 2026 at
21:22
Published on 27 January 2026 at 21:37
Prompt
What features does OpenTofu provide?
Output
OpenTofu is an open-source fork of Terraform (created after HashiCorp's
license was changed to BSL), developed under the auspices of the Linux
Foundation. In 2026, it became a full-fledged competitor to Terraform,
offering a number of unique features while maintaining backward
compatibility.
Here are the main features that OpenTofu provides:
1. Full compatibility with the Terraform ecosystem
OpenTofu is designed as a drop-in replacement. This means:
-
HCL support: The same configuration file syntax is used.
-
Working with providers and modules: OpenTofu uses its own registry
( OpenTofu Registry ), which mirrors most popular providers (AWS,
Azure, GCP, etc.) and modules.
-
Migration: You can migrate from Terraform (versions up to and
including 1.6 and many later) with virtually one command without rewriting
any code.
2. Advanced Security (State Encryption)
One of the main "killer features" introduced in OpenTofu (starting with
version 1.7) is native encryption of state files .
-
Unlike standard Terraform, where sensitive data
terraform.tfstate is often stored in
cleartext, OpenTofu allows you to encrypt it at rest.
-
Various key management methods are supported: AWS KMS, GCP KMS, HashiCorp
Vault (OpenBao), as well as environment variables and files.
3. Improvements in code management
OpenTofu is actively implementing features that the community has been
requesting for years:
-
Dynamic Provider Functions: Ability to use functions defined
directly in providers within your HCL code.
-
Improved loops in import blocks: Can now be used
for_each inside
count blocks
import, making it much easier to bulk
import existing resources into your code.
-
Early Variable Evaluation: Allows you to use variables in parts of
the configuration where they were previously unavailable (for example, in
backend settings).
4. Openness and community
-
MPL v2.0 License: Ensures that the tool will always remain free
and open for use for any commercial purposes without legal risks.
-
Community-driven Roadmap: The development plan is formed based on
RFCs (Request for Comments) from the community, and not on the commercial
interests of a single corporation.
Comparison of key aspects
| Characteristic |
OpenTofu |
Terraform |
| License |
Open Source (MPL 2.0) |
Business Source License (BSL) |
| State encryption |
Native (client) |
Depends on the backend (SaaS/Enterprise) |
| Management |
Linux Foundation |
HashiCorp |
| Registry |
opentofu.org |
registry.terraform.io |
Is it worth switching?
If your organization values open source and vendor lock-in, or
client-side encryption of state files is critical to you, OpenTofu is an
excellent choice.
Would you like me to help you create a migration plan or a sample
configuration for encrypting the state file?
Prompt
What is it intended for? Let's say I'm creating a multi-agent
system.
OpenTofu is designed for managing infrastructure as code (IaC).
Simply put, instead of manually clicking through the cloud provider's
console (creating servers, databases, and networks), you describe the
desired architecture in text files, and OpenTofu automatically "builds" and
connects these components.
If you're building a multi-agent system (MAS), OpenTofu will be
responsible for the "foundation" on which those agents will live and
communicate.
The Role of OpenTofu in Creating a Multi-Agent System
When agents become numerous, they require computing resources and a
communication environment. Here's how OpenTofu helps in this scenario:
1. Deployment of computing nodes
You can describe a cluster (e.g. Kubernetes or a group of virtual machines)
where your agents will run.
-
Example: You need 10 isolated containers for different agent types
(scheduler agent, executor agent, etc.). OpenTofu will create them with a
single command.
2. Setting up the communication environment (Message Brokers)
Agents must exchange messages.
-
OpenTofu will automatically deploy and configure RabbitMQ ,
Kafka , or Redis Pub/Sub to serve as the "bus" for your
agents to communicate.
3. Database Management (Vector and Regular)
Agents often need memory (Long-term memory).
-
You can use code to set up a vector database (such as Pinecone ,
Weaviate , or Milvus ) and a regular one (PostgreSQL) to
store conversation history and logs.
4. Scaling
If your system needs 500 agents instead of 5 tomorrow, you don't need to
manually configure each server. Simply change one number in the
configuration: count = 500, and
OpenTofu will build the missing infrastructure.
Example of a logical diagram of work:
-
Code (HCL): You describe: "I need a 3-node cluster and a
database."
-
OpenTofu (Execution): Compares your code with what's already in
the cloud.
-
Infrastructure: Creates servers -> Installs the runtime
environment (Docker/K8s) on them -> Sets up the network between
them.
-
Agents: Now your Python scripts (agents) can run in this
ready-to-use and stable environment.
Why choose OpenTofu over just scripts?
-
Idempotency: If you run the server creation script twice, it can
create two servers. OpenTofu will recognize that one already exists and
won't do anything extra.
-
Dependency Management: It knows that it needs to create a network
first, and only then a server on that network.
-
Collaboration: The state file ( state) allows an entire team of
engineers to work on the same infrastructure without chaos.
Can you suggest which cloud resources or providers would be best suited
to host your multi-agent system?
Prompt
I'm interested in how to organize the exchange of messages between agents
that exchange commands and data.
To organize communication between agents for exchanging commands and data,
you typically use one of three architectural models. The choice depends on
how autonomous your agents are and how critical delivery speed is.
Below is a breakdown of the main approaches you can implement and automate
using OpenTofu.
1. Message Bus (Pub/Sub) — The Most Flexible Approach
This is a classic model where agents do not communicate directly. Instead,
they send messages to "topics" or "exchanges."
-
How it works: Agent A sends a command to the topic
commands. Agent B is subscribed to
this topic, receives the command, executes it, and sends the result to the
data topic.
-
Tools: RabbitMQ, Apache Kafka, NATS, or
Redis.
-
Advantage: Agents are fully decoupled. If one agent goes offline,
messages accumulate in the queue and are processed once it restarts.
2. Centralized Orchestrator (Shared Space)
In this model, there is a central "knowledge base" or dispatcher that
distributes tasks and maintains state.
-
How it works: Agents write data to a shared database (e.g., a
vector database or Redis) and check the status of tasks in a central
table.
-
Tools: Redis (using Streams or Lists), PostgreSQL with
queues (Listen/Notify).
-
Advantage: It is easy to track the state of the entire system and
the history of all commands in one place.
3. Direct Interaction (gRPC / HTTP)
Agents contact each other directly via their network addresses.
-
How it works: Each agent has its own API endpoint.
-
Tools: gRPC (high speed, strict data typing) or
FastAPI/Flask (simplicity).
-
Advantage: Minimal latency because there are no intermediate
layers.
-
Disadvantage: Harder to scale. If an agent's IP address changes,
others must be notified (requires Service Discovery).
Technical Implementation: The Role of OpenTofu
Once you decide on the architecture, you need to "spin up" the
infrastructure for this communication. OpenTofu automates this
process:
-
Broker Deployment: OpenTofu code deploys a RabbitMQ or
NATS cluster.
-
Queue Configuration: It immediately creates the necessary queues
(e.g., task_queue,
results_queue).
-
Security: It generates unique credentials for each agent type,
ensuring an "executor" agent cannot accidentally delete messages from the
"planner" queue.
-
Service Discovery: If using gRPC, OpenTofu can configure
Consul or internal DNS in Kubernetes so agents find each other by
name (e.g., agent-alpha.local) rather
than static IPs.
Where to start?
If you are just starting to design your system, I recommend the
Redis + Python
(using libraries like Celery or TaskIQ) or
NATS combination. This provides a great balance between simplicity
and performance.
Would you like me to provide a sample OpenTofu configuration to deploy a
message broker (like Redis or RabbitMQ) in Docker or a cloud
provider?
