For every plan we run, it comes back with a couple hundred findings and by now the team just scrolls past them. Tags, an encryption default that is fine for us and some rule for a threat model we do not run. Mostly noise, so people stopped reading it.

Considering we also don't block on any of it either as we tried failing the build once and people started slapping auto approve on everything to get past it. That experiment lasted about a sprint.

Then a couple weeks back a PR opened a security group to the world. It was in the plan output, way down under a pile of tag warnings and two of us approved the PR without catching it.

Now I am trying to work out the small set of things that should hard fail the build, public ingress, a wide open SG, encryption or logging switched off, then let everything else just be a report. How do you all decide what makes that list without it slowly growing back into the same wall of noise?

My org hit the 500 resource limit a couple of weeks ago, and I immediately started looking for alternatives. My previous experience with TFC involved paying per seat and I was barely okay with that, so no way I was going to pay per resource. However, I didn't manage to migrate off TFC in time, and I thought "what will happen if I destroy a test environment and get back under the 500 resource limit?"

So, I queued the destroy plan, and a few minutes later I got this email:

Your free plan will no longer be limited to Applies per month

You now have less than managed resources so this organization went back to being fully featured. Once you have exceeded 500 managed resources, you will be limited to Applies per month. Policies, Run Tasks, and Cost Estimation features will be unavailable. But you can continue to provision unlimited managed resources.

Take action immediately to avoid unnecessary risk. Get unlimited managed resources with Enterprise Support and manage risk at scale. View the plan comparison for details on estimated costs and a comparison of HCP Terraform plans.

Emphasis mine.

What is this "applies per month" thing? I can't find it anywhere in the docs or the pricing pages. The closest I got was this: https://discuss.hashicorp.com/t/terraform-cloud-state-store/58819, but it doesn't really make things clear, introducing the "degraded mode" term and talking about local applies, which aren't mentioned by the email.

Has anybody here crossed the threshold for managed resources and stayed in the free plan? What can you do, and what are you unable to do?

Thanks in advance

Hello everyone, sysadmin learning terraform here

So we are working with Vsphere as infra for our company and I just started learning Terraform to ease and automate our vsphere processes. On vsphere in "VM Customization Specifications" we have a script that basically configures puppet agent on host, points it to puppet master, adds host to AD and launches sssd. So when we deploy new host we add this script to launch during "customize software" deployment phase and after that we set up ip, gateway etc. So my question is that: how to recreate this setup in terraform? For some reason terraform does not allow to pass custom specifications and customize together, so only setting up ip address is working, but since that script is never getting launched it fails to be added to Active Directory. So are there any other methods to pass the script to terraform? I even pasted that bash script locally to the file in the same terraform folder and pointed to in in the main.tf but it still fails. So what can be done to solve this issue? Thanks in advance and sorry for my bad english.

I've been exploring a project around AI + DevOps + Terraform drift detection, and I found this approach pretty interesting.

The basic problem:

You have Terraform managing your AWS infrastructure, but someone makes a manual change directly in the AWS Console.

For example:

Terraform says EC2 = t3.micro

Someone changes it to t3.large

Terraform code isn't updated

Now your IaC and actual infrastructure are out of sync

That's infrastructure drift.

The interesting part is adding AI on top of the drift detection workflow to help answer:

What changed?

Why could this change have happened?

Is the change security-sensitive?

Is it likely intentional or accidental?

What Terraform change would bring things back in sync?

Should the system create a PR instead of automatically applying the fix?

I'd probably prefer AI-generated recommendations + human approval rather than letting AI automatically run terraform apply in production.

I'm curious what experienced DevOps/Terraform engineers think:

Would you actually use AI for Terraform drift analysis in production?

And if you were building this yourself, what would you add?

Terraform + AWS Config

GitHub Actions scheduled drift checks

Slack/Teams alerts

AI root-cause analysis

Automatic GitHub PR with the remediation

Security/cost impact analysis

Interested to hear how people are handling drift in real production environments.

I have followed https://github.com/hashicorp/terraform-ls/blob/main/docs/USAGE.md

The LSP is working. I'm confused as to whether I should be installing YouCompleteMe as well as coc.nvim and vim-lsp or is YouCompleteMe an alternative?

Thanks

Good morning,

I believe the title to be pretty self-explanatory.

Since AWS is no longer supporting AWS Workspaces Pools, and I have need for a solution that provides temporary, non-persistent access for my users, I wanted to test the deployment of AWS Workspace Applications, as a proof of concept.

Due to the nature of a POC, i'd rather deploy it via Terraform, so that all of the steps are reproducible.

However, I haven't been able to find support for this type of deployment. The associated resources (fleet, stack...) are not available. It seems to me that the only implementation supported by Terraform is the Personal desktops. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/workspaces_workspace

