Docs
CLI Reference
Every command below is real — this list matches the actual command surface, not an aspirational one. The CLI has one runtime dependency, cross-spawn, used only by run for correct cross-platform command execution.
npm install -g @ashishlekhyani/envsync-cliFastest way to start
Run envsync login <token>, then just run envsync with no arguments — it launches an interactive menu that picks your project, environment, and action for you. Everything below also works directly if you prefer flags and scripts.
$ envsync login <token> Logged in as jordan@example.com $ envsync ? Project › ❯ Core API Marketing Site ? Environment › ❯ Production Staging Development ? Link this folder to that project/environment for next time? › yes ? What do you want to do? › ❯ Pull secrets into .env Push .env back to the server Run a command with secrets injected Check status (diff against .env) Log out Exit Pulled 6 secret(s) into ./.env ? What do you want to do? › ❯ Exit
envsync login [token]
Authenticate with a service token generated in Settings → CLI & Tokens. Writes credentials to ~/.envsync/credentials.json. Reads the token from stdin if omitted (e.g. echo $TOKEN | envsync login), avoiding shell history.
envsync logout
Removes local credentials. Does not revoke the token server-side — revoke it from Settings if it may have been compromised.
envsync (no command) / envsync menu
Interactive mode — once logged in, walks you through picking a project and environment (or reusing a linked one), then an action to run. No flags or IDs to remember.
envsync projects
Lists every project you have access to, with its ID.
envsync environments [--project <id>]
Lists every environment for a project, with its ID. --project can be omitted once you've linked this folder.
envsync link --project <id> --environment <id>
Remembers a project/environment for the current folder (writes .envsync.json there), so every command below can drop --project/--environment entirely.
envsync pull [--project <id> --environment <id>] [--out <path>]
Reveals and writes every secret in the environment to a .env file (default ./.env). Overwrites the destination file completely.
envsync push [--project <id> --environment <id>] [--out <path>]
Reads a local .env file and upserts its keys to the server — creates new keys, updates existing ones. Never deletes keys that exist remotely but not locally.
envsync run [--project <id> --environment <id>] -- <cmd> [args...]
Runs a command with secrets injected directly into its environment variables. Nothing is written to disk.
envsync status [--project <id> --environment <id>] [--out <path>]
Compares your local .env against the server — shows each key's last-updated time and flags anything changed remotely since your last pull. Never reveals values, so it's safe to run often.
A note on audit trails: pull and run reveal every secret in the environment, so each key produces its own audited reveal entry — an environment with 50 secrets means 50 audit rows per pull. statusnever reveals values, so it's audit-quiet by design.
A note on token storage: envsync login <token> writes the token to ~/.envsync/credentials.json, readable only by your user account. Setting an ENVSYNC_TOKEN environment variable instead (common in CI) skips that file, but environment variables are inherited by child processes and can be visible to other tools or users on the same machine — prefer it only in environments you trust, and never pass a token as a bare command-line argument on a shared host.
A service token is always scoped to the single organization it was created in — the CLI (and the interactive menu) can only ever see that one organization, regardless of how many others the token creator personally belongs to.