Logo

CLI Guide

Environment Management

Environments isolate variables across the lifecycle of an app — typically development, staging, and production. EnvVault also supports arbitrary custom environments such as qa, uat, or per-PR previews.

Built-in vs Custom Environments

Built-in

development, staging, and production are always available. The CLI defaults to development when no environment is specified.

Custom

Any string is valid. A custom environment is auto-created on the first env set or secrets set targeting it. Useful for ephemeral preview environments (pr-1234) or customer-specific configurations.

Selecting an Environment

Resolution order, highest priority first:

  1. The -e / --env flag passed to the command.
  2. The ENVVAULT_ENV environment variable.
  3. The selected_environment field in .envv.json.
  4. Default: development.

Pin the environment for the directory using the interactive picker:

envv use   # pick project + environment, write .envv.json

Or override per command:

envv env list -e production
envv secrets get DATABASE_URL --env=staging
envv run -e qa -- npm test

Creating a Custom Environment

The first write to a new environment auto-provisions it:

# Auto-creates the "qa" environment for this project
envv env set FEATURE_FLAG_NEW_NAV true -e qa

# Verify
envv env list -e qa

Common Workflows

Per-environment configuration

Set a single key with different values per environment:

envv env set DATABASE_URL postgres://localhost/dev -e development
envv env set DATABASE_URL postgres://staging-host/db -e staging
envv env set DATABASE_URL postgres://prod-host/db -e production
Running tests against a dedicated environment
# Once: provision the "test" env
envv env set DATABASE_URL postgres://localhost/test -e test

# Always run tests against it
envv run -e test -- npm test
Ephemeral preview environments
# In a PR pipeline
PR_ENV=pr-${PR_NUMBER}
envv env set DATABASE_URL postgres://preview/db -e $PR_ENV
envv run -e $PR_ENV -- npm run deploy:preview