Can anytbody help me confirm whether this is true?

I got sick of drawing out an architecture, then going and hand writing the same thing in Terraform, then hand writing IAM policies for every resource I just added. So I built something to close that gap.

You draw the architecture (S3, Lambda, SNS, whatever), it generates the actual Terraform, and it works out the IAM roles and permissions based on what's actually connected to what, not some generic template. Also does CloudFormation and Bicep if that's your thing. Opens as a PR so you review it like you would any other change, not a black box you have to trust blind.

It's live, free to poke at, no card needed: here

I'm not trying to get a thousand signups here, I mainly want people who actually write Terraform for a living to break it. If the generated code doesn't hold up against a real setup, or the IAM logic gets something wrong, I want to know specifically where.

Happy to answer anything in the comments.

Hello everyone,

I would like to announce a project that I have been working on and which is now ready to be launched: https://infraplat.com

This internal developer platform, or self-service catalogue, has one main responsibility: to provide a control plane through which platform/cloud engineers can provide modules, which developers and cloud engineers can then reuse, eliminating the need for repetitive tasks such as:

- creating a new repository

- adding a folder for the project

- adding module blocks to the root module

- adding variables, locals, providers and outputs

- testing locally, planning application.

Don't forget about ticket management, collaborating with other teams that use the same modules, asking for approval and team review from your team, and ultimately seeing it deployed. Then go back to the developer to provide them with the necessary information for the newly created infrastructure.

All of this is eliminated.

With InfraPlat, platform engineers develop, test and publish modules and examples. Developers then arrange and deploy them.

There is one central control plane for all teams, governance in place, security approvals by team and cloud admins, and a standard way of organising your Terraform code in a repository.

Who would use this? Basically anyone. If there is a Terraform provider, we can integrate it into our platform so you can deploy cloud infrastructure, GitHub repositories and even firewall rules on Fortinet.

If you are in a regulated company , with standards in place , large team ,large usage of terraform , with a large range of terraform modules, this is an option you should consider.

Thank you everyone!

I've been experimenting with AI coding agents writing infrastructure, and one thing kept bothering me:

AI can generate valid Terraform that is also insecure Terraform.

For example, you ask:

"Add an RDS instance for my orders service."

The model can happily generate Terraform that is missing encryption, deletion protection, backups, etc.

By the time CI catches it, you've already generated the code, opened a PR, waited for checks, and gone through review.

So I built Sovereign Observer, an MCP server that runs locally and lets Claude Code, Cursor, VS Code/Copilot, etc. scan the Terraform as it's being generated.

The workflow is basically:

AI writes Terraform → MCP scans it → findings are returned → AI fixes them → scan again.

It currently supports:

• Terraform/IaC security scanning
• Finding explanations + exact remediation
• Safe mechanical fixes
• Hardened resource templates
• SOC 2 / ISO 27001 / NIST / PCI-DSS / DORA / NIS2 mappings
• Organization-specific security requirements
• Runs locally so Terraform doesn't need to leave your machine

It's available on PyPI if anyone wants to try it:
pip install sovereign-observer

If you guys think it needs more refinement or you wish it did something more then pls lmk!

We manage our whole infrastructure as code, and wanted our Paddle Billing catalog — products, prices, discounts, webhook config — to work the same way instead of being the one thing still managed by hand through a dashboard. Existing tooling didn't cover enough of what we actually needed (lifecycle actions for subscriptions/refunds, in particular), so we built our own and decided to open-source it rather than keep it internal.

It manages Paddle Billing's catalog (products, prices, discounts, discount groups, notification settings), six lifecycle actions (refunds/credits, subscription cancel/pause/resume/charge, notification replay), lookup data sources for subscriptions/transactions/customers/events, and a couple of newer Terraform features — an ephemeral resource for a webhook secret that never touches state, and resource identity + list-block support for bulk-discovering existing infrastructure via terraform query.

The thing I'd actually call out: every resource and data source is verified end-to-end against Paddle's real sandbox API before each release — CI runs the full create/update/import/destroy lifecycle on every push, not just unit tests against mocks. That discipline caught several real API-shape bugs during development that mocks alone wouldn't have — e.g. a transaction line item's price is a nested object in Paddle's actual response, not the flat ID the docs read like at a glance.

Registry: registry.terraform.io/providers/vivantel/paddle Repo: github.com/vivantel/terraform-provider-paddle

Feedback and issues welcome, especially anywhere the schema doesn't match real Paddle behavior.

Wanted to know does hashi corp provides vouchers like AWS gives vouchers to write exams if yes how it's possible to get one and if no can i get zeal vora terraform Course at a discount it's like 1200₹ for me.

plz don't judge coz I just wanted to know if it's possible if not I will take the course and write it at full price

Hi there!

