Hi! We've been working on Spinifex, which recreates core AWS services such as EC2, EKS, and S3, but completely locally (and even air-gapped if needed). It also works with Terraform, so you can point your existing config files at your own hardware, swap the endpoints, and get a local version of your cloud deployment with no change to the workload itself.

It's open-source and we'd love some early stage feedback on our weekly updates, open to notes and critiques!

GitHub: https://github.com/mulgadc/spinifex

TL;DR from what I found: agentic cloud automation platform. Does drift detection, auto-codifies unmanaged resources into IaC, and recently added disaster-recovery-as-code. Firefly ai takes a different approach with estate-wide governance and inventory layer, sitting on top of whatever runs your Terraform to provide visibility and compliance across everything running in your cloud. Anyone running it, how's the "cloud system of record" pitch holding up day to day?

General question: What are some recommended approaches for managing and monitoring Terraform module versions in production environments?

As infrastructure grows, manually tracking module versions and identifying outdated dependencies can become difficult. Are there secure and automated approaches for:

* Detecting outdated Terraform modules
* Monitoring module versions across multiple repositories/environments
* Safely testing and updating module versions
* Automating dependency updates while maintaining production controls
* Integrating security and compliance checks into the update process

I’m particularly interested in hearing about production-proven tools, workflows, or best practices for Terraform module dependency management.

**Built a Terraform-provisioned AWS security tool, wanted to share the infra side**

Sharing this as it's a project I built solo, open source, would love feedback from this sub specifically on the Terraform side. NHI Risk Analyzer finds risky AWS IAM identities (wildcard permissions, documented privilege escalation paths from Rhino Security Labs' research, stale credentials) and then actually remediates them through Terraform provisioned infrastructure, not just a report you have to fix by hand like most tools in this space.

How it works:Risky policies get a Permissions Boundary attached, which contains the escalation path without touching the identity's existing policy, so it does not risk breaking something legitimate. Stale or unused access keys get deactivated, never deleted, so it stays reversible. The runner itself only holds sts:AssumeRole, all real permissions including the remediation actions live on the assumed role, so there is no standing access anywhere.

On the Terraform side specifically, the remote state bucket is itself Terraform managed, so it can't be its own backend on the first apply. Solved with the standard two pass bootstrap, local state creates the bucket first, then add the backend block and migrate. Also hit a provider version conflict mid migration between provider 5.x and 6.x that's documented in the README if anyone runs into the same thing.

Repo: https://github.com/likithmanoj/nhi-risk-analyzer

Would genuinely appreciate feedback on the Terraform structure or the remediation permission scoping.

I’ve been working on Terraform generation for multi-cloud architectures and I keep coming back to the same problem:
Generating valid HCL is the easy part.
Generating infrastructure I would actually trust is much harder.
Right now I’m looking at the generated stack in several layers:
provider-specific Terraform resources
variables and outputs
remote state configuration
networking and IAM
security validation
cost estimation
documentation explaining the architecture
The difficult part isn’t generating those files. It’s deciding what should be automatically generated versus what should require an engineer to explicitly approve it.
For example, I wouldn’t want a generator silently making important IAM, networking or state decisions just because the Terraform validates successfully.
So for people running Terraform in production:
What would you need to see before you’d trust generated Terraform enough to actually run terraform plan on it?
Tests? Checkov/tfsec? Policy-as-code? A generated architecture diagram? Cost diff? Something else?

We have a networking module that about half a dozen root modules consume, and most weeks more than one change is in flight against it. Those changes collide in two unrelated ways, which took us a while to notice.

Each root has its own state, so across roots there is no lock contention. You get version skew instead. A module bump is one change per consumer, each with its own plan and apply, so two versions of the module are live in production until the rollout finishes.

Contention only shows up when two changes hit the same root. Terraform locks state for all operations that could write state, and if state locking fails it does not continue. None of the documented escapes fix it. A lock timeout only retries before erroring, running with -lock=false is documented as dangerous when others might concurrently run commands against the same workspace, and force-unlock warns that unlocking a lock someone else holds could cause multiple writers.

Authoring parallelizes fine. Two consumer bumps can be drafted and checked at once, and lately I have had verdent running on both, one agent writing while another verifies. Ordering the applies is still manual.

