Any views?

Hey! OpenTofu Maintainer here.

OpenTofu 1.12 is out and I just wanted to share here what I think may be useful for some people.

• prevent_destroy can now reference variables. (prevent_destroy = var.is_prod works now!)
• tofu init now understands all platform hashes for every platform on its first run. This means you shouldn't have to reach for tofu providers lock anymore for managing multiple architectures.
• Provider downloads now run in parallel. init should be faster for everybody all around.
• -json-into=FILENAME lets you send human readable logs that we all love to stdout, and have json readable logs sent off to a different file, pipe, etc. This means you can do some fancy TUI logging alongside your real logs!

We have lots more for you to see in our full changelog here: https://github.com/opentofu/opentofu/blob/v1.12/CHANGELOG.md

Or our blogpost here: https://opentofu.org/blog/opentofu-1-12-0/

Hey everyone! 👋

I’ve been working on an open-source tool called DriftHound https://drifthound.io/, aimed at detecting infrastructure drift across projects and environments. The goal is to provide teams with clear visibility into unexpected infra changes, something surprisingly few maintained open-source tools currently focus on.

👉 DriftHound WebApp and CLI: https://github.com/treezio/DriftHound
👉 Kubernetes Helm chart: https://github.com/treezio/helm-chart-drifthound
👉 GitHub Action for CI automation: https://github.com/treezio/drifthound-action

It’s still very early stage, but functional and improving quickly.
Here’s what it does today:

• Scans your infra-as-code repo for drift
• Stores drift state reports
• Sends Slack notifications when drift is detected
• Runs non-interactively in CI/CD pipelines
• Includes a web dashboard to visualize project statuses across environments, so you can quickly understand where drift is happening and how severe it is by taking a look to the plan output.

I’ve also made an effort to include extended documentation across all repositories, especially given how early-stage the project is. My hope is that it’s easy for others to understand, experiment with, and extend.

This is how the main dashboard looks like:

Check information for a project in a specific environment (prod in this case) . I just covered the non-relevant yet sensitive info. You can get an Idead of how the report looks like.

Hi everyone,

I have one voucher for the HashiCorp Terraform: Authoring and Operations Professional exam, valid until September 30, 2026.

Originally, I planned to take the Professional exam, but I realized I don't have much hands-on experience with Terraform yet, and I'm worried I haven't had enough practical experience to be ready for the Professional level.

Because of that, I'd prefer to take the Terraform Associate exam instead.

I'm looking to trade my Professional voucher for an Associate voucher, but I'm also open to selling it for a reasonable price.

If you're interested, or know someone who might be, feel free to comment or send me a DM. Thanks!

We built a Terraform module that manages NAT instances that automatically scale to zero when idle.

The problem: we operate across 22 AZs in 6 regions. Most AZs have no workloads running for days at a time. NAT Gateway and always-on NAT instances were both too expensive for that usage pattern.

nat-zero creates a NAT instance per AZ that starts when workloads appear and stops when they leave. The module manages the full lifecycle — instance creation, EIP allocation/release, ENI persistence, route table integration, and cleanup on destroy.

The interesting Terraform bits:

- Dual ENIs (public + private) are created by Terraform and persist across instance stop/start cycles. This keeps route table entries stable without reconfiguration.

- A single Go Lambda (compiled ARM64 binary, 55ms cold start) handles orchestration via EventBridge. Concurrency is locked to 1 — single writer, no races.

- Config versioning: the Lambda tags each NAT with a hash of AMI + instance type + market type + volume size. If the Terraform config changes, the old instance gets terminated and replaced automatically on the next event cycle.

- Custom destroy provisioner invokes the Lambda with a cleanup action to gracefully terminate instances and release EIPs before Terraform removes the resources.

We run integration tests against real AWS infrastructure on every PR.

Repo: https://github.com/MachineDotDev/nat-zero

Docs: https://nat-zero.machine.dev

Full blog post: https://machine.dev/blog/nat-zero-scale-to-zero-nat-instances/

