Never lose Terraform state to a missing backend block
Run a workspace whose configuration declares no cloud or backend block and InfraDots now wires its state to your managed InfraDots backend automatically — with a clear heads-up in the run log — instead of silently letting that state disappear. Configs that already define a backend are left exactly as they are.
There's a failure mode in every Terraform automation platform that only bites
you once, but bites hard: you run a configuration that has no cloud or
backend block, it happily creates real infrastructure, and then the state
file — the record of everything it just built — is written to a throwaway
working directory and vanishes when the run ends.
Nothing looked wrong. The plan succeeded, the apply succeeded, the resources are really there in your cloud account. But InfraDots never received the state, so the next run starts from nothing, tries to create it all over again, and now you're untangling duplicate resources and import errors. A quiet gap in one config turns into a loud incident a week later.
That gap is closed.
What's new
Before a run initializes, InfraDots now checks whether your configuration
actually routes its state anywhere. If it finds no cloud block and no
backend block, it does two things:
- Wires up state automatically. It generates a
cloud {}block pointing at your InfraDots-managed backend — using the workspace and organization the run already belongs to — so the state is stored and versioned like every other workspace, with full state history and drift detection. - Tells you it did. A notice appears right at the top of the run's initialization log: no backend was configured, so state is being stored in InfraDots. No silent magic — you can always see when it kicked in.
The resources you create are now tracked from the very first apply, whether or not anyone remembered to add a backend block.
Why it matters
- No orphaned infrastructure. Every apply is recorded. The next run sees what already exists instead of trying to build it a second time.
- Zero-config onboarding. Point a repo at InfraDots and run it. You no longer have to hand-edit HCL to add a state backend before your first apply is safe — it just works.
- Fewer 2 a.m. surprises. The most dangerous bugs are the silent ones. This turns a silent state loss into a visible, self-correcting default.
We never touch a backend you already have
This only fills a vacuum. If your configuration already declares a backend of
any kind — InfraDots, an existing cloud block, backend "remote", S3, GCS,
anything — InfraDots leaves it completely untouched and stays out of the way.
The detection is deliberately conservative: when there's any doubt about
whether a backend exists, it assumes one does and changes nothing, so it can
never collide with a backend you configured yourself.
Under the hood
The check runs on every Terraform and OpenTofu run, scanning the root module for
a configured backend before init. Terragrunt workspaces are unaffected — they
manage their own state through remote_state, which InfraDots already respects.
The injected backend points at the same InfraDots host your run is already
authenticated against, so state flows through the standard, versioned pipeline —
the same one that powers state history, the resource inventory, and drift
detection.
Turning it on
Nothing to flip. It's on by default for every organization. The next time a backend-less configuration runs, InfraDots keeps its state safe and tells you it did — no action required.