Terraform Alternatives

terraform reviews and mentions

• Terraform: cómo declarar infraestructura en código con HCL
  3 projects | dev.to | 21 Sep 2026
• Managing Terraform Across Multiple Cloud Providers
  1 project | dev.to | 6 Jul 2026

  That's a security problem. A compromised CI pipeline with AWS and Azure credentials exposes both clouds simultaneously. And it's an operational problem — rotating credentials means updating every pipeline that touches that state. This problem compounds at scale: Terraform couples provider processes tightly to credentials, so managing hundreds of accounts across clouds means spawning thousands of provider processes, which quickly becomes unmanageable.

• Scaling Terraform Infrastructure Beyond a Single Team
  2 projects | dev.to | 6 Jul 2026

  Terraform has no built-in concept of per-team or per-workspace permissions. All workspaces in a backend share the same credentials, so giving a user access to one workspace implicitly grants access to all of them. There's been a long-standing request to support separate backend configurations per workspace, and a related request to allow variables in backend configuration blocks — both still open. Teams that need isolation end up managing separate backends per team — which works, but now the cross-team dependency problem (how to pass outputs between backends) sits on top of the access control problem. The demand for a scalable multi-root-module architecture is significant — OpenTofu's proposal to make terraliths a thing of the past has drawn significant community support.

• Detecting and Managing Terraform Drift
  3 projects | dev.to | 3 Jul 2026

  Provider upgrades. A new version of the AWS provider reads a resource differently — normalising JSON policies, reordering security group rules, or adding new default attributes. The resource hasn't changed, but the plan shows a diff. This is one of the most common sources of noisy drift — expected changes from the refresh report that aren't real drift but look like it.

• The Problem with Large Terraform States
  2 projects | dev.to | 30 Jun 2026

  The most visible symptom. Plan time scales with resource count because every resource is refreshed on every plan, regardless of whether its configuration changed. The exact speed depends on provider — AWS resources with complex nested structures (IAM policies, security group rules) are slower to refresh than simple ones, and Azure resources that require multiple API calls per refresh are worse still. These aren't edge cases — users regularly report 2,900-resource states taking 20–25 minutes to plan and 1,600-resource states taking 8+ minutes. Even starting Terraform with a large state can take minutes before a single API call is made. There's a long-standing proposal for terraform plan -light that would only refresh resources whose configuration changed, but it remains unimplemented. OpenTofu has a similar request to skip refreshing unchanged resources and a proposal for state compression to reduce the overhead of large state files.

• How To Learn Go Fast: A Practical Roadmap For Senior Backend Developers
  8 projects | dev.to | 26 Jun 2026
• Release on Demand
  6 projects | dev.to | 5 Jun 2026

  When a change earns its way onto main, the train builds the container image one time and tags it by the commit SHA. That image is the artifact. It runs in dev immediately. And here's the part that makes promotion boring: shipping to prod doesn't rebuild anything. It re-points a config overlay (a Kustomize overlay, in practice, committed to the same repo) at the same SHA that's already running in dev. Same bytes, different environment. Promotion is a routing decision, not a build decision. The thing you tested in dev is the literal thing that runs in prod. Not a rebuild from the same commit and a hope. The same image. That cleanly splits two worlds that most setups jam into one giant deploy job. The slow-moving substrate (the cluster, the network, IAM, the shape of your manifests) changes on the order of a quarter and belongs to Terraform, ideally run through something like Terraform Cloud so applies are deliberate and auditable instead of run from someone's laptop. The fast-moving payload (image refs, rollouts, the things that change every commit) belongs to Git, reconciled continuously by a GitOps controller. Argo CD is the common one: it watches the repo, diffs the declared state against what's actually running in the cluster, and makes the cluster match. Change the overlay in Git, Argo CD notices and applies it. Flux does the same job if you prefer it. TF for the building, Git for the lights. The rule is simple: if it changes per release, Git owns it; if it changes per quarter, Terraform owns it. Match the tool to the rate of change and the six-hour deploy job that rewrites your infrastructure mid-flight just stops existing. One more piece falls out of this: tags are markers, not artifacts. The cluster never deploys a tag. The tag is a point-in-time anchor that says "this commit's state was live in prod," useful for audit, for rollback targeting, and for release notes. It records what shipped and when. Nothing reads it to decide what runs.

• Scarab Diagnostic Suite Field Test #006: Terraform Console Panic
  1 project | dev.to | 3 Jun 2026
• Jenkins as a Code, or how I stopped clicking around in the UI
  12 projects | dev.to | 18 May 2026

  AWS EC2 / Azure VMs (Linux and Windows) — Dedicated job run terraform to provision and de-provision instances from packer templates.

• Going Production on Cloud: Infrastructure Best Practices Every Engineer Should Know (Part 1)
  1 project | dev.to | 7 May 2026

  Use an IaC tool like Terraform to define every resource declaratively, and a configuration management tool like Ansible for anything that runs on the instance itself.

• A note from our sponsor - AppSignal
  www.appsignal.com | 10 Oct 2026

  Stop vibe-debugging. Every exception, every backtrace, grouped so you see patterns, not noise. Learn more →