I built Rootform to review architectural changes in Terraform plans. You can explore the changes in context, inspect the evidence behind a relationship, and check the architecture against policies.

Open a plan and you can compare the starting architecture with the proposed result, follow the relationships around a changed resource, and keep the unchanged parts in view.

The attached demo uses a synthetic event platform. A subscription switches queues; the old destination, new destination and unchanged source topic are visible together. You can select the delivery relationship to inspect the rule and input evidence behind the change.

You can also export the interactive review as a single HTML file. A teammate can open it in their browser, navigate the architecture and inspect the changes without installing Rootform or running a server.

Both the structured architecture view and the constellation view are included. The latter lets you explore connections across the map or focus on the neighbours of a selected resource.

Rootform uses explicit rules to interpret relationships rather than drawing every Terraform dependency as a connection. When it cannot establish a relationship, it records the uncertainty.

Analysis stays local: Rootform doesn’t execute Terraform or contact your cloud accounts. You can also run policy checks and use the GitHub Actions integration in your existing pipeline.

Try the Playground, no signup or installation. Open a sample plan, inspect a change, then switch to Constellation to explore its surroundings: https://rootform.dev/playground/

GitHub: https://github.com/rootform-dev/rootform

What do you currently share alongside a Terraform plan to explain an architectural change to reviewers?

Review event driven plan with Rootform

Fireworks deployments are normally managed with firectl or the console, so I wrote a provider.

terraform {
  required_providers {
    fireworks = {
      source  = "amrutp24/fireworks"
      version = "~> 0.3"
    }
  }
}


resource "fireworks_deployment" "llama" {
  base_model       = "accounts/fireworks/models/llama-v3p1-8b-instruct"
  accelerator_type = "NVIDIA_H100_80GB"


  min_replica_count = 0 # scale to zero when idle
  max_replica_count = 2
}

Resources: fireworks_deployment, fireworks_dataset, fireworks_supervised_fine_tuning_job. Data sources: fireworks_deployment, fireworks_model. API key and account id come from FIREWORKS_API_KEY and FIREWORKS_ACCOUNT_ID.

On maturity, since it matters more than the feature list. It's 0.x, so pin it. Only fireworks_dataset has been run against the real API end to end. Deployments and fine-tuning jobs are covered by acceptance tests against an in-process mock, because creating a deployment needs a payment method on the account and training a real fine-tune costs money. Where I couldn't test against production the schema follows Fireworks' docs, which is a weaker guarantee and I'd rather say so than not.

Not there yet: autoscaling policy blocks, uploading dataset files through the API (datasets reference data by external_url today), reinforcement fine-tuning.

Registry: https://registry.terraform.io/providers/amrutp24/fireworks/latest Source: https://github.com/amrutp24/terraform-provider-fireworks

If you run Fireworks at any real size, the thing I'd most like to hear is whether the deployment schema matches what you actually configure. That's the resource I couldn't verify myself.

In my limited free time, I enjoy maintaining community Terraform modules. Digging through the Terraform Registry documentation and switching between the browser and terminal can be tedious, so I (and Qwen) built tfrd to compare the resources in a Terraform configuration with the provider schema and report unused attributes and parameters. As a community contributor, I want my modules to reflect the full range of functionality providers support, and this tool helps me find gaps.

Terraform module which creates a Lambda function that runs in reference mode: the function reads its deployment package directly from an S3 bucket you own, and GitHub Actions deploys new code through an OIDC-trusted role. The module also provisions the artifact bucket, the IAM roles, the GitHub OIDC trust, and an optional deny policy that blocks direct console or CLI edits.

hi, my company started using agentic ai for the building infra as code using azure verified modules. Now this is something new becos I have always managed infra code separately from the app code (separately repo) and since agentic ai is something can do both is this even relevant to follow this isolation. Does this makes agentic dev hard or is it still good to do that. Please share your experiences.

I got tired of clicking through the TL-SG108E web UI, so I built a Terraform provider for the TP-Link Easy Smart line. It's now public:
https://github.com/davidlukac/terraform-provider-tplinkeasysmart

What's different

- Speaks the switch's native management protocol (UDP, the one the vendor's Windows utility uses) instead of scraping the HTML UI. It handles the 2023+ firmware RSA login change.
- 11 resources and 12 data sources: VLANs (port-based and 802.1Q), PVIDs, LAG, port mirroring, QoS, IGMP snooping, loop prevention, storm control, port settings, LED, system info, etc.
- Safety guards: risky changes (management path, VLAN mode, locking yourself out) are refused at plan/apply time unless you explicitly opt in. Without a console, a bad write means a factory reset, so I built it to be paranoid.
- Multiple switches via provider aliases, import support, drift detection.
- Offline test suite against a fake UDP switch, about 99.9% measured coverage, CI matrix over Terraform 1.4 to latest, plus an OpenTofu leg.