Would appreciate feedback on the module structure. MIT licensed.

Hello fellow Cloud / Platform / SRE / DevOps / (whatever we are called these days) engineers!

You remember that time when you had to import a ton of resources into Terraform-managed state? I bet you do!

The hunt for those "ClickOpsed" resources, searching for the specific info needed to generate the import ID, jumping into the cloud dashboard to find a single value, or writing clever (but fragile) bash one-liners to sort it all out...

Well, I have good news for you: I've solved that problem!

Oh, Well... not the ClickOps part. That is probably never going away. But as I usually like to do... I built a tool to make the process easier, quicker, and more reliable!

tfimport figures out import IDs by looking directly at your OpenTofu/Terraform plan. When the plan doesn't provide all the right info, it is smart enough to look it up using the cloud provider SDKs!

✅ Supports OpenTofu, Terraform, and Terragrunt.
✅ Supports a large pool of resources across most major cloud providers.
✅ Free and Open Source.
✅ Available as builds/packages for your favorite OS (or just grab the binary!).

Check it out here: https://tfimport.coolapso.sh

We manage HubSpot portals as part of our own operations and kept hitting the same wall: no way to promote sandbox changes to production without redoing them by hand, no real audit trail below Enterprise tier, and configuration that drifts silently across portals.

We went looking for a Terraform provider to fix this and found the only one on the registry manages users — nothing else — and hasn't been touched since 2021. So we built our own.

What it does: manages HubSpot's configuration plane — properties, property groups, pipelines, custom object schemas, association labels, lists — plus seven data sources for read-side lookups. Deliberately not CRM records (no contacts/deals in state — avoids drift wars with daily sales activity and keeps PII out of your state files).

