Managed state or a remote backend?

A remote backend and an automation platform can both store Terraform or OpenTofu state, but they do not necessarily own the same coordination boundary.

OpenTofu remote state centralizes state in a backend or automation platform so a team does not rely on one operator’s local file. Some backends also provide locking. A control plane can coordinate that state with its own run queue, approval, execution snapshot, and recovery rules.

Compare the contracts

Question	Remote backend	Forgeplane-managed state
State location	A backend selected in the Terraform or OpenTofu configuration	An encrypted object coordinated with Forgeplane database metadata and key material
Concurrency	Depends on the selected backend’s locking behavior	Run admission records a base generation; stale executions cannot silently replace a newer generation
Execution queue	Usually outside the backend	Coordinator queue, worker assignment, and run lifecycle are part of the same control plane
Approval	Usually outside the backend	Optional approval is linked to the promoted apply intent and reviewed plan artifact
History	Backend-specific versions or snapshots	Current generation and integrity metadata are coordinated with run history; this is not a promise of every backend’s history feature
Encryption	Backend and deployment specific	State payload is encrypted outside the coordinator database and requires configured key material
Recovery	Restore requirements depend on the backend	Database metadata, encrypted objects, and every required decrypt key form one recovery set
Local CLI access	Often a native backend workflow	Forgeplane-managed state belongs to the governed execution path; do not assume drop-in local backend behavior

This is a contract comparison, not a claim that one model is always better.

How Forgeplane-managed state works

When managed state is enabled, the instance owns the state identity. A run records:

• the state_object_id;
• the base state_generation; and
• the state_status_at_start.

The encrypted state payload is stored outside the coordinator database. The database stores identity, ownership, generation, status, and integrity metadata. Configured key material authenticates and decrypts the payload.

Before a worker result can become current, Forgeplane checks that the run’s base generation is still current. If another execution already advanced the state, the stale run cannot overwrite it silently.

See Terraform and OpenTofu managed state for the full admission and storage model.

Recovery is a coupled operation

A usable managed-state generation requires three layers to agree:

1. PostgreSQL metadata and generation pointers;
2. the encrypted object in S3-compatible storage; and
3. every key ID needed to verify and decrypt retained ciphertext.

Restoring only one layer can produce an internally healthy service with unusable state. Forgeplane marks state recovery_required when it cannot prove one valid current generation. Managed-state mutation then stops rather than creating empty state, selecting an older object, or overwriting the uncertain generation.

A production design needs one manifested backup set, protected key escrow, a restore procedure, and a drill that verifies object identity, generation, integrity metadata, and key access before writes resume.

Use an ordinary remote backend when

Keep or choose a conventional backend when:

• your existing CLI or CI workflow already provides the required queue, locking, approval, and evidence;
• operators need direct backend access outside Forgeplane’s governed run path;
• a backend-specific compatibility feature is mandatory;
• you do not want state recovery coupled to the Forgeplane database, object store, and keys; or
• you have not yet tested Forgeplane backup and recovery under realistic failure conditions.

Do not migrate state merely to make the architecture look consistent. State migration is a high-risk operation and must have an explicit rollback and verification plan.

Use Forgeplane-managed state when

It can fit when you need the state generation to be coordinated with:

• the admitted run and its execution snapshot;
• the worker and requested operation;
• plan promotion and approval;
• stale-run rejection;
• audit evidence and the surrounding instance lifecycle; and
• fail-closed recovery when the platform cannot prove the current generation.

Ansible runs do not use this state path. Ansible is execute-only in Forgeplane.

Migration and production checklist

Before enabling managed state for production:

1. Inventory the current backend, locking, state consumers, output consumers, and recovery process.
2. Confirm that the deployed Forgeplane release supports the required workflow. Do not infer universal backend compatibility.
3. Stop competing writers and verify the intended current state before any migration.
4. Back up the source state and document the exact rollback boundary.
5. Configure durable PostgreSQL, S3-compatible object storage, and protected key material.
6. Test stale-generation rejection and an idempotent retry.
7. Back up and restore all three state layers together.
8. Keep mutation disabled if recovery verification is incomplete.

Use the Helm production checklist, run operations, and admin dashboard recovery guidance to complete the operating design.