Honest status

- Pre-1.0 (v0.26): the interface can still change between minor versions, so pin it (~> 0.26) and read the changelog before upgrading.
Available from the Terraform Registry (davidlukac/tplinkeasysmart) with signed releases; terraform init is all you need.
- Verified live on a single TL-SG108E v6 (firmware 1.0.0 Build 20230218). Other Easy Smart models are untested, and firmware from before the 2023 RSA key exchange isn't supported. There's a read-only first-run config and a hardware report template if you want to try yours.
- Needs to be on the same L2 segment as the switch (the protocol is broadcast-based).
Feedback, bug reports and "works on my TL-SG1016DE / TL-SG105E" confirmations are very welcome.

Update: it's now on the Terraform Registry, so there's no more building from source: source = "davidlukac/tplinkeasysmart" and terraform init. Releases are GPG-signed binaries on GitHub too. Thanks for the feedback so far. The README now states the verified device (TL-SG108E v6, fw 1.0.0 Build 20230218) up front, with a compatibility table and a read-only first-run config, so you can check your own model without any risk of writing to it. Hardware reports welcome:
https://github.com/davidlukac/terraform-provider-tplinkeasysmart/issues/new?template=hardware_report.yml
Registry: https://registry.terraform.io/providers/davidlukac/tplinkeasysmart

(Disclosure line, if you want it: developed with AI assistance, Claude Code, with every write path tested offline and verified against real hardware.)

I’ve released v0.6.0 of an independent community Terraform provider for managing Google Ads as code. It is now available in the Terraform Registry as vittorfp/googleads.

Current coverage includes core Search and Performance Max stacks, conversion actions, assets, targeting, shared negative lists, labels, and an importer that converts an existing account into Terraform resources and import blocks. It targets Google Ads API v25.

A realistic caveat: this is pre-1.0 and intentionally does not cover the full Google Ads API. If you try it, pin the version and review plans carefully—especially before applying to a production Ads account.

I’d particularly value feedback on schema gaps, import drift, and workflows that are currently unsupported. Issues and small reproducible examples are very welcome.

GitHub: https://github.com/vittorfp/terraform-provider-googleads

Independent project; not affiliated with Google.

Hi guys, I hope you're doing great.

so I'm preparing to take the Hashicorp Terraform Associate (004) and I'm trying to find any ressources that might help.

since I'm more into reading is there any books you'd recommend for this manner?

thanks

I built cairn, a repo-mapping tool for coding agents. It now parses Terraform (plus CloudFormation/SAM, Serverless, CDK) and records which repo creates each SQS queue, SNS topic, DynamoDB table, S3 bucket, EventBridge bus, Kinesis stream, SSM parameter, and Lambda function. Then it links every repo that references the resource back to the creator repo.

Matching covers ARNs, queue URLs, `Fn::ImportValue`, Terraform data blocks, and env vars. Stage interpolation is resolved, so `orders-${var.stage}` and `orders-prod` are the same table. Generated dirs like `.terraform` and `cdk.out` are never scanned.

Free and open source (Apache 2.0). It's also a Claude Code plugin on the marketplace: `/plugin marketplace add Moe1177/cairn`, then `/plugin install cairn@cairn`. Repo: https://github.com/Moe1177/cairn · PyPI: https://pypi.org/project/cairnmap/

I am the author. Curious how it handles real-world modules, so try it and tell me where it misfires.

We run infracost on every PR with a threshold that fails the build and it's good at what it does. Our AWS bill still went up about a fifth over the same six months. When finance asked which PR did it, I looked and found none because none of it came through a PR. Here's where it came from.

• NAT processing. Infracost prices the gateway hours, while the per GB charge is whatever you put in the usage file which for us was still the default.
• S3 requests on buckets created a year ago that just got busier.
• Cross-AZ traffic after a refactor that didn't add a single resource.
• The HCP bill itself since we imported a pile of old stuff into state and the per resource charge went up with it.

None of that shows up in a plan but tying the bill side back to the module and the person who owns it helped. We do that in pointfive now and it opens the terraform PR for the fix which at least lands the cost with whoever wrote the code. It's still after the fact though.

https://dibsonstuff.com/quiet-social-locking.html

Wrote a thing about how people use both terraform locking and social locking with Dibs. It's hopefully a lot more blog than spam. And written by a human hand! (although I did use a little something-something for the header image).

Maybe worth a read if you've got competing infrastructure stack deployments and negotiate that stuff in Slack all the time.

