I was a Terraform believer.

I had written hundreds of .tf files. I had debugged state corruption at 2 AM. I had carefully designed remote backends in S3 with DynamoDB locking so my team wouldn't step on each other. I had given internal talks about Terraform best practices. If you had asked me two years ago whether I'd ever move away from it, I would have laughed.

And then I started using MechCloud — a stateless Infrastructure-as-Code platform that treats live cloud APIs as the source of truth instead of a state file — and I had to rethink a lot of things I took for granted.

This is not a hit piece on Terraform. It is still an exceptional tool with a massive ecosystem. But the experience of working without a state file made me realise how much mental overhead I had quietly normalised over the years, without even questioning it.

Here is what I learned.

What "stateless" actually means

Before I explain why I moved, I need to clarify what "stateless IaC" means — because it sounds paradoxical at first.

Every IaC tool needs to know what currently exists in your cloud account before it can figure out what changes to make. Terraform solves this by maintaining a state file — a local record of every resource it has created. When you run terraform plan, it compares your .tf files against this state file, then diffs the state file against the real cloud.

A stateless platform eliminates the state file entirely. Instead, it queries live cloud APIs at runtime to discover what actually exists. No cached record. No reconciliation between "what Terraform thinks exists" and "what actually exists." The cloud itself is the source of truth.

MechCloud does this by querying your AWS account directly — reading the real state of your resources on every run — and then using your YAML templates to determine what changes are needed.

Simple idea. Profound implications.

The problems I didn't know I had

1. State drift was a constant background anxiety

With Terraform, state drift happens whenever someone changes infrastructure outside of Terraform — through the AWS Console, a CLI command, a Lambda function, a deployment pipeline you didn't write. Terraform has no idea these changes happened. Its state file is now lying to you.

The result? terraform plan gives you a diff that is subtly wrong. You apply it, and either something breaks, or Terraform "fixes" the manual change and rolls it back, or you get a conflict error and spend an hour debugging.

I had built habits around this: periodic terraform refresh, strict policies against console access, "import" commands for resources added manually. These were all reasonable coping mechanisms. But they were all coping mechanisms for a problem that, I now realise, was architectural.

When the live cloud API is your source of truth, drift simply doesn't exist as a concept. What is in your cloud account is the truth. Every plan is based on reality, not on a cached snapshot of reality.

2. State file management was its own infrastructure problem

Where do you store the state file? S3 — but then you need bucket versioning, encryption, access policies, and lifecycle rules. You need a DynamoDB table for locking. You need IAM roles that can access both. You need to make sure the S3 bucket itself is in a region you trust.

I once spent a full day debugging a production incident that traced back to state file corruption caused by two CI/CD pipelines running terraform apply simultaneously, despite DynamoDB locking. The lock had been acquired, but a network timeout caused one pipeline to retry without properly releasing it first.

State file management is real infrastructure that you have to design, secure, maintain, and occasionally rescue. With a stateless platform, this problem category simply vanishes.

3. Onboarding a new team member was always an event

Any time a new DevOps engineer joined my team, their first week inevitably included:

• Getting access to the S3 backend
• Pulling the state file
• Running terraform init with the right backend config
• Discovering that someone had checked in a local .tfstate file by accident
• Learning which modules were "safe" to plan vs. which ones would cause a cascade

With a stateless platform, there is nothing to initialise and no state file to synchronise. The new team member connects to the cloud account, and what they see in the YAML templates is exactly what they'll get. The learning curve shifts from "how does this tool manage state" to "what does this infrastructure actually do" — which is a much better thing to be learning.

4. Importing existing resources was painful

If you have resources that weren't created by Terraform — which in any real company, you always do — you had to use terraform import. This required you to:

1. Write the resource configuration by hand
2. Know the exact resource ID in AWS
3. Run terraform import <resource> <id>
4. Verify that the state now matches reality
5. Run terraform plan and hope it shows no diff

This was tedious and error-prone. One mismatched attribute and your next terraform apply would attempt to modify or destroy a production resource.

A stateless platform that queries live APIs can discover your existing resources automatically. There is no import step. What exists in AWS is what the platform works with.

What the transition actually looked like

I want to be honest here: the transition was not instant, and it required a mindset shift.

The biggest adjustment was moving from HCL (Terraform's language) to YAML templates. MechCloud uses a hierarchical YAML structure where resource nesting mirrors API dependency. For example, a subnet lives under a VPC in the template because it depends on the VPC ID — and that hierarchy makes the dependency explicit and readable.

Here is a simplified example of what a VPC with a subnet looks like in MechCloud's YAML template format:

resources:
  - type: aws_ec2_vpc
    name: vpc1
    props:
      cidr_block: "10.0.0.0/16"
      enable_dns_support: true
      enable_dns_hostnames: true
    resources:
      - type: aws_ec2_subnet
        name: subnet1
        props:
          cidr_block: "10.0.1.0/24"

The subnet is nested under the VPC in the resources block. MechCloud automatically injects the VPC ID into the subnet creation call. You never manually write vpc_id = aws_vpc.main.id the way you would in Terraform.

At first this felt like "magic I can't see." Over time it felt like "removing boilerplate I was always writing."

The other adjustment was psychological. When you've relied on terraform plan to show you a diff, working without a state file means trusting that the platform is accurately reading your live infrastructure. That trust took a few weeks to build — mostly through watching it work correctly, repeatedly, on real accounts.

What I won't go back to

State file management. Not for a second.

The cognitive overhead of ensuring state is accurate, backed up, locked, and shared correctly across a team adds up quietly over months and years. You stop noticing it the way you stop noticing background noise — until it's gone, and you realise how much quieter everything is.

Beyond that: the ability to discover existing infrastructure without import commands, the confidence that every plan reflects actual cloud state, and the simpler onboarding story are things I now consider table stakes.

Who should consider making this move

This approach is particularly compelling if:

• Your team has experienced state drift, state corruption, or state locking incidents
• You are managing infrastructure across AWS, Azure, and GCP and want a unified interface
• You want to reduce the infrastructure-for-your-infrastructure overhead
• You are exploring AI-assisted infrastructure provisioning (MechCloud has a PromptOps layer that lets you describe infrastructure in natural language)
• You are starting a new project and can design without Terraform lock-in

It is less immediately compelling if:

• You have a large existing Terraform codebase with dozens of modules (migration effort is real)
• You depend on niche Terraform providers for non-cloud services
• Your team is deeply invested in the HCL ecosystem and tooling

What I learned about learning

This experience taught me something beyond the technical.

I had spent years becoming expert at Terraform's way of solving a problem — so much so that I had stopped questioning whether the problem itself was necessary. State files felt like a law of nature, like something IaC simply had to have. It took using a tool that eliminated them entirely to realise they were a design choice, not a requirement.

That's the kind of learning that doesn't show up on a resume but changes how you evaluate tools for the rest of your career.

What's next

In my next post, I'll walk through a hands-on tutorial: provisioning a complete AWS VPC setup with MechCloud's YAML templates — covering the resource hierarchy, the ref: syntax for cross-resource references, and how it compares to writing the equivalent in Terraform HCL.