Snap CD vs HCP Terraform (Terraform Cloud)

HCP Terraform (formerly Terraform Cloud) is HashiCorp's managed platform for running Terraform at scale. It bundles state management, remote execution, policy enforcement, and a private registry into a single SaaS offering. It's the most widely adopted Terraform orchestration platform, and for good reason — it works well for teams that want a fully managed, opinionated workflow.

Snap CD takes a different approach. It separates orchestration from execution, stays agnostic about state backends, and focuses on the cross-state dependency problem that grows as infrastructure scales. This guide walks through the key differences to help you decide which fits your team.

Architecture

HCP Terraform

HCP Terraform runs terraform plan and terraform apply on HashiCorp-managed infrastructure. Your Terraform code is uploaded to their platform, and execution happens in their environment. This is convenient — no runners to manage, no compute to provision — but it means:

• Credentials leave your network. Cloud provider credentials (AWS keys, Azure service principals, GCP service accounts) must be configured in HCP Terraform so its workers can authenticate. Dynamic credentials via OIDC federation mitigate this, but not all providers support it.
• Network access requires configuration. If your Terraform code needs to reach private endpoints (a database, an internal API, a private registry), you need HCP Terraform agents — self-hosted workers that run inside your network. At that point you're managing infrastructure to run your infrastructure tool.
• Compliance constraints. Some organisations can't send infrastructure code or credentials to a third-party cloud, full stop. HCP Terraform's answer is Terraform Enterprise — a self-hosted version with a significant price tag.

Snap CD

Snap CD separates orchestration from execution by design. The snapcd.io Server handles configuration, dependency tracking, and logging. Self-hosted Runners handle the actual terraform plan and terraform apply execution.

• Credentials stay where you put them. Runners run in your environment — a Kubernetes pod, a VM, a container — with whatever credentials you assign them. Nothing leaves your network.
• Network access is natural. Runners connect outbound to snapcd.io via authenticated WebSocket. They already have access to your private endpoints because they run inside your network.
• No separate "enterprise" tier for self-hosting. The Runner is source-available. The Server itself is available for self-hosting under the source-available license.

State management

HCP Terraform provides managed remote state storage. This is one of its strongest features — you don't need to set up S3 buckets, DynamoDB tables, or Azure storage accounts for state. It handles locking, versioning, and encryption out of the box.

Snap CD does not manage state. Your Terraform code uses whatever backend you've already configured — S3, Azure Blob Storage, GCS, Consul, or anything else Terraform supports. If you've already invested in a state management strategy, Snap CD doesn't ask you to change it.

This is a trade-off. HCP Terraform's managed state is genuinely convenient for greenfield projects. But if you already have state backends in place, or you need state to stay in a specific region or account for compliance reasons, Snap CD's agnostic approach avoids the migration.

Cross-workspace dependencies

This is where the two tools diverge most sharply.

HCP Terraform: run triggers

HCP Terraform has run triggers — you can configure workspace B to trigger a run when workspace A completes. This gets the sequencing right, but it doesn't handle the data flow:

• Run triggers fire the downstream workspace, but they don't pass outputs. Workspace B still needs to use terraform_remote_state or some other mechanism to read workspace A's outputs.
• terraform_remote_state requires workspace B to know the backend configuration of workspace A. This creates tight coupling between workspaces.
• There's no automatic re-plan when upstream outputs change. If workspace A's VPC ID changes, workspace B gets triggered, but it has to discover the change through the remote state data source during its own plan.

Snap CD: declarative dependency wiring

Snap CD makes cross-state dependencies a first-class concept. You declare them with snapcd_module_input_from_output resources:

resource "snapcd_module_input_from_output" "vpc_id" {
  module_id        = snapcd_module.compute.id
  input_kind       = "Param"
  name             = "vpc_id"
  output_module_id = snapcd_module.networking.id
  output_name      = "vpc_id"
}

With this in place:

• Snap CD knows the full dependency graph and enforces correct apply order.
• When networking's vpc_id output changes, compute automatically re-plans with the new value — no terraform_remote_state needed.
• Your Terraform code uses plain variable blocks. No backend configuration leaks between modules.
• The dependency graph is visible and auditable, not buried in workspace settings.

This is the fundamental difference. HCP Terraform treats cross-workspace dependencies as a notification mechanism. Snap CD treats them as a data pipeline.