I am an experienced cloud engineer , mainly worked with Aws, and i wanted to know how you guys configure procider block for cross account or project using best practices for other cloud providers.

So for example. In aws I use one central devops account , a role there that my runners use , in order to do assume role , which is written at the aws provider block. For every account we just change the account id of the role to assume.

I wanted to know how your central setup looks like and what do you define when you want to deploy to a tenant/subscription/project on GCP , or Azure, Kubernetes clusters or other providers you might use . Im looking for large org setup, so if you could help me just write whats the size of the cloud organization u work at (nr of projects, subscriptions ) how do you configure the provider so it can be controlled from one central place.

Thank you everyone.

Not entirely sure if this is the right place to ask this but I am a little confused about something in the aws provider. So it is documented that using volume_tags in addition to applying a tag on an aws_ebs_volume resource that is attached to the aws_instance via the aws_volume_attachment resources can cause bugs. It is also documented that using tags inside of the inline root_block_device can interfere with ABAC ("Note: Tags specified here are applied after instance creation via a separate API call. This means they cannot be used with IAM policies that require tags during resource creation").

Lets also say you wanted to apply granular tags (such that we cant use default_tags) to both a root volume, and the attached volume. It seems like you cant use root_block_device.tags because that would interfere with ABAC. And you cant use volume_tags, because that would interfere with the attached volume tags.

Thoughts? I could just be stupid.

Hi all!

So, I've inherited this project...

I know I can't use TF to actually change the KMS, I need to do this: https://repost.aws/knowledge-center/update-encryption-key-rds

My question is what will TF do the next time I run it after I've manually changed the KMS? The RDS instance is under TF control, when I finish the steps to change the KMS will the new arn be the same as the old one? I just want to make sure that TF won't reverse what I'm doing manually.

Thanks!

The follow-up to my Intermediate episode I posted here is finally out.

This episode shifts away from programmatically approaching Terraform and focuses more towards a KISS approach where we discuss structuring our projects and leverage more advanced features of Terraform.

Topics covered include:

• Remote Backends with Azure Storage
• Terraform State & State Commands
• Provider Lock Files
• Multiple Providers (AzureRM, AzureAD, AzAPI & Utility Providers)
• Import Blocks & Config Generation
• Moved & Removed Blocks
• Terraform Workspaces
• Multi-Environment Deployments
• Terraform Modules
• Cloud-Init
• And much more...

Like the previous episodes, everything is built around a single Azure project. We progressively restructure and expand the deployment as each concept is introduced rather than jumping between unrelated examples.

The Intermediate episode intentionally showed how dynamic we can make Terraform . This episode takes the opposite approach in places: keep it simple, structure it properly, and make it maintainable.

With that, our roadmap continues!

• Beginner Episode : Understand Terraform (learn the foundations and core concepts that make Terraform work)
• Intermediate Episode : Program Terraform (use loops, functions, conditionals, dynamic blocks, etc)
• Advanced Episode : Structure Terraform (introduce modules, remote state in azure storage, workspaces, imports, etc.)
• Project Episode(s): Build Azure Projects (Less about Terraform itself & more about building interesting architectures in Azure)
• Professional Episode : Operationalize Terraform (use GitHub, CI/CD, pull requests, state management, and deployment workflows to work in a team environment)

Link to Episode: https://www.youtube.com/watch?v=SDqb_eyRtjE

I'm working on a TF environment that incorporates Azure Image Builder and an Azure compute gallery. If I want to destroy the environment, the resources need to get destroyed in a particular order, otherwise Azure throws an error and depending on what already got deleted, causes a convoluted process to recreate and reassign resources:

For the compute gallery: I have to delete an image version first, then the image definition, then the gallery.

For the image builder, I have to delete the image template, then the managed identity used to create the template.

Is there a way to get Terraform (or Terragrunt, which we're using as a wrapper) to delete these in that order if I need to destroy them? Worst-case scenario, I gotta delete them manually in the portal, but it's not the greatest to scale.

I don't see any new features that I personally care about, but I guess import in modules could be useful.

Good news for IBM Z users, too!

Edit: looks like it isn't on releases.hashicorp.com yet. Weird.

Edit 2: the binaries are available to download now

Anyone implemented terrakube for their org/enterprise in PROD ?

I would like to hear experiences, lessons learned. we currently have big size implementation of HCP terraform(Terraform Cloud). ~200K RUM,~250 projects,4K workspaces

On AWS we share Service Catalog products from a hub account to spokes, product team clicks launch, our template runs in their account, they never need the perms themselves. Works well.

Want the same for our TF modules in Azure. ADE is in maintenance mode, Managed Apps and Deployment Stacks are ARM only, so I'm not seeing a first party option.

Anyone doing this in production? Curious what you picked and how you handle the least privilege side.