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
development, staging, and production are always available. The CLI defaults to development when no environment is specified.
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:
- The
-e/--envflag passed to the command. - The
ENVVAULT_ENVenvironment variable. - The
selected_environmentfield in.envv.json. - Default:
development.
Pin the environment for the directory using the interactive picker:
envv use # pick project + environment, write .envv.jsonOr override per command:
envv env list -e production
envv secrets get DATABASE_URL --env=staging
envv run -e qa -- npm testCreating 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 qaCommon Workflows
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# 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# 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