Env0 Integration
💡 NOTE: For the latest details and examples, see the Overmind Env0 plugin repository on GitHub: overmindtech/env0-plugin and the Env0 plugin documentation at Env0 Plugins Overview.
The Overmind Env0 plugin lets you connect your Env0 Terraform deployments directly to Overmind. It:
- Submits Terraform plans from Env0 to Overmind for blast radius and risk analysis
- Tracks change lifecycle, marking when a deployment starts and finishes
- Links changes back to Env0, so every change in Overmind has a ticket link to the corresponding Env0 deployment
- Posts simulation results to GitHub PRs or GitLab MRs for visibility during code review
How It Works​
The Env0 plugin runs as a standard Env0 version: 2 plugin defined in your env0.yaml:
- Plugin installation – Env0 clones the public plugin repository and executes it as a Bash-based plugin.
- Overmind CLI install – The plugin downloads and installs the latest Overmind CLI and GitHub CLI (for GitHub support) into a writable directory on the PATH. GitLab support uses
curlwhich is typically available on most systems. - Authentication – The
api_keyinput is exported asOVERMIND_API_KEYso the CLI can authenticate. - Action execution – Based on the
actioninput, the plugin runs one of:submit-plan: Uses the Env0-provided$ENV0_TF_PLAN_JSONto submit a Terraform plan to Overmindstart-change: Marks the beginning of a change in Overmindend-change: Marks the completion of a change in Overmindwait-for-simulation: Retrieves Overmind simulation results as Markdown and (whenpost_comment=true) posts them to the GitHub PR or GitLab MR
- Ticket link – For all actions, the plugin builds a ticket link back to the Env0 deployment using Env0 environment variables (
ENV0_PROJECT_ID,ENV0_ENVIRONMENT_ID,ENV0_DEPLOYMENT_LOG_ID,ENV0_ORGANIZATION_ID). This ticket link is attached to the Overmind change so you can always trace back to the original Env0 run.
Requirements​
Before configuring the integration, ensure:
- Overmind account with an API key that has the following scopes:
account:readchanges:writeconfig:writerequest:receivesources:readsource:write
- Env0 environment variables are available at runtime (Env0 sets these automatically for Terraform runs):
ENV0_PROJECT_IDENV0_ENVIRONMENT_IDENV0_DEPLOYMENT_LOG_IDENV0_ORGANIZATION_IDENV0_TF_PLAN_JSON– required for thesubmit-planactionENV0_PR_NUMBER– required whenwait-for-simulationposts comments (i.e. running against a PR/MR)ENV0_PR_SOURCE_REPOSITORY– required whenwait-for-simulationposts comments (used to detect GitHub vs GitLab)
- Terraform plan JSON – Env0 must be configured to produce a JSON plan (Env0 normally populates
ENV0_TF_PLAN_JSONafter aterraformPlanstep). - GitHub authentication – When
wait-for-simulationposts to GitHub, setGH_TOKEN(see Creating a GH_TOKEN). - GitLab authentication – When
wait-for-simulationposts to GitLab, setGITLAB_TOKEN(see Creating a GITLAB_TOKEN).
Store your Overmind API key in Env0 as a secure environment variable (for example OVERMIND_API_KEY) and pass it to the plugin via the api_key input.
Plugin Inputs​
The Env0 plugin exposes the following inputs:
| Input | Description | Required |
|---|---|---|
action | The action to perform. Must be one of: submit-plan, start-change, end-change, wait-for-simulation. | Yes |
api_key | Overmind API key used for authentication. Must have scopes: account:read, changes:write, config:write, request:receive, sources:read, source:write. | Yes |
tags | Comma-separated key=value tags to attach to the change (only used with submit-plan). | No |
post_comment | Whether wait-for-simulation should post the Overmind markdown to GitHub PR or GitLab MR. Defaults to true when running against a PR/MR, otherwise false. When true, comment_provider must be set. | No |
comment_provider | Where wait-for-simulation should post comments when post_comment=true. Must be one of: github, gitlab. | No |
on_failure | Behavior when the plugin step errors. fail (default) fails the step and blocks the deployment; pass allows the deployment to continue even if this step errors. | No |
Tags are useful for categorisation, for example:
environment=productionteam=platformservice=billing
Basic Setup​
Add the plugin to your env0.yaml and reference the public repository:
version: 2
deploy:
steps:
terraformPlan:
after:
- name: Submit Plan to Overmind
use: https://github.com/overmindtech/env0-plugin
inputs:
action: submit-plan
api_key: ${OVERMIND_API_KEY}
In this example:
- Env0 runs your normal
terraformPlanstep. - After the plan completes, the plugin:
- Uses
ENV0_TF_PLAN_JSONto submit the plan to Overmind. - Attaches Env0 deployment details as a ticket link.
- Creates or updates a Change in Overmind with blast radius and risk analysis.
- Uses
You can optionally attach tags to the change:
version: 2
deploy:
steps:
terraformPlan:
after:
- name: Submit Plan to Overmind
use: https://github.com/overmindtech/env0-plugin
inputs:
action: submit-plan
api_key: ${OVERMIND_API_KEY}
tags: environment=production,team=platform
Tracking Change Lifecycle​
To get full before/after snapshots and lifecycle tracking in Overmind, add the start-change and end-change actions around your terraformApply step.
Mark Change Started (before terraformApply)​
Configure a before hook on terraformApply:
version: 2
deploy:
steps:
terraformApply:
before:
- name: Mark Change Started
use: https://github.com/overmindtech/env0-plugin
inputs:
action: start-change
api_key: ${OVERMIND_API_KEY}
This will:
- Look up the relevant Change in Overmind (typically created during
submit-plan). - Mark it as started, capturing a snapshot of current infrastructure state.
Mark Change Finished (after terraformApply)​
Configure an after hook on terraformApply:
version: 2
deploy:
steps:
terraformApply:
after:
- name: Mark Change Finished
use: https://github.com/overmindtech/env0-plugin
inputs:
action: end-change
api_key: ${OVERMIND_API_KEY}
This will:
- Mark the Change as completed in Overmind.
- Capture a post-deployment snapshot to understand exactly what changed.
- Keep the Env0 deployment ticket link associated with the Change for easy navigation.
Wait for Simulation​
The wait-for-simulation action fetches the latest Overmind simulation summary for the current Env0 deployment and optionally comments on the matching GitHub pull request or GitLab merge request.
By default the plugin posts comments whenever the deployment runs in the context of a PR/MR. Set post_comment: false to skip commenting. When post_comment=true, you must set comment_provider to github or gitlab.
version: 2
deploy:
steps:
terraformPlan:
after:
- name: Post Overmind Simulation
use: https://github.com/overmindtech/env0-plugin
inputs:
action: wait-for-simulation
api_key: ${OVERMIND_API_KEY}
post_comment: false # optional override
To post a comment to a GitHub PR:
version: 2
deploy:
steps:
terraformPlan:
after:
- name: Post Overmind Simulation (GitHub)
use: https://github.com/overmindtech/env0-plugin
inputs:
action: wait-for-simulation
api_key: ${OVERMIND_API_KEY}
post_comment: true
comment_provider: github
To post a comment to a GitLab MR:
version: 2
deploy:
steps:
terraformPlan:
after:
- name: Post Overmind Simulation (GitLab)
use: https://github.com/overmindtech/env0-plugin
inputs:
action: wait-for-simulation
api_key: ${OVERMIND_API_KEY}
post_comment: true
comment_provider: gitlab
Fail-safe Mode​
By default, if the plugin step fails (e.g. Overmind API error, missing env var, network issue), Env0 treats the step as failed and can block the deployment. To allow the deployment to continue even when this step errors, set on_failure: pass:
- name: Submit Plan to Overmind
use: https://github.com/overmindtech/env0-plugin
inputs:
action: submit-plan
api_key: ${OVERMIND_API_KEY}
on_failure: pass # deployment continues even if this step fails
Use on_failure: pass when the Overmind integration is optional and you do not want plugin failures to block deployments.
Complete Example​
Here is a complete env0.yaml example that uses all actions:
version: 2
deploy:
steps:
terraformPlan:
after:
- name: Submit Plan to Overmind
use: https://github.com/overmindtech/env0-plugin
inputs:
action: submit-plan
api_key: ${OVERMIND_API_KEY}
tags: environment=production,team=platform
terraformApply:
before:
- name: Mark Change Started
use: https://github.com/overmindtech/env0-plugin
inputs:
action: start-change
api_key: ${OVERMIND_API_KEY}
after:
- name: Mark Change Finished
use: https://github.com/overmindtech/env0-plugin
inputs:
action: end-change
api_key: ${OVERMIND_API_KEY}
- name: Post Overmind Simulation
use: https://github.com/overmindtech/env0-plugin
inputs:
action: wait-for-simulation
api_key: ${OVERMIND_API_KEY}
post_comment: true
comment_provider: github
With this configuration:
- Every Env0 plan is sent to Overmind for blast radius and risk analysis.
- Every Env0 apply is tracked from start to finish in Overmind.
- Each Change in Overmind includes a ticket link back to the Env0 deployment for full traceability.
- Simulation results are posted as comments on the GitHub PR for easy review.
Creating a GH_TOKEN​
The wait-for-simulation action calls gh pr comment for GitHub repositories, which requires a GitHub personal access token. To create one:
- Sign in to GitHub and open https://github.com/settings/tokens/new (or the fine-grained token wizard).
- Choose Classic token, set an expiry that matches your security policy, and select the repo scope (read/write is needed to comment on PRs).
- Generate the token and copy it immediately — GitHub will not show it again.
- Store the token securely in Env0 (for example as an environment variable or secret) and expose it to the plugin as
GH_TOKEN.
Creating a GITLAB_TOKEN​
The wait-for-simulation action uses the GitLab API to post comments on merge requests for GitLab repositories. To create a GitLab personal access token:
- Sign in to GitLab and navigate to your user settings (or group/project settings for project/group tokens).
- Go to Access Tokens (or Preferences > Access Tokens for user tokens).
- Create a new token with the
apiscope (read/write is needed to comment on merge requests). - Generate the token and copy it immediately — GitLab will not show it again.
- Store the token securely in Env0 (for example as an environment variable or secret) and expose it to the plugin as
GITLAB_TOKEN.
When post_comment=true, you must set comment_provider to github or gitlab.
Troubleshooting​
If the plugin does not behave as expected, check the following:
- Env0 plugin logs – Env0 shows plugin execution logs in the deployment details; look for Overmind-related errors.
- API key scopes – Ensure the API key used in
api_keyhas all required scopes. - Environment variables – Verify that Env0 is setting
ENV0_TF_PLAN_JSON(forsubmit-plan) and otherENV0_*variables for your deployment. Forwait-for-simulation, ensureENV0_PR_NUMBERandENV0_PR_SOURCE_REPOSITORYare available when posting comments. - Authentication tokens – When using
wait-for-simulationwithpost_comment=true, ensureGH_TOKEN(for GitHub) orGITLAB_TOKEN(for GitLab) is set in your Env0 environment. - Plugin path – The plugin uses
ENV0_PLUGIN_PATH(as described in the Env0 plugin docs) to locate its files; ensure you are not overriding this in your environment.
For more advanced usage patterns or updates to the plugin behaviour, see the GitHub repository: https://github.com/overmindtech/env0-plugin.