• No underlying infrastructure setup and management - env zero takes care of the setup as opposed to other approaches, where you need to do all the setup and management yourself (for example, S3 Backend requires you to create an S3 Bucket and an optional DynamoDB Table for locking beforehand).
• Security - env zero stores the state securely and assures only you can access it.
• State consistency - Remote Backends assure that users won’t overwrite each other’s state with a locking mechanism and that they receive the most recent state on every Terraform operation
• Remote plans - By providing the Remote Backend configuration and successful login, users can run terraform plan locally, which will trigger a remote plan in env zero. The remote plan will use the shared state and variables set for the env zero environment.

• No Terraform Backend configuration when running inside env zero - You don’t have to provide any type of configuration; deploy your code as is, and env zero will automatically configure it to use the Remote Backend.
• States UI - View the current version of your current state and all previous versions.
• Correlation of Deployment to State - Identify which deployment caused a specific change to your state.
• State Access Control - Specify which environments should be able to access an environment’s state in env zero.

​

Use Remote Backend in a New Environment

• Create a new Environment
  • Check the Enable Remote State checkbox
  • Enter a Workspace Name

​

Enable Remote Backend on a workflow sub-environment

• An API key ID and secret
• A sub-environment whose template is Terraform or OpenTofu
• If the sub-environment was deployed before, the Run Tasks permission, to migrate its state. No built-in project or environment role includes it; grant it with a custom role.

curl -s -u "<API_KEY_ID>:<API_KEY_SECRET>" \
  "https://api.env0.com/environments/<WORKFLOW_ENVIRONMENT_ID>" \
  | jq -r '.latestDeploymentLog.workflowFile.environments["<ALIAS>"].environmentId'

curl -X PUT "https://api.env0.com/environments/<SUB_ENVIRONMENT_ID>" \
  -u "<API_KEY_ID>:<API_KEY_SECRET>" \
  -H "Content-Type: application/json" \
  -d '{"isRemoteBackend": true}'

curl -X POST "https://api.env0.com/environments/<SUB_ENVIRONMENT_ID>/deployments" \
  -u "<API_KEY_ID>:<API_KEY_SECRET>" \
  -H "Content-Type: application/json" \
  -d '{"deploymentType": "task", "taskPayload": "terraform state list", "configurationChanges": [{"name": "TF_CLI_ARGS_init", "value": "-migrate-state -force-copy", "type": 0, "scope": "DEPLOYMENT"}]}'

curl -s -u "<API_KEY_ID>:<API_KEY_SECRET>" \
  "https://api.env0.com/configuration?environmentId=<SUB_ENVIRONMENT_ID>&organizationId=<ORGANIZATION_ID>" \
  | jq -r '.[] | select(.name == "TF_CLI_ARGS_init") | .id'

curl -X DELETE "https://api.env0.com/configuration/<VARIABLE_ID>" \
  -u "<API_KEY_ID>:<API_KEY_SECRET>"

• Redeploying the workflow doesn’t change the setting.
• If another Remote Backend environment in the organization uses the same workspace name, the call returns 409 with Workspace name "<WORKSPACE_NAME>" is taken by remote backend environment. You can’t change a sub-environment’s workspace name after it’s created, so give each sub-environment its own workspace in the workflow file before it’s first deployed.

​

Viewing & Downloading State Versions

​

Release a Locked State

​

How to release a locked state

• Navigate to the STATES tab for the affected environment.
• If the workspace is locked, you’ll see a warning along with a Force Release button.
• Click the Force Release button to clear the lock

​

Using the Remote Backend Locally

​

Next steps

• Self-Hosted Remote State - Store state in your own cloud storage bucket.
• Running remote plan - Trigger Terraform plans remotely via env zero.
• State Migration - Migrate existing state into the env zero remote backend.