Provisioning engines define desired infrastructure in code and apply those definitions to cloud resources. Terraform, OpenTofu, Pulumi, AWS CDK, and Crossplane operate at this layer.
Orchestration and governance tools control how infrastructure changes run, who can approve them, and which policies apply. Spacelift, env0, Scalr, and Qovery operate at this layer.
Most teams need one tool from each layer. Choose a provisioning engine for resource creation, then add an orchestration tool when you need shared workflows, policy enforcement, developer self-service, or multi-cloud management.
What "infrastructure automation" actually splits into
A provisioning engine defines the desired state of infrastructure and applies the resource changes needed to reach it. Terraform and OpenTofu read configuration files, compare those definitions with deployed resources, produce a change plan, and update stored state after execution. Both use a declarative model and support largely the same provider ecosystem, although their governance and features now differ. OpenTofu remains compatible with common Terraform commands and state files.
An orchestration layer governs who can run a provisioning engine, when runs occur, and which policies apply. It can add approval workflows, credential controls, and audit records around Terraform or OpenTofu operations. More advanced infrastructure automation tools also expose self-service interfaces, manage environments across clouds, and provide controlled API access for other software.
The layers solve separate parts of cloud infrastructure automation. Terraform or OpenTofu determines which resources to create, modify, or remove. An orchestration product determines whether a proposed run may proceed and how the organization manages it. You can use a provisioning engine alone for a small environment with a few trusted operators. Shared infrastructure usually benefits from an orchestration layer because access, policy enforcement, and repeatable workflows become harder to manage through configuration files and CI scripts alone.
Provisioning engines translate infrastructure definitions into cloud resources and track the resulting state. Terraform and OpenTofu use declarative configuration, Pulumi and AWS CDK use programming languages, and Crossplane exposes infrastructure through Kubernetes APIs. Each approach determines how you define, test, apply, and maintain infrastructure.
Terraform
Terraform remains the incumbent provisioning engine because its large provider ecosystem covers major clouds and many specialized services. Its declarative configuration language lets you describe a desired infrastructure state, while providers translate that configuration into API calls. Reusable modules, established integrations, and a large pool of experienced practitioners reduce the work required to adopt it.
HashiCorp's August 2023 license change introduced a governance concern for some buyers. Terraform moved from the open-source Mozilla Public License 2.0 to the Business Source License. The BSL permits free use in most situations but restricts competitive products and certain forms of commercial redistribution. Organizations building managed infrastructure services or requiring permanent open-source access may need legal review or an alternative such as OpenTofu.
Terraform best fits teams that value broad provider coverage, mature integrations, and established hiring paths. Buyers should accept HashiCorp's control over the roadmap and confirm that the BSL permits their intended use.
OpenTofu
OpenTofu offers Terraform-compatible provisioning under open governance. HashiCorp's 2023 move from MPL 2.0 to the Business Source License prompted vendors and contributors to create the fork, which the Linux Foundation adopted. A multi-organization technical committee makes project decisions publicly, so one vendor cannot unilaterally change the license.
Compatibility lets you keep familiar HCL configurations, providers, state files, and commands with limited migration work. OpenTofu also adds native state encryption, which protects state data through services such as AWS KMS or GCP KMS without requiring a separately encrypted backend. Terraform users typically depend on external storage controls or Terraform Cloud for equivalent protection.
OpenTofu remains a provisioning engine. You still need separate tooling for approvals, policy enforcement, run coordination, and developer self-service. OpenTofu fits teams that want Terraform-compatible workflows without exposure to licensing decisions controlled by a single vendor.
Pulumi
Pulumi lets you define and provision infrastructure with general-purpose languages such as TypeScript, Python, Go, C#, and Java. Rather than learning HCL, developers can use familiar functions, conditionals, classes, package managers, and IDE tooling. Pulumi also connects to many Terraform provider plugins through its compatibility bridge.
Standard language tooling gives Pulumi a concrete advantage for logic-heavy infrastructure. Typed languages can catch invalid properties and incompatible values before Pulumi calls a cloud API. Developers can also write unit tests with Jest, pytest, or Go test to verify resource properties and environment rules without deploying them. These software-style tests provide faster feedback than checks that require an infrastructure plan or live resources.
Pulumi suits teams with a strong software engineering culture and infrastructure that benefits from reusable abstractions or substantial conditional logic. Ops-focused teams may find HCL easier to review because its narrower syntax limits how infrastructure definitions can behave. Pulumi programs can accumulate the same abstraction and maintenance costs as application code, so the programming model works best when your team already applies code review, testing, and ownership practices consistently.
AWS CDK
AWS CDK suits developers who want to define AWS infrastructure in TypeScript, Python, Java, or other familiar languages. Its constructs support reusable abstractions, type checking, loops, and standard testing tools.
AWS CDK uses a two-step deployment model. It first synthesizes application code into a CloudFormation template, then CloudFormation deploys the AWS resources. As a result, CloudFormation manages deployment state and execution, while AWS CDK provides the programming model.
That dependency sets the tool's boundaries. AWS CDK supports AWS resources rather than a common model across cloud providers, and deployment speed depends on CloudFormation. Manual changes can also create drift that requires CloudFormation's separate detection features.
AWS CDK fits teams committed to AWS with no near-term multi-cloud requirement. Teams planning to manage several cloud providers would need separate tooling or substantial rewrites.
Crossplane
Crossplane turns Kubernetes into a control plane for infrastructure. Custom Resource Definitions extend the Kubernetes API so you can represent infrastructure as Kubernetes objects. Controllers then compare each declared resource with its actual state and reconcile any difference, much as Kubernetes manages workloads.
Crossplane fits GitOps workflows because tools such as Argo CD can apply infrastructure manifests and monitor them through the same API used for applications. The CNCF project profile records Crossplane's graduation in October 2025 and cites Galaxy FinX running Crossplane with GitOps and Argo CD across more than 100 Kubernetes clusters. CNCF Graduated status indicates that the project has reached the foundation's highest maturity level.
Crossplane best serves teams that already operate Kubernetes control planes and want continuous infrastructure reconciliation. Teams can expose approved infrastructure abstractions through Kubernetes APIs instead of asking users to manage each cloud resource directly.
The orchestration and governance layer
Provisioning engines define and apply infrastructure, but they provide limited controls for shared workflows. Orchestration and governance tools manage approvals, policy enforcement, access, and execution across teams and cloud providers. They give you a consistent operating layer above infrastructure code.
Spacelift
Spacelift leads the CI/CD-for-IaC category and often serves as the default orchestration layer for infrastructure code. Its control plane runs Terraform and OpenTofu alongside Pulumi, CloudFormation, Terragrunt, Ansible, and Kubernetes/Helm workloads. You can standardize approvals and execution without forcing every project onto one provisioning engine.
Stacks connect repositories to infrastructure runs. Spaces organize Stacks and apply role-based access across departments or environments. Policies use Open Policy Agent rules to inspect plans, require approvals, restrict changes, and control notifications. Private workers can keep execution inside your network when cloud-hosted runners do not meet security requirements.
Spacelift governs IaC rather than the full application lifecycle. It does not natively manage application deployments or complete preview environments with services, DNS, TLS, and seeded data as one environment. You may need separate developer-facing tooling for those workflows.
Spacelift fits platform teams that need consistent governance across several IaC tools, cloud accounts, and internal groups.
env0
env0 emphasizes fast drift detection and cost controls. Its Instant Drift Detection identifies discrepancies within minutes of connecting a cloud account and records who changed each resource and when. Time-to-live policies can destroy temporary environments after a set period, while deployment estimates and automatic tags help attribute cloud spending to specific environments.
env0 governs several infrastructure as code tools through one control plane, including Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes. Open Policy Agent policies can block risky configurations, protect environments from deletion, and enforce spending limits during deployment. Compared with Spacelift, env0 places more emphasis on cost estimation and environment expiration. Enterprises with mixed IaC tooling should consider env0 when cost allocation, drift remediation, and policy enforcement take priority over application lifecycle management.
Scalr
Scalr offers a focused HCP Terraform alternative for teams that want managed remote runs without adopting a broader deployment platform. Its Terraform-centric coverage includes Terraform, OpenTofu, and Terragrunt, while remote state, workspaces, and policy controls preserve a familiar operating model.
Scalr also limits what coding agents can execute. An agent can prepare changes through MCP, but a person must trigger the run. That restriction gives you a clear approval boundary, though it rules out autonomous infrastructure changes.
Scalr fits Terraform-only shops that want governed execution and OpenTofu support. Teams using Pulumi, CloudFormation, or Kubernetes manifests will need another orchestration tool.
Qovery
Qovery provides a platform-engineering layer that hides the provisioning engine from application developers. Spacelift, env0, and Scalr govern Terraform or OpenTofu runs, while Qovery lets you declare applications and environments without maintaining HCL workflows directly. Qovery then translates those declarations into cloud infrastructure and manages its lifecycle.
Qovery makes execution deterministic by applying declared configurations through controlled, repeatable workflows. The platform calculates the required infrastructure changes before applying them, which limits variation between manual procedures and automated actions.
Coding agents use the same governed API as other automation. You can restrict an agent to approved projects and operations instead of giving it broad cloud credentials. An agent can request an environment or deployment, while Qovery enforces the permissions and execution path behind that request.
Ephemeral environments give each branch or pull request an isolated copy of the required application environment. Qovery provisions the resources through a reusable configuration and removes them when they are no longer needed, reducing manual setup and abandoned infrastructure.
Qovery supports AWS, GCP, Azure, and Scaleway. It fits companies that want one application deployment model across several cloud providers, as well as companies leaving a managed PaaS that need more infrastructure control without asking developers to manage Terraform.
Give developers self-service without the Terraform grind
Qovery provisions infrastructure in your own cloud through governed, repeatable workflows across AWS, GCP, Azure, and Scaleway. Start in under 10 minutes.
Developer self-service across AWS, GCP, Azure, and Scaleway
How to choose: matching layers to team maturity
Choose a provisioning engine alone when one team owns infrastructure and can review every change through its existing delivery pipeline. Terraform or OpenTofu suits declarative infrastructure, Pulumi suits code-heavy logic, AWS CDK suits AWS-only environments, and Crossplane suits Kubernetes control planes.
Add an orchestration layer when two or more teams share cloud accounts, policies, or infrastructure modules. Spacelift, env0, and Scalr can centralize approvals, policy checks, state access, and managed runs across those teams.
Skip direct HCL workflows when developers need self-service environments without learning the underlying infrastructure model. PaaS migration often creates this requirement because developers expect simple deployment controls while platform engineers need cloud ownership and governance.
Coding agents require narrower permissions than human operators usually receive. Give agents access through governed APIs that constrain available actions, record changes, and execute approved workflows rather than exposing unrestricted cloud credentials.
Qovery fits when developer self-service and agent-safe execution create the main bottleneck. Its platform layer provides deterministic execution, governed API access, ephemeral environments, and coverage across AWS, GCP, Azure, and Scaleway. Teams focused mainly on policy enforcement over existing infrastructure code may prefer a dedicated IaC orchestration tool.
Frequently asked questions
What separates provisioning tools from orchestration tools?
Provisioning tools create infrastructure, while orchestration tools control how and when changes run. Qovery operates at the orchestration and platform layer. You gain policy, repeatable workflows, and developer self-service.
Do you need both layers?
Most shared production environments need provisioning and orchestration capabilities. Qovery abstracts the underlying provisioning work behind governed workflows. You avoid managing separate tools for every deployment step.
How difficult is a Terraform to OpenTofu migration?
OpenTofu preserves broad compatibility with Terraform configurations and workflows. Qovery removes this choice when you use its infrastructure abstraction. Your migration effort depends mainly on provider, module, and state compatibility.
Does Qovery replace Terraform or run on top of it?
Qovery provides a higher-level platform that manages infrastructure and application environments without requiring direct Terraform workflows. Qovery does not function as a Terraform run manager like Spacelift. You manage environments through Qovery rather than maintaining HCL pipelines.
How can coding agents change infrastructure safely?
Coding agents need authenticated APIs, scoped permissions, and deterministic execution. Qovery exposes governed API access within its platform workflows. You can limit agent actions while preserving approvals and policy controls.
Melanie leads content at Qovery. She covers platform engineering trends, Kubernetes operations, FinOps, and the tools that help engineering teams ship faster.
Next step
Give developers self-service without the Terraform grind
Qovery provisions infrastructure in your own cloud through governed, repeatable workflows across AWS, GCP, Azure, and Scaleway. Start in under 10 minutes.