Policy enforcement

HCP Terraform

HCP Terraform has Sentinel (HashiCorp's own policy-as-code language) and OPA (Open Policy Agent) integration. These let you write policies like "no public S3 buckets" or "all resources must have tags" and enforce them before apply. Sentinel in particular is mature and well-documented.

The trade-off: Sentinel is proprietary to HashiCorp. If you leave HCP Terraform, your Sentinel policies don't come with you. OPA is open, but the integration is only available on the Plus tier.

Snap CD

Snap CD takes a different approach to guardrails:

• Approval gates require a configurable number of human approvals before an apply proceeds. You can review the plan, verify what's changing, and approve or reject.
• RBAC controls who can trigger plans, approve applies, and manage configuration — scoped to the Stack, Namespace, Module, or Runner level.
• Runner isolation ensures that a Module can only execute on Runners you've explicitly allowed, so the blast radius is bounded by the Runner's credentials.

Snap CD doesn't have a built-in policy-as-code engine. If you need automated policy checks (tag enforcement, security scanning), you'd integrate them into your Terraform code (e.g., tflint, checkov, or OPA with conftest) or into the runner's workflow. The approval step gives humans the final say.

Pricing

The pricing models are fundamentally different:

• HCP Terraform charges per resource under management. As your infrastructure grows, the bill grows proportionally — even if you're not making changes. The free tier covers 500 resources; after that, pricing scales with resource count.
• Snap CD charges per Module. A Module with 5 resources costs the same as a Module with 500 resources. You pay for the units of deployment you manage, not the resources inside them.

For large infrastructure (thousands of resources across many states), this difference is significant. A team managing 5,000 resources across 20 modules would see very different bills.

OpenTofu support

HCP Terraform runs Terraform — HashiCorp's proprietary fork since the BSL license change. It does not support OpenTofu.

Snap CD supports both Terraform and OpenTofu. Runners execute whatever binary is available — terraform or tofu. If you're evaluating a migration to OpenTofu, or you want to use OpenTofu for new projects while maintaining existing Terraform code, Snap CD doesn't force a choice.

Self-hosting

HCP Terraform's self-hosted option is Terraform Enterprise. It provides the same features as the cloud version but runs on your infrastructure. It requires a separate license, and pricing is typically enterprise-contract — not publicly listed, but significantly more expensive than the SaaS offering.

Snap CD's runner is self-hosted by default — that's the standard architecture, not an upsell. The server component is available under a source-available license for organisations that need to self-host the entire stack. There is no separate "enterprise" product with different features.

Private registry

One area where HCP Terraform has a clear advantage is its private module registry. Teams can publish versioned Terraform modules internally and consume them across workspaces. This is a polished, well-integrated feature.

Snap CD doesn't include a private registry. You'd use Git repositories (with tags for versioning), a self-hosted registry, or the public Terraform registry. For most teams this works fine, but if a managed private registry is important to your workflow, it's worth noting.

Comparison table

When to choose HCP Terraform

• You want fully managed state storage and don't want to operate state backends.
• You need Sentinel for automated policy enforcement and are comfortable with the vendor lock-in.
• Your team is small, resource count is low, and the free tier or lower pricing tiers work for you.
• A private module registry is a core part of your workflow.

When to choose Snap CD

• You have cross-state dependencies and want them managed declaratively, not through triggers and remote state.
• Your credentials must stay in your network, and you don't want to manage HCP Terraform agents.
• You're managing large infrastructure where per-resource pricing becomes expensive.
• You want to use OpenTofu, or keep the option open.
• You want self-hosting without an enterprise contract.

Summary

HCP Terraform is a mature, well-integrated platform with strong managed state and policy features. Snap CD focuses on the dependency orchestration problem — wiring outputs to inputs across states — and keeps execution in your environment by design. The right choice depends on whether your primary challenge is managed infrastructure operations (HCP Terraform) or cross-state coordination at scale (Snap CD).

See also

• Modular Deployments — deep dive into Snap CD's Module, input, and dependency system
• Self-Hosted Terraform Runners with Credential Isolation — how Runners keep credentials in your network
• A Permission System Built for Infrastructure — granular RBAC across the Stack/Namespace/Module hierarchy
• Non-invasive Orchestration — how Snap CD runs standard Terraform commands without wrappers