Skip to main content
To set up a Workflow, follow this simple guide: env zero relies on a file named env0.workflow.yaml (or env0.workflow.yml) to describe the dependencies and configuration of the sub-environments in your workflow. For the complete schema reference, see Workflow File Reference.

​
Approval Priority Order

When multiple approval settings exist, approvals are evaluated in the following priority:
  1. ENV0_REQUIRES_APPROVAL environment variable
  2. Approval policy (always evaluated if defined)
  3. Value from the UI or API request
  4. Value from the workflow requiresApproval field

​
Example Configuration

env0.workflow.yaml
environments:
  vpc:
    name: "VPC and Network"
    templateName: "VPC"

  db:
    name: "Database"
    templateName: "DB"
    requiresApproval: true
    needs:
      - vpc

  eks:
    name: "EKS Cluster"
    templateName: "EKS"
    needs:
      - vpc

  billing-service:
    name: "Billing Service"
    vcs:
      type: terraform
      terraformVersion: "1.5.7"
      repository: "https://github.com/env0/templates"
      path: "aws/hello-world"
      githubInstallationId: 123456789
    disabled: ${DISABLE_BILLING_SERVICE}
    needs:
      - db
      - eks

  config-service:
    name: "Configuration Service"
    templateName: "Configuration Service"
    revision: feature-branch
    disabled: ${DISABLE_CONFIG_SERVICE}
    needs:
      - db
      - eks

​
Using Environment Variables in Workflow Fields

You can use ${...} syntax to interpolate environment variables into workflow fields. In the example above:
  • DISABLE_BILLING_SERVICE controls whether the billing-service environment is disabled.
  • DISABLE_CONFIG_SERVICE controls whether the config-service environment is disabled.
When these variables are set to true (for example, in your environment or via env zero variables), the corresponding sub-environment is skipped during deployment.

​
Environment Removal Strategy

By default, removing an environment from the workflow file leaves it detached but not destroyed. To automatically run a “destroy” process on environments that were removed from the workflow file, add environmentRemovalStrategy: destroy to your settings section. For example:
env0.workflow.yaml
settings:
  environmentRemovalStrategy: destroy

environments:
  vpc:
    name: "VPC and Network"
    templateName: "VPC"
ValueBehavior
destroyAutomatically destroy removed environments after deploying all environments
detachDetach removed environments without destroying them (default)
Template NamingWhile not enforced, use unique template names. Otherwise, the Workflow will randomly choose one of the templates without considering permission restrictions.

​
Creating a Workflow in the UI

  1. Create a new template and select env zero Workflow as the Template Type:
In the VCS step, fill in your VCS details and the directory that contains your env0.workflow.yaml (or env0.workflow.yaml**) file:
  1. Create an Environment based on the Workflow template.
    You can choose any of the workflow environments from the dropdown menu in the top right corner.
After choosing one of the workflow sub-environments, you can modify its variables, workspace, revision and auto-approval settings.
Remote BackendThe Remote Backend option will be applied to Terraform templates only. For further documentation about remote backend, follow this guide.
Overrides NoteThe values you set here for workspace and revision will override the ones you’ve defined in the workflow file for the corresponding environment.If you would like to set the whole workflow to the same workspace name value, you can do so by setting the workflow workspace name, and leaving the sub environments blank.Note that since Terragrunt uses a working directory instead of workspace name, the workspace name override won’t apply to Terragrunt template type.When marking the workflow as remote backend, you must provide unique names for each of the sub environments workspaces.
  1. Deploy