env zero CLI Tool

Install the env zero CLI to deploy, inspect, and manage environments from your terminal or CI, with JSON output and stable exit codes for scripts.

The env zero CLI is a single binary for managing your environments and deployments from the terminal or CI. It reads environments, deployments, plans, projects, and templates, and acts on them: create, deploy, destroy, archive, and approve, cancel, or abort a deployment. Output is JSON on stdout, errors go to stderr, and exit codes are stable, so it fits cleanly into scripts.

The old CLI, the Node package @env0/cli version 1.x, is deprecated. The current CLI is a single binary and is the recommended way to use env zero from the terminal. Pin @env0/cli@^1 to stay on the old one while you migrate.

Prerequisites

• An env zero account with appropriate permissions
• A cloud credential assigned to the project you deploy into, so deployments can authenticate to your cloud provider

Step 1: Install

Homebrew

brew install env0/tap/env0

Homebrew covers macOS and Linux. The npm package installs the same binary, where version 2 is the current CLI. Binaries are also on the latest release. Verify with env0 version.

Step 2: Sign in

On your own machine, sign in through the browser:

env0 login

This confirms a short code, signs you in, and lets you pick a default organization and project. The session is stored in your OS keychain when available, so later commands need no flags. Use --no-browser to print the URL instead, and env0 status or env0 logout to check or clear the session.

From CI

Browser login needs a terminal, so automation uses an API key instead (any env zero key works). Create one under Organization Settings → API Keys, or from a signed-in CLI:

env0 api-key create --name ci-runner --role User --project-role <project-id>=Deployer --yes -o compact

--role is required. Use env0 personal-api-key create --name <name> --yes instead for a key that carries your own permissions. See API keys for which to choose.

Set the returned apiKeyId and apiKeySecret as environment variables:

export ENV0_API_KEY_ID=<api-key-id>
export ENV0_API_KEY_SECRET=<api-key-secret>

Copy the API key secret when you create it. It is not shown again.

You can also pass --api-key-id and --api-key-secret on a single command.

Step 3: Deploy

environment create provisions a new environment and starts its first deployment. environment deploy runs a new deployment on one that already exists. Add --wait to either to block until it finishes and take the exit code from its result:

env0 environment create --name my-environment --project <project-id> --template <template-id> --wait
env0 environment deploy <environment-id> --wait

To create from a git repository instead, use --repository with --type (for example terraform) and --organization. While a deploy waits, step logs (git clone, then plan and apply for Terraform or OpenTofu) stream to stderr. Add --ttl 2h to create to have env zero destroy the environment after two hours.

Actions take an environment id, not a name. Resolve a name to an id with:

env0 environment list --name my-environment --project <project-id> -o compact | jq -r '.data[0].id'

Step 4: Approvals

When an environment requires approval, its deployment pauses. Find the deployment id (the deploy output carries it at .data.id, or list the latest one):

env0 deployment list --environment <environment-id> --limit 1 -o compact | jq -r '.data[0].id'

Then act on it:

approve

env0 deployment approve <deployment-id>

Set the gate per run with --requires-approval on environment deploy or destroy, and stop a running deployment with env0 deployment abort <deployment-id>.

Step 5: Inspect, destroy, and archive

Read commands print JSON for jq. Use -o compact for one line or -o table for a readable view:

env0 environment list --project <project-id>
env0 context <environment-id>
env0 deployment logs <deployment-id>

env0 context returns an environment’s state, recent deployments, and a drift or failure summary in one call, so it is a fast way to see why something failed. Every command and flag is listed in the command reference.

Destroy an environment when you no longer need it. This deletes real infrastructure, so it requires confirmation:

env0 environment destroy <environment-id> --yes

Archiving is the other way to clear an environment. It tells env zero to stop tracking the environment without running a deployment, so its cloud resources are left alone:

env0 environment archive <environment-id>

Use it when you want to keep the infrastructure, and when Destroy is not available because the environment has never deployed. See mark an environment as inactive for what changes. To bring an archived environment back, redeploy it with env0 environment deploy <environment-id>.

Projects archive the same way, with one difference: archiving a project cannot be undone.

env0 project archive <project-id>

Use the CLI with AI agents

The CLI is built for agents and scripts, not only people: JSON on stdout, errors on stderr, stable exit codes, and env0 context for one-request diagnosis. In an agent or CI context, authenticate with the ENV0_API_KEY_ID and ENV0_API_KEY_SECRET environment variables rather than browser login.

Install the skill

env0 skill install writes a usage guide into your coding agent’s config, so it knows the commands, flags, and output without you explaining them:

env0 skill install

It installs for Claude Code by default. Use --agent cursor, --agent codex, or --agent copilot for others, --global to install for your user account instead of the project, or --path for a specific file. env0 skill show prints the guide and env0 skill uninstall removes it. The same guide ships as an asset on every release, so you can download it without the CLI from the latest release.

Migration from v1

The old CLI was the Node package @env0/cli version 1.x. The current CLI covers the same actions and adds a full read and diagnosis surface, but it is not a drop-in replacement: it targets environments by id, renames two environment variables, and prints JSON by default instead of streaming logs. Pin the old one while you migrate:

npm install -g @env0/cli@^1

Install and authentication

v1	Current CLI
npm install -g @env0/cli	brew install env0/tap/env0 or npm install -g @env0/cli@2
env0 configure	env0 login, then env0 project use <project-id>
ENV0_API_KEY	ENV0_API_KEY_ID
ENV0_API_SECRET	ENV0_API_KEY_SECRET

ENV0_ORGANIZATION_ID, ENV0_PROJECT_ID, and ENV0_API_URL are unchanged. ENV0_ENVIRONMENT_NAME and ENV0_BLUEPRINT_ID are no longer read.

Commands

v1	Current CLI
env0 deploy (existing environment)	env0 environment deploy <id>
env0 deploy (first run, creates it)	env0 environment create --template <id> (or --repository)
env0 destroy	env0 environment destroy <id> --yes
env0 approve	env0 deployment approve <id>
env0 cancel	env0 deployment cancel <id>

Flags

Legacy flags map across, though some now belong to a specific command:

• environment deploy: -v to --var, -q to --secret, -u to --tf-var, -r to --revision, -t to a repeatable --target, -a to --requires-approval
• environment destroy: -a to --requires-approval, -z to --skip-state-refresh, plus --checkout-updated-code
• environment create: -w to --workspace-name (set once at creation, cannot change later), plus the same variable, --revision, and --requires-approval flags as deploy

The old CLI acted by name and blocked while streaming logs to stdout. The current CLI acts by id and returns the started deployment right away. Add --wait to block and stream logs to stderr, or run env0 deployment logs <id> --follow to stream them to stdout.

Next steps

• Deploy a workflow from the CLI, with a different branch and variables per sub-environment
• Manage API keys for CI and other automation
• Troubleshoot CLI errors when a command fails or returns unexpected results