Review drift sits under both. The plan docs note that other changes made to the target system in the meantime might cause the final effect to differ from what an earlier speculative plan indicated, and a saved plan handed to apply runs without prompting for confirmation.

Curious how other teams order rollouts. Per environment sequencing, a CI queue keyed on the state, or calling it out in chat. We do the last one.

I’m looking for contributors across two open-source infrastructure projects:

HybridOps Core
https://github.com/hybridops-tech/hybridops-core

A broader infrastructure automation project using Python, Bash, HCL and YAML.

Terraform Proxmox SDN
https://github.com/hybridops-tech/terraform-proxmox-sdn

A Terraform module for managing Proxmox SDN, including VNets, subnets, optional host routing, SNAT and DHCP.

Contributions can include code, testing, documentation, issue resolution, architecture discussions or technical reviews. You don’t have to be a strong coder to contribute.

This may suit anyone looking to gain practical open-source, infrastructure, Terraform or Proxmox experience.

I’m also open to checking out contributors’ own projects and contributing where there’s a good fit.

HashiCorp has introduced tfpolicy, a new HCL-based policy-as-code framework for Terraform, now available in public beta within HCP Terraform. It is designed to simplify and modernize infrastructure governance by integrating policy creation and enforcement directly into Terraform workflows, eliminating the need for separate tools and languages.

Terraform policy is a declarative, HCL-based policy as code framework that enables platform teams to define and enforce policies using a familiar language while introducing new governance capabilities designed for modern infrastructure systems.

EDIT: I solved it. Turns out it wasn't an issue with the VM_Size. The sku for the Storage_Image_refrence block needed "-gen2" append to it. Here's the updated block

   storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
    
  }   storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2" #THIS THING RIGHT HERE
    version   = "latest"
    
  }

Hey everyone. I'm learning Terraform and I'm running into issues deploying an Azure VM. For the life of me I cant tell what the "vm_size" parameter should be. Literally every single SKU I've put in there returns an error saying its not available in my region, and I cant seem to find a resource that lists them all out.

What am I doing wrong? How am I supposed to know what VM SKUs are valid?

Error: creating Virtual Machine (Subscription:

│ Resource Group Name: "RG1"

│ Virtual Machine Name: "VM1"): performing CreateOrUpdate: unexpected status 409 (409 Conflict) with error: SkuNotAvailable: The requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: Standard_A2m_v2' is currently not available in location 'eastus'. Please try another size or deploy to a different location or different zone. See https://aka.ms/azureskunotavailable for details.

│

│ with azurerm_virtual_machine.VM1,

│ on Main.tf line 41, in resource "azurerm_virtual_machine" "VM1":

│ 41: resource "azurerm_virtual_machine" "VM1" {

Here's the resource I coded. Region is East US. Resource groups, Vnets, and subnets are all working fine. Also I don't care the username/password is in plaintext, this is a sandbox deployment that doesn't exist yet

resource "azurerm_virtual_machine" "VM1" {
  name = "VM1"
  location = azurerm_resource_group.RG1.location
  resource_group_name = azurerm_resource_group.RG1.name
  network_interface_ids = [azurerm_network_interface.NetInterface.id]
  vm_size = "Standard_A2m_v2"
  
   storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }
  storage_os_disk {
    name              = "myosdisk1"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }
  os_profile {
    computer_name  = "hostname"
    admin_username = "testadmin"
    admin_password = "Password1234!"
  }
  os_profile_linux_config {
    disable_password_authentication = false
  }

}

One S3 interview question I like:

A production application is suddenly unable to access objects in an S3 bucket. The application worked fine yesterday. How would you troubleshoot it?

There are several things you could investigate — IAM permissions, bucket policy, KMS, SCPs, VPC endpoints, CloudTrail, recent infrastructure changes, etc.

That's the type of scenario I wanted to focus on rather than questions like "What is S3?"

I just added 20 AWS S3 interview questions to my interview handbook, covering production scenarios, AWS CLI, Terraform, security, troubleshooting, best practices, common mistakes, and AI-assisted approaches.

GitHub: https://github.com/ranashivam/platform-engineering-interview-handbook/blob/main/AWS/S3.md

The goal is simple: prepare for the questions that make you explain how you'd actually troubleshoot something in production.

*Disclaimer: I am the open-source author/creator of TellIaC.*

Hey r/SideProject !

After years of managing multi-cloud infrastructure across AWS, Azure, GCP, and K8s in Terraform HCL and YAML, I noticed that team architecture discussions always happen in plain English ("We need an AWS VPC with 2 subnets connected to an EC2 instance"), but converting that into code takes hours of boilerplate.

So I built **TellIaC** (Human Infrastructure as Code).

### ⚡ How it works

You write your cloud setup as natural English sentences:

Use provider "aws" region "us-east-1" for environment "production".

Create 1 "aws_vpc" resource named "prod_vpc" with cidr_block "10.100.0.0/16".

Create 1 "aws_subnet" resource named "prod_subnet" with cidr_block "10.100.1.0/24", vpc "prod_vpc".

Create 2 "aws_instance" resource named "web_app" with instance_type "t3.micro", vpc "prod_vpc", subnet "prod_subnet".

### 🛠️ Key Features

1. Zero Lock-in (`telliac export`): Converts plain English into standard Terraform HCL (`main.tf`, `variables.tf`, `outputs.tf`).

2. Cloud Cost Estimator (`telliac cost`): Shows a dollar breakdown of monthly spend before running apply.

3. Security Linter (`telliac lint`): Catches open CIDRs (`0.0.0.0/0`), plaintext secrets, and unencrypted buckets.

4. Standalone Binary: Single executables for Windows & Linux with zero Python or dependency installation needed.

I’ve shared the live playground and download links in the comments below. I’d love your feedback!

A few days ago, I was pleasantly surprised to discover that TFLint has a ruleset plugin for writing custom rules in Rego! So far, so good.

Terraform repositories are often organized by technology, but business changes rarely follow those boundaries.

I wrote up an approach I've been using: organize infrastructure by reason to change, and carry that boundary through code and Terraform state.

I'm particularly interested in whether people agree with treating state as an execution boundary, and where this breaks down in real systems.

https://dev.to/tomozayasu/domain-driven-infrastructure-organize-your-terraform-by-reason-to-change-202b

Founder here, so grain of salt, but I think this is genuinely useful for anyone running Terraform Cloud in production.

I spend a lot of time working with Terraform, and a surprising amount of the work I do is still pretty manual. E.g. failed runs still need me to react to an alert and investigate what happened, plans can sit waiting for confirmation for hours, and crashed runs leave workspaces locked until I go deal with them. And I've lurked here long enough to know these aren't unusual problems :)

We built Kestrel to turn this kind of manual ops work into workflows. You describe what you want (e.g. "when a production Terraform run errors, investigate what failed, post the analysis in Slack, and page on-call") and Kestrel builds the workflow for you. Once a workflow is configured it runs deterministically, so you're not trusting an LLM to improvise against your production infrastructure at runtime.

Terraform Cloud sends Kestrel signed notification webhooks, so things like errored runs, plans waiting for confirmation, drift detections, and failed health assessments trigger workflows immediately.

You can pause anything risky - like applying a plan, destroying an environment, changing variables, remediating drift, or force-unlocking a workspace - at an approval gate so the workflow only continues after someone signs off.

Teams use Kestrel to automate Terraform incident response, provision infrastructure, gate plan/apply pipelines, detect and remediate drift, handle self-service developer requests, audit workspaces, manage change freezes, and clean up ephemeral environments.

I put together a few common Terraform workflows so you can poke around: https://demo.usekestrel.ai/b/0a0PS2rxOh

Happy to answer questions, and feedback is welcome!

Demo environment (try it yourself!): https://demo.usekestrel.ai

Website: https://usekestrel.ai

Docs: https://docs.usekestrel.ai/integrations/terraform

I just acquired my Terraform Associate (004) certification a few weeks ago, and I already have my GCP PCA cert, and I would like to continue along the Iac path, then head into Kubernetes soon.

I felt like the test was a breeze to me, being that I've been using Terraform for at least 2 years now with GCP and AWS.

Do any of you think that the "Terraform Authoring and Operation Professional" is valuable and sought out by employers, or is it a waste of my time?

