Terraform Cloud alternative

Keep the runs. See the whole cloud.

ops0 runs Terraform and OpenTofu with plan review, policy checks, and approval, like HCP Terraform. Then it covers what a run platform never sees: the resources nobody wrote in code.

See the differences

A run platform only knows what is in state. Your bill and your outages do not stop there. 

Terraform and OpenTofuState in your own bucketRead-only discovery first
Side by side

Same runs. Wider view.

What stays the same
  • Plan and apply for Terraform, with every run numbered and logged
  • Policy checks on the real plan before anything applies
  • Approval before deploy and destroy, sent to Slack, email, or a webhook
  • Variables and sensitive values per project
  • Remote state with locking
ops0 adds
The resources nobody wrote in code

Read-only discovery across AWS, Azure, Google Cloud, and Oracle Cloud marks every resource as managed by a project or unmanaged, then turns the ones you pick into reviewed Terraform with imported state.

ops0 adds
Drift that opens an incident

Scheduled drift checks compare code, state, and the live cloud. Changed or deleted resources open an incident and close it when a later check is clean.

ops0 adds
Cost before apply, and a budget that can say no

Each change gets a per-resource monthly estimate, and an org or project budget can block an over-limit deploy at creation and again at approval.

ops0 adds
State in your own bucket

Keep each project’s state in your own S3, Cloud Storage, Azure Blob, or OCI bucket, and pull secrets at run time from AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or OCI Vault.

ops0 adds
Framework policies and a separate approver

Import policy packs for SOC 2, ISO 27001, ISO 27002, HIPAA, GDPR, and CIS in one step. With separation of duties on, the person who starts a deployment cannot approve it.

ops0 adds
More than Terraform

OpenTofu, CloudFormation and StackSets, Ansible, Kubernetes, and guardrails for coding agents run through the same approvals and audit trail.

Fair comparison

When HCP Terraform is the better fit.

Moving a workspace

Six steps per workspace.

  1. 01
    Connect the cloud read-only

    Run discovery first to see everything running in the account, so nothing outside your workspaces is missed.

  2. 02
    Create a project per workspace

    Point it at the same GitHub or GitLab repository and folder.

  3. 03
    Move the state

    Lock the HCP Terraform workspace so no run writes during the copy, then move its state into your own S3, Cloud Storage, Azure Blob, or OCI bucket, or into ops0-managed state.

  4. 04
    Bring the variables

    Import values from tfvars, environment variables, or JSON. Secret values are never imported automatically; reference them from your vault instead.

  5. 05
    Attach policies and approvals

    Turn on the policy packs you need and separation of duties for production projects.

  6. 06
    Run a plan-only run

    A plan with no changes shows that code, state, and the live resources line up before the first apply.

Common questions

Both run Terraform with plan review, policy checks on the plan, and approval before apply. ops0 also discovers what is running in your cloud accounts read-only, marks every resource as managed by a project or unmanaged, turns chosen resources into reviewed Terraform with imported state, and runs OpenTofu, CloudFormation, Ansible, and Kubernetes changes through the same approvals.
RelatedGoverned DeploymentsDiscoveryCoding Agent Guardrails

Start with what is running.
Move the runs after.

Connect one account read-only and see everything running in it, including what no workspace manages, before you change a single run.

Explore Discovery