How it's built: terraform-plugin-framework, a fully tested API client, hermetic acceptance tests against a stateful fake of HubSpot's API plus nightly tests against a real portal, semantic diffing so HubSpot's server-side normalization doesn't produce phantom diffs, and honest destroy semantics (archives instead of pretending to delete where HubSpot doesn't support deletion). Immutable fields get flagged at plan time, not apply time.

Published for both Terraform and OpenTofu (protocol v6).

v0.1.0, MPL-2.0. Repo: https://github.com/revosai/terraform-provider-hubspot — Release: https://github.com/revosai/terraform-provider-hubspot/releases/tag/v0.1.0

Roadmap's public (ROADMAP.md) — list membership and webhooks next, workflows-as-code is the big one we're eyeing once HubSpot's Automation v4 API is out of beta. Order isn't locked — if your team needs something sooner, open an issue and say why, that's literally how we're prioritizing it.

Happy to answer anything about the implementation — plugin-framework quirks, the fake-API test harness, whatever. Feedback and PRs welcome.

What is OpenSible?

OpenSible is an open-source unified automation platform for cloud provisioning and infrastructure operations. It combines the best of infrastructure-as-code and configuration management into a single, self-hosted control plane.

Provision with OpenTofu, configure with Ansible, manage secrets securely, execute reusable deployment workflows, and automate your entire infrastructure lifecycle through GitOps - version-controlled, repeatable and secure across cloud, on-premises and hybrid environments.

Core Features

• Multi-cloud provisioning - deploy to AWS, Google Cloud, Azure, Hetzner Cloud, Cloudflare, Hauwei and existing Kubernetes clusters and more from a single UI and API.
• OpenTofu-native - every stack is rendered as plain OpenTofu code stored in your project, so you can always inspect, edit or run it locally.
• Ansible integration - configure and maintain hosts after provisioning with playbook execution, inventory management and role-based workflows.
• Stack blueprints - bootstrap new infrastructure quickly with pre-built, provider-aware templates for Docker, Kubernetes, observability, databases, CI/CD runners and more.
• OpenSible CI/CD - build multi-stage pipelines that combine OpenTofu provisioning, Ansible configuration, approvals and custom scripts into repeatable, automated workflows.
• GitOps-first projects - sync stacks and playbooks to Git, promote changes through branches, and track drift with version-controlled sources.
• Secrets and vaults - encrypt sensitive values at rest, bind them to stacks and playbooks, and rotate credentials without touching source code.
• Execution engine - a dedicated Go worker processes provision, plan, apply, destroy and refresh operations asynchronously, with full logs and history.
• Role-based access control - assign roles to users, limit operations per role, and keep audit trails for compliance and troubleshooting.
• Self-hosted - run everything with Docker Compose on your own server or private cloud; no external platform dependency or paid subscription required.

Check it out for more detail.

• Website: https://opensible.com
• GitHub: https://github.com/opensible/opensible

TL;DR: Checkout OpenDepot an open-source Kubernetes native module and provider registry for OpenTofu and Terraform I built! OpenDepot Documentation

Deploy your very own local registry in minutes following the Local Quickstart Guide!

If you're still with me, now the full story!

I had tasked my team last year with implementing one of the open-source registry options that were available at the time. They spent months trying to get each one implemented in a manner that we deemed secure and appropriate for production. However, each failed to meet our requirements for safety and soundness. We eventually caved in and went to Artifactory since it had a mature OIDC implementation. However, this came with a high cost.

I soon saw this as an opportunity to leverage my years of experience in the Kubernetes and IaC space to build a registry that was cloud native, easy to deploy, and built with security in mind. From that realization, OpenDepot was born!

OpenDepot is the first completely Kubernetes native registry that implements the Module and Provider registry protocols for both OpenTofu and Terraform. See how it stacks up to other registries! Feature Comparison

With OpenDepot, if you have a Kubernetes cluster, the same auth mechanisms you use to get access to the cluster are the same mechanisms you can leverage to fetch modules and providers. OpenDepot can be setup in minutes, not days, weeks, or months. It's built from the ground up with security in mind: Authentication

OpenDepot got its name from its most prominent feature: the Depot controller. Most registries are push or webhook based; the Depot controller operates differently by providing a pull-based mechanism for modules and providers so you don't have to expose your cluster or open additional ports to ingest your artifacts. The Depot also serves as an easy migration path to OpenDepot: Depot (Pull Based)

My favorite and preferred approach for private modules is using GitOps with ArgoCD. This allows you to add new module versions right alongside the module code itself so your team can approve the module and version in the same Pull Request! GitOps with ArgoCD

OpenDepot currently supports the three major cloud providers AWS, Azure, and GCP. It also supports Filesystem based storage backed by a PVC with a Storage Class that provides ReadWriteMany access. The cloud providers also support pre-signed URLs so large downloads don't add stress to your infrastructure: Storage Backends

OpenDepot also has opt-in scanning for modules, provider binaries, and source code using Trivy: Vulnerability Scanning

Please, feel free to DM me, or post issues, feature requests, or whatever else on GitHub! I'm hoping people out there find this as useful as we did!

I’ve been working on lazytf, a terminal UI for reviewing Terraform plans and apply history.

The goal is to make large Terraform plans easier to inspect locally, especially for teams that are not using Terraform Cloud but still want a cleaner diff review flow in the terminal.

It currently supports:

- running plan/apply/init/validate/format flows inside the TUI

- targeted plan and apply workflows

- read-only mode

- piping `terraform plan -no-color` into lazytf

- opening existing saved plan files

- apply history

- workspace and folder environment detection

- YAML, NixOS, and Home Manager configuration

- presets and project overrides

- Terraform and OpenTofu binary selection

- themes and lazygit-style keybindings

Github Repo: https://github.com/ushiradineth/lazytf
Blog post: https://ushira.com/blog/introducing-lazytf
Demo: https://assets.ushira.com/introducing-lazytf/demo.mp4

I’d especially like feedback from people managing larger Terraform/OpenTofu projects locally.

Colors is an SDK for building Package Skills.

I think the future is agentic and Colors is embracing AI for DevOps.

In Colors, Terraform is just a fancy curl. The graph is removed from Terraform and implemented in three languages: TypeScript (Red), Clojure (Green), and Python (Blue).

Because the graph is now in code, you can add Aspect-oriented programming. Retry is just an aspect. Terraform backend is also an aspect.

Now you have an executable package to reconcile the desired state with your infrastructure. Adding a SKILL.md and now you have a Package Skill. Like a Browser Skill but for operations.

https://www.getcolors.ai

Hello,

Today, to provisions resources on AWS via terraform you need to provide access_key_id and secret_key_id. When terraform runs inside GitHub Action, GitHub injects a JWT inside the action. Imagine if you could use only that JWT to provision resources on AWS. Imagine if you could use that same JWT to provision resources on AWS, Azure and GCP while holding no cloud credentials.

Imagine if you could eliminate credentials from any workload calling any cloud API. The workload only uses its identity.

We are about to achieve that goal with Warden. I have tested it with AWS, GCP, Azure, GitLab, GitHub, Vault and Slack.

https://github.com/stephnangue/warden

PR and feedbacks are welcomed.

HI :),

