Choose a self-hosted Terraform and OpenTofu platform

A team does not need a platform merely because it uses Terraform or OpenTofu. Choose one when shared execution, approval, worker placement, state coordination, or audit evidence has become a real operating problem.

OpenTofu calls this product category TF Automation and Collaboration Software (TACOS): software that manages and orchestrates OpenTofu execution. See the OpenTofu category definition before comparing products with different deployment models.

Compare the operating models

Model	Good fit	Main trade-off
Local CLI	A small team with simple ownership and trusted operator machines	Each operator must coordinate credentials, state, concurrency, and evidence.
General-purpose CI runners	Teams that already express infrastructure delivery as CI jobs	Approval, state, drift, and run lineage depend on the surrounding CI design.
Pull-request automation	Teams whose main boundary is a reviewed repository change	Repository review does not by itself prove which final plan artifact is applied or cover every non-PR operation.
SaaS control plane with private agents	Teams that accept a vendor-operated control plane but need execution near private targets	The execution plane can be private while control-plane data and availability remain vendor-dependent.
Self-hosted control plane	Teams that require the control plane, execution, state services, and keys inside infrastructure they operate	The team owns deployment, upgrades, availability, backups, restore drills, observability, and worker images.

These models can overlap. A self-hosted platform can receive requests from CI, and a pull request can remain the source-review boundary. The decision is which system owns run admission, the final execution record, approval, worker placement, and recovery.

Evaluate the boundaries

Control-plane and data ownership

Ask where these records live:

• user and automation identities;
• versioned infrastructure definitions and resolved inputs;
• plans, logs, artifacts, and audit events;
• state metadata and encrypted state objects;
• credentials and encryption keys.

“Private runner” describes execution placement, not necessarily ownership of the control plane or its data. “Self-hosted” means more operational responsibility, not automatic security.

Execution placement

List every private API, cluster, network, and cloud endpoint that a run must reach. Then verify:

• whether workers can run inside those network boundaries;
• how jobs are assigned and fenced;
• how tool capabilities and versions are matched;
• where cloud credentials enter the execution path;
• whether workspaces are disposable and what data persists after a run.

Approval and artifact integrity

A repository approval and an apply approval solve different problems. A useful apply gate should identify the requester, reviewer, exact plan artifact, inputs, and target environment. Confirm what happens when the plan is stale, replaced, or no longer valid.

State and recovery

A remote backend can centralize state and locking. A platform may also coordinate operation queues, approval, state generations, and recovery. Review the exact storage and locking contract rather than treating “managed state” as one universal feature. The managed state versus remote backend guide provides a focused comparison.

Drift and follow-up actions

Separate observation from mutation. Determine whether a scheduled check can change infrastructure, how repeated findings are deduplicated, what evidence is retained, and which follow-up actions exist in the deployed release.

API and automation

Check whether CI or another system can create an execution request without becoming the hidden source of truth. The platform should preserve the caller, request, resolved execution context, result, and retry boundary.

Where Forgeplane fits

Forgeplane is a private-beta, self-hosted control plane for governed Terraform and OpenTofu delivery. It provides:

• versioned templates and typed inputs;
• environments and instances as execution boundaries;
• named, capability-matched worker pools;
• plan-to-apply promotion with an optional approval record;
• digest checks for the reviewed plan artifact;
• run logs, artifacts, status, and audit evidence;
• optional managed-state coordination; and
• scheduled, non-mutating drift detection with separate follow-up requests.

The coordinator, PostgreSQL, NATS JetStream, object storage, keys, and workers run in infrastructure you operate. The default production worker image intentionally contains no infrastructure tools. You must build or select reviewed worker images and advertise only the capabilities they contain.

Read Self-hosted Terraform and OpenTofu orchestration for the product model and Workers for the execution contract.

When Forgeplane is not the right fit

Do not add Forgeplane only to replace a command that already works safely. It is likely a poor fit when:

• a local CLI and an existing remote backend already meet the team’s coordination needs;
• you do not want to operate a control plane and its durable dependencies;
• you require a public, anonymous package distribution rather than private-beta access;
• you need a feature or backend compatibility that the current release does not document;
• you expect the default worker image to contain Terraform, OpenTofu, Ansible, or provider tooling; or
• you need drift acceptance or code generation to execute automatically. The current drift execution path supports revert_live; other convergence choices remain non-executable records.

Run a proof before production

1. Define one representative template, environment, and instance.
2. Place a reviewed worker where it can reach the real target boundary.
3. Run a plan and verify its logs, artifact, digest, and resolved inputs.
4. Promote it through the approval path and confirm separation of requester and reviewer.
5. Test failure, cancellation, timeout, and retry behavior.
6. If managed state is enabled, test stale-run fencing and a complete backup and restore.
7. Verify that audit and access records answer who requested, reviewed, executed, and changed the target.

Start with the private beta quickstart, then use the Helm deployment guide and permissions reference to design the production boundary.