I have created Fabric FAST v58 scripts for a regulated GCP landing zone (NIS2, GDPR, ISO 27001).
Additionally, a set of scripts for the application layer: Vertex AI RAG with Vector Search and Model Armor, services on a shared GKE cluster, Cloud Run with private Cloud SQL and event analytics to BigQuery, and MySQL to Cloud SQL with Database Migration Service. All applications are wired to the same compliance frameworks.

https://github.com/Merlin-Studio/GCP-Terraform-Vertex-AI-RAG-GKE-Examples

Any comments welcome, thanks.

Hey everyone!

Back in 2020, I created a small Terraform provider called uname as a helper for a few projects I was working on.

Fast-forward to today, and it just reached 200,000 downloads! 🎉

It's kind of funny that the smallest open-source project I maintain has turned out to be the most popular one. 😄

A big thank you to everyone who has used it, recommended it, or incorporated it into their infrastructure workflows. It's really cool to see something you built for your own needs end up being useful to other people!

For those unfamiliar with it, the provider exposes host kernel and architecture information through Terraform data sources and provider functions. It also works with OpenTofu.

Some use cases include:

• Detecting the host OS and architecture to download the right binaries during provisioning
• Infrastructure testing and compliance checks
• Infrastructure inventory
• And probably a few use cases I haven't even thought of!

Repository: https://github.com/julienlevasseur/terraform-provider-uname

Since I'm sharing, I'd also like to introduce another personal open-source project of mine: Profiler.

Profiler solves a different, everyday developer problem: managing shell environment variables.

You can save your shell environment as named profiles and switch between them with a single command. It's handy when working across multiple projects, switching between development environments, or managing different sets of environment variables without manually exporting everything over and over. (supports also .env and auto kubectl namespace switch)

If that sounds useful, give it a look!

Repository: https://github.com/julienlevasseur/Profiler

Thanks again for the support, and happy hacking! 🙂

Title. Since only the specific GH App can request a token , you cant run the Terraform state commands locally.

The workaround I can only think is to temporarily add Secret or if frequent then create Certificate in App Registration.

But are there other ways I am not aware, how do you guys handle such situations?

Hey guys, I started a job working in Infrastructure as Code. I have a CS degree, but I don’t have experience with cloud engineering or stuff related to Terraform, ADO, or Azure portal. I’m doing stuff at my job (code is mainly written using copilot or ChatGPT) and I feel a lost. I don’t know any of the concepts for cloud computing or virtual machines or resources and things like that. I am looking into it online but I still don’t know where to begin. I hear my coworkers doing this stuff well, despite also not having any experience in it when they started either. I have to look at build sheets and things like that and then provision resources using terraform but I don’t really understand much of anything that I’m looking at besides simple code snippets. Is there any advice yall could give me about this, or how/what to learn so that I can wrap my head around things? Any advice is appreciated, thanks!

So i built a deliberately vulnerable stack in Terraform to mirror the actual AWS-side misconfiguration from the Capital One breach, not the ssrf bug itself !!, that was application-layer, but the two settings that turned it into 106 million exposed records: an EC2 instannce still accepting unauthenticated IMDSv1 requests...., with an IAM role attached granting broader S3 access than the instance needed.

writing this as code surfaced something worth shariing on its own. If you fix a misconfiguration like this by hand, live, outside your Terraform state, aws ec2 modify-instance-metadata-options directly, say, the next terraform apply can silently revert it back to whatever the .tf file still says. A real fix needs to go into the actual resource block, http_tokens = "required" on the instance's metadata_options, not a one-off CLI command patched onto a live resource.

then i Ran Plexavo, an open source AWS cloud security intelligence tool i built, against the stack afterward to confirm the chain traced correctly end to end, internet-facing instance, unauthenticated metadata, over-permissioned role, straight into the bucket.

Repo if anyone wants to see the actual checks: https://github.com/plexavo/Plexavo

Finder treats Terraform files as an icon. This free Quick Look extension syntax-highlights .tf, .tfvars, YAML, HCL-adjacent configs and 48 other languages. Signed and notarized, Homebrew install, open source under MIT. No commercial angle, just scratching my own itch.

https://konstruukt.com/projects/qlcodepreview/

Hi guys I am working on gh enterprise and i was wondering what are the possible code concerns like code quality and code security. I have enable code ql on pipelines but i am not even sure if that helps because terraform being a domain specific language. I am also considering checkove. But that leads me to inquire , from you perspective what are the key concerns you have faced while managing IaC. What i can think from top of head is the soneone committing secrets or keys in the GH. Or may be poorly formatted code.

Can you please share your experience with such.