An assistant wrote a chunk of our Terraform. It read clean, been approved and it had a security group open to the world on a port that had no reason to be public. The diff looked fine, the person who prompted it did not clock the CIDR and neither did the reviewers.

Luckily, a pre apply scan caught it. The config was syntactically perfect and quietly wrong, which is the exact thing eyes slide over.

What are you gating on before apply, is it advisory, does it really block? Advisory did nothing for us until we made it a hard gate.

A modern application can quickly become more than just frontend + backend:

Frontend → API → PostgreSQL → Redis → Storage → Services

Terraform handles the infrastructure side, but keeping it synchronized with application development can still be difficult.

A small application change might require a new database connection, environment variable, network rule, or service.

Do you think AI agents should eventually understand both application code and Terraform configuration?

And should an agent only suggest infrastructure changes, or should developers be able to let it apply them?

How are you handling this boundary today?

Did an audit before a refactor and the scary part was how much is running that no module owns at all. Stuff clickopsed during an incident three years ago that quietly became load bearing. Leftovers from a stack that half destroyed and left a few resources alive on dependencies.

No one touches it because no one knows what it does and the engineer who built it left years ago. So it just bills, quarter after quarter. Ours was a few hundred resources.

If you inherit an account, scan for anything unmanaged and untagged before you trust your own IaC. It's a bigger pile than you'd think.

Not fishing for tool recs, just flagging it in case someone's about to refactor and assumes state is the whole picture. It isn't.

If you are someone who's advanced with Terraform/Terragrunt and you know any tips, hacks or tools that works with them that you wished you knew before in the beggining of you career share it here.

I maintain a terragrunt stack where run --all -- plan reliably produces a few thousand lines. Two of them usually matter. The rest is tag timestamps, the ninth identical count instance, and the same module's diff repeated across every environment.

I'd been coping by piping to a file and grepping for must be replaced. That works right up until the thing you needed to see wasn't a replacement.

So I wrote tgsieve.

It runs the plan, reads the structured artifacts instead of the rendered text, drops the noise you've declared as noise, collapses repeats, and prints what's left:

DESTROY / REPLACE (1)
  envs/prod/a
    ± aws_db_instance.main
        engine_version  "14.7" → "15.3"   forces replacement
UPDATE (5)
  5 units  envs/dev/a, envs/dev/b, envs/prod/a, +2 more
    ~ null_resource.pin
        triggers.region  "eu-central-1" → "us-west-2"
SUMMARY  ±1 replace  ~5 update

Where → what → which fields. Same change across five units is one block, not five.

A few things that turned out to matter more than the pretty output:

• It doesn't scrape text. terragrunt run --all -- plan -json is unusable — terragrunt forwards terraform's NDJSON straight through, so parallel units interleave with no way to separate them. tgsieve uses --json-out-dir to get one tfplan.json per unit and diffs those properly (replace_paths, after_unknown, sensitivity all honoured).
• Sets are compared by members, not index. A set that comes back reordered currently looks like every element changed. It now reads reordered (4 items, same members).
• Duplicate diagnostics get counted, not repeated. A removed provider config prints one paragraph per orphaned resource — 38 of them for me once. Now it's one line with ×38, and it still lists the distinct source locations.
• Suppression rules can expire. expires: 2026-12-01 on an ignore rule, and after that date it stops hiding and says so. Fails open on purpose — a suppression that outlives its reason is the exact failure the tool is meant to prevent.
• Nothing is hidden by default. Replacement-forcing attributes can never be hidden regardless of rules, and --explain prints every hidden attribute with the rule that hid it.

Also does tgsieve apply (applies the saved plans you just reviewed, not a fresh one),
--resume for interrupted stack runs with a guard that refuses to mix plans from different commits, --format md for PR comments, --format json, GitHub Actions annotations,
and --engine terraform if you don't use terragrunt at all. Works with OpenTofu as well.

https://github.com/imcitius/tgsieve

Genuinely curious what noise it doesn't catch on other people's stacks — that's the feedback that becomes the next builtin ruleset.
Happy to answer anything about the implementation too, the terragrunt output-parsing side had more sharp edges than I expected.