vs. Terraform automation
How Facets differs from Terraform automation tools like env0 and Terraform Enterprise: a typed abstraction over Terraform, not a faster way to run the Terraform you still write by hand.
Terraform automation tools like Terraform Enterprise and env0 made running Terraform safer: remote state, plan approvals, policy-as-code, pipelines. That solved execution. It did not change the fact that someone still has to write and maintain all the Terraform, and that every team touching infrastructure has to think in it.
Facets works one level up. It is a typed, declarative abstraction over Terraform: platform teams define how infrastructure is built once, as versioned modules with guardrails, and everyone else, developers and AI agents, declares what they need. Facets generates the Terraform from those same modules.
Automating a workflow is not self-service
Remote state, plan approvals, and policy-as-code are table stakes now. Pipeline orchestration runs your Terraform for you, but the harder problems sit below it:
- Collaborating on a single Terraform project without teams stepping on each other.
- Managing dependencies across Terraform projects.
- Keeping environments from drifting apart.
- Terraform sprawl: modules copied, tweaked, and forgotten across teams.
- "Self-service" that still expects product teams to write or wire Terraform modules.
These persist because everything stays at the same low level of abstraction. Platform engineers own the how, and product teams get dragged into it anyway: every environment, every service, every change means a human stitching Terraform together. You can automate the workflow, but if every team still has to think in Terraform, debug modules, and manage state, it is not self-service. It is delegation with better tooling.
A higher-level abstraction over Terraform
Facets puts a typed, declarative model over Terraform:
- Platform teams define how it is built, using typed, versioned modules.
- Product teams (developers, app teams) define what they need: a database, a service, a cluster.
- Facets generates the Terraform to provision it, using the same modules the platform team wrote.
It is not a workflow engine. It is an abstraction layer that makes safe, scalable self-service possible.
What that changes
Collaboration without collisions
Workflow automation tools do not stop teams from stepping on each other. With Facets:
- Project-specific Terraform is replaced by declarative Blueprints, so each environment has one clear source of truth.
- Every module invocation is isolated by design: teams change infrastructure without risking downstream breakage, and dependencies are still respected.
- Selective releases let teams promote changes module by module, deploying independently across teams and environments.
Self-service for developers
Other platforms offer templates, but still expect developers to write or understand Terraform. With Facets:
- Developers choose Intents ("web service", "database"), not low-level resources or IaC.
- Infrastructure is provisioned with your policies, constraints, and best practices already enforced.
- No Terraform knowledge required: platform teams define the how, so developers focus on the what.
Governance by design
Most tools layer policy on top of Terraform. Facets builds it into the model. With Facets:
- Platform teams set standards at the module level, so every provisioned resource is compliant by default.
- Inputs are typed, constrained, and validated, catching errors before they run.
- Drift cannot sneak in, because changes only happen through approved Blueprints and workflows.
Facets does not replace Terraform expertise; it makes it scale. Your team writes a module once, and every other team reuses it safely.
Facets vs. Terraform platforms
| # | Challenge | Facets | env0 | TFE (Terraform Enterprise) |
|---|---|---|---|---|
| 1 | Writing modular IaC with the right abstraction | Yes: type-safe module outputs, abstraction boundaries enforced by the platform | No: up to teams to design | No: up to teams to design |
| 2 | State management and automated execution | Yes: built-in orchestration, remote state, retries, drift detection | Yes | Yes |
| 3 | Isolation across environments | Yes: environments are first-class with overrides and policies | Yes | Yes |
| 4 | Rollout from lower to higher environments | Yes: native environment promotion workflows | Partial: manual or pipeline-based | Partial: requires scripting |
| 5 | Isolation between logical resources to enable collaboration | Yes: dependency graph, per-resource visibility, and RBAC | Partial: via modules and repos | Partial: via workspace structure |
| 6 | A well-defined dev workflow for IaC developers | Yes: versioned automation, testing flow, enforced interfaces | Partial: VCS and hooks | Yes: VCS, Sentinel policies |
| 7 | Self-service for product teams with IaC safeguards | Yes: product teams define needs via UI, CLI, or an AI agent; the platform enforces how via typed automation | No: product teams must write IaC | No: requires IaC and Sentinel |
| 8 | No need for project-specific automation | Yes: IaC is generated from high-level Blueprint Intents | No: per-project pipelines required | No: config and state per project |
| 9 | A higher-level abstraction on top of Terraform | Yes: typed modules, structured inputs and outputs, architectural modeling | No | No |
The shift
Terraform automation tools run your Terraform faster, safer, and in sequence. They still expect every team to write, reuse, and wire modules on their own. Facets flips that:
- Platform teams define how infrastructure is built once, as typed, versioned modules with guardrails.
- Developers and agents declare what they need, and Facets generates the Terraform.
Infrastructure scales like code: safe reuse, strict contracts, no duplication. Platform engineers ship modules; everyone else consumes them, with no tickets, no drift, and no guesswork.
How Facets works
How a requirement becomes a deployment in Facets, and how the Kubernetes-based control plane orchestrates it, whether driven by a person, the Praxis CLI, or a Praxis agent.
Core concepts
The canonical definitions of the Facets model, in the order you meet them: Project Type, Module (Intent, Flavor, Output type), Project, Environment, Blueprint, and Resource.