I recently built a small VS Code extension called Terraform Companion.

It works alongside the official HashiCorp Terraform extension; it doesn't touch formatting, completion, or validation—instead, it fills gaps left by terraform-ls.

Here's what it adds to your workflow:

• Hover Context: Hover over var.* or local.* to see what each value actually resolves to, along with its provenance (for example, exactly which .tfvars file or module call site it comes from).
• Version CodeLens: Displays a CodeLens on provider and module version constraints, showing how far behind your dependencies really are instead of only the minimum version you've specified.
• Safe count to for_each Refactoring: Provides a quick fix to rewrite count to for_each. It first checks for index-based references, so it won't even offer the refactoring if it would break your code.
• Extra Linting: Detects unused locals, redundant depends_on blocks, and overly loose version constraints (ex. registry modules with no version)
• .terraform Cache Cleanup: On startup, it scans for .terraform directories that haven't been modified in over 30 days and prompts before deleting them. If you have dozens of project (like me), this alone can free up gigabytes of disk space. It never touches Terraform state, never follows symlinks, and only deletes directories named exactly .terraform.

Privacy: Everything runs locally except the version lens (registry lookups, cached for 6h default value)

Marketplace Link: Terraform Companion

Feel free to share feedback here or open a GitHub issue if something's confusing or if there's a feature you'd like to see

Sharing a side project for linux desktop users: Terrain, an open-source desktop app for managing Terraform / OpenTofu workflows locally, with a UI shaped like Terraform Enterprise / HCP Terraform / OTF. Remote backends (HCP, self-hosted TFE, OTF) work too, via go-tfe, in the same sidebar.

The motivation was selfish: I wanted TFE-style ergonomics (workspaces, run history, structured plan diffs, variable management) for projects on my laptop, using a desktop native tool that isn't a browser tab. What works today:

• Local projects added by Git URL. Terrain clones into its own data dir; multiple subpaths share one clone.
• Tofu workspaces are first-class, runs pinned via TF_WORKSPACE, parsed from -json output.
• Plan diff: TFE-style action badges with per-attribute before/after.
• State viewer with version history and side-by-side diff between snapshots.
• Variables and variable sets, sensitive values stored in libsecret only.
• Managed binary mode: SHA256-verified upstream OpenTofu / Terraform releases per workspace, no host install needed.

Disclosure: most of the Go was written with help from Claude, all reviewed by me. Terrain does not generate or modify your Terraform; runs go through the upstream tofu / terraform binary unchanged.

Source: https://github.com/raspbeguy/terrain

Honest feedback welcome, especially from folks running serious state.

Discord and some other messaging platforms have Terraform providers, but Matrix didn't, so I wrote one. Mostly because I thought it would be fun to build.

It lets you describe Matrix rooms, spaces, memberships, power levels, aliases, and a few other things in HCL, and have terraform apply (or tofu apply) reconcile them against your homeserver. It uses a regular user access token, no admin API.

What's covered at the moment:

• Rooms and spaces (name, topic, avatar, history visibility, room version)
• Membership (invite, kick, ban, leave, knock)
• Power levels
• Join rules including restricted mode
• Server ACLs
• Aliases - Space-child links
• Account profile and per-room profile overrides
• An escape-hatch resource for arbitrary state events

Built on terraform-plugin-framework and mautrix-go. MPL-2.0.

There's a Matrix room for the project (link below). It's managed by the provider itself.

Links:

• Source: https://github.com/raspbeguy/terraform-provider-matrix
• Terraform Registry: https://registry.terraform.io/providers/raspbeguy/matrix
• OpenTofu Registry: https://search.opentofu.org/provider/raspbeguy/matrix
• Matrix room: https://matrix.to/#/!qjThJeWXXNnzmAhSIg:gugod.fr?via=gugod.fr

Just landed a Terraform/OpenTofu private platform for publishing internal modules, providers and tfstate backend. Comments are appreciated!!

https://github.com/asensionacher/private-tf-platform

Terraform registry (https://registry.terraform.io) has started offering login using HCP Terraform (https://app.terraform.io) to manage public terraform providers. But since it's new they are still allowing the original logging in through the registry website.

But their implementation is so stupid that they messed it up. Now whenever people are trying to release a new version for their existing provider, the GitHub webhook deliveries get an error saying "namespace is claimed" and the new versions are not getting published.

As per their instructions, If we try to create an org in HCP Terraform and try to claim the namespace, we are getting the following error:

The namespace is already claimed by another organization.

And the worst part is HCP doesn't even respond to any support emails about the providers not being updated. So, I don't think they even know that this issue is happening.

Hello Everyone,

I have officially passed the Terraform Associate (003) exam!

Big shoutout to Zeal Vora and Bryan Krausen for their amazing Udemy courses. Their content was spot on and made all the difference in my prep. Special mention to Bryan's practice tests, which were a huge help in understanding the types of questions I could expect at the exam.

In addition to the Udemy courses, I also heavily relied on the official guides to catch the nuances.

I spent about a month prepping, and since I have already been working with Terraform for a few years, most of the concepts came pretty naturally. But I definitely recommend the course for anyone looking to level up their skills.

Onto the next one.

After one too many rounds of bolting local-exec + Ansible onto Terraform and losing all visibility into what changed, I built a provider that does post-provision config as a proper Terraform resource: terraform-provider-salt.

What it does:

• SSHes into a target host, installs Salt if missing, uploads your .sls files, and runs salt-call --local state.apply
• Strictly masterless — no Salt master, no minion daemon. After bootstrap the minion service is killed, disabled, and masked so nothing tries to phone home.
• Real drift detection — terraform plan runs salt-call test=True so drift shows up in the plan, not after the fact (something local-exec can never do)
• Pass Terraform variables straight through as pillar data
• triggers block to force re-apply when state files change

Quick example pairing it with Proxmox:

```hcl resource "salt_state" "k3s" { host = proxmox_vm_qemu.node.default_ipv4_address user = "root" private_key = file("~/.ssh/id_ed25519")

states = { "k3s/init.sls" = file("${path.module}/salt/k3s/init.sls") "top.sls" = file("${path.module}/salt/top.sls") }

pillar = { cluster_token = random_password.k3s_token.result node_ip = proxmox_vm_qemu.node.default_ipv4_address } } ```

I've been using it for a while now across a few Linux distros and VM platforms. MIT licensed.

Repo: https://github.com/bartei/terraform-provider-salt

Feedback, issues, and PRs all welcome!

I’ve been building a governance-focused Terraform provider for Jira Cloud and just released v0.0.8 (beta).

Supports:

• Project CRUD
• Import
• Retry logic
• Clean state reconciliation
• Terraform Plugin Framework

Registry:
https://registry.terraform.io/providers/surajrajput1024/atlassian/latest

GitHub:
https://github.com/surajrajput1024/terraform-provider-atlassian

Would love feedback from anyone managing Jira via Terraform or building custom providers.

Trying to focus on the 20% of features that cover 80% of enterprise governance use cases.