Terraform provider settings for sub-environments

A workflow environment can be configured from two places: the sub_environment_configuration block of the env0_environment resource in the env zero Terraform provider, and the env0.workflow.yaml file. Settings that exist in both do not always behave the same way.

Field reference

Field	Where the value is stored	Which deployments honor it	Which surface wins
`alias`	Not stored. Must match the key of the sub-environment under `environments` in the workflow file.	All	The workflow file defines the aliases.
`approve_plan_automatically`	Every deployment that Terraform triggers saves it on the sub-environment as its approval setting, and so does create, even when `prevent_auto_deploy` is `true`. The provider does not read it back into state.	All, as the last fallback. See How approval is resolved.	Terraform for the deployment it triggers, ahead of the workflow file. For every other deployment, its own request value when it sets one, then the workflow file when it sets `requiresApproval`, otherwise the saved setting.
`configuration`	Environment-scoped variables on the sub-environment. The provider reads them back into state, so changes made in the UI or API show as drift, except the values of sensitive variables. The API redacts those, so the provider keeps the state value and a changed secret is not detected.	All	Terraform. The workflow file has no variables section.
`workspace`	The sub-environment’s workspace name, set once when env zero creates the sub-environment.	All	Terraform over the workflow file’s `workspace`, at creation only. Changing it after creation does not change the workspace. It triggers a deployment unless `prevent_auto_deploy` is `true`.
`revision` (deprecated)	Not stored. The provider sends it as an override for a single deployment.	Deployments that Terraform triggers only.	Terraform for the deployment it triggers. The workflow file’s `revision` for every other deployment. Set `revision` in the workflow file instead.
`id`	Computed. The sub-environment’s environment ID.	n/a	n/a

How approval is resolved

For each sub-environment, a deployment resolves approval in this order: the value in the deployment request, then the workflow file’s requiresApproval, then the saved setting. These are steps 3 to 5 of the approval priority order. The provider sends approve_plan_automatically in the deployment request, so for the deployment Terraform triggers it wins over the workflow file, and env zero saves it on the sub-environment. The field defaults to true, so a block that omits it still sends “no approval required”, and that overrides a requiresApproval: true in the workflow file for that deployment. A deployment started from the UI, the API, a VCS push, or a schedule does not carry Terraform’s value. For each sub-environment it uses the value in its own request when one is set, then the workflow file’s requiresApproval when set, and otherwise the saved setting. The deploy dialog’s Approve automatically checkbox and the API’s subEnvironments.<alias>.userRequiresApproval field set a request value. VCS pushes and schedules do not.

When the workflow file sets requiresApproval, that value replaces the saved setting on the next deployment that Terraform did not trigger. Terraform state keeps showing the value you configured, because the provider does not read the saved setting back, so no drift is reported.To require approval regardless of what triggers the deployment, set both values: approve_plan_automatically = false in the Terraform block and requiresApproval: true in the workflow file. A deployment request that sets its own approval value, such as the deploy dialog’s Approve automatically checkbox, still overrides both for that deployment.

main.tf

resource "env0_environment" "workflow" {
  name        = "my-workflow"
  project_id  = "<YOUR_PROJECT_ID>"
  template_id = "<YOUR_WORKFLOW_TEMPLATE_ID>"

  sub_environment_configuration {
    alias                      = "kubernetes-cluster"
    approve_plan_automatically = false
  }
}

env0.workflow.yaml

environments:
  kubernetes-cluster:
    name: "Kubernetes Cluster"
    templateName: "eks"
    requiresApproval: true

Updates with `prevent_auto_deploy`

With prevent_auto_deploy = true, an update to the resource writes only configuration changes to env zero. The provider sends approve_plan_automatically and workspace only as part of a deployment it triggers, so Terraform records changes to them in state, but they never reach env zero. On create, approve_plan_automatically, workspace, and configuration take effect, and revision has no deployment to apply to.

Next steps

Approval policies - Require approval by policy, evaluated before the request and workflow file values.
Partial workflow deployment - Deploy or destroy a subset of the workflow graph.
Managing workflow variables - Configure variables and output passing at the template level.

GET STARTED

ENVIRONMENTS & DEPLOYMENTS

TEMPLATES & IaC TOOLS

PLATFORM CONFIGURATION

SELF-HOSTED AGENTS

CLOUD MANAGEMENT

GOVERNANCE & POLICIES

ACCESS & IDENTITY

SECURITY & COMPLIANCE

INTEGRATIONS & DEVELOPER TOOLS

BILLING & SUPPORT

Terraform provider settings for sub-environments

Field reference

How approval is resolved

Updates with `prevent_auto_deploy`

Next steps

​Field reference

​How approval is resolved

​Updates with prevent_auto_deploy

​Next steps

Field reference

How approval is resolved

Updates with `prevent_auto_deploy`

Next steps