Skip to content

How run works

How getmyenv run works: resolve the context, check every variable has a value, merge with the parent environment, and start your app. No SDK.

Last updated: 2026-10-11

Resolve, validate, merge, spawn

  • Resolve: fetch the context's ciphertext and decrypt it on your machine.
  • Validate: every variable in the project needs a value in this context or in the parent environment.
  • Merge: combine with the parent environment.
  • Spawn: start your command with the result.

Where run goes

Run getmyenv where your app starts: your machine, the server, the CI job, or the container's start command. It needs Node 24 or newer there. run is the default. If getmyenv can't run where the app starts, export writes a plaintext .env instead.

The process that run starts gets readable values as environment variables, and so do its child processes. export writes them to a plaintext file.

In containers and CI, point GETMYENV_CONFIG_DIR at a persistent volume so the machine stays the same across runs. Compose: /docs/docker.

Server access at start

run fetches the values from getmyenv each time it starts. If it can't reach the server, the command does not start. A running process keeps its values. Revoking stops new reads. A running process keeps the values it started with until it restarts.

When something fails

In each case below, run exits with an error, your app does not start, no value is printed, and the next run works once the problem is gone.

  • The server cannot be reached: it names the address it tried.
  • The server does not answer in time: it stops waiting and says so.
  • The server returns an error, like HTTP 503: it prints the status.
  • The connection closes mid-answer: it says the answer did not arrive.
  • The folder token is invalid, revoked or its project was deleted: it says why and gives the next step.
  • A value is missing: it names the variable.

If an import is cut off, some values may already be saved. The CLI says so. Run import again. A process already running keeps its values when its token is revoked.

The CLI end-to-end tests run each of these cases on every change, through a proxy that injects the fault.

Precedence

By default getmyenv values win over variables already in the parent environment. The CLI prints each replaced name. With --keep-existing, parent values win. --explain shows the origin of every name.

npx getmyenv run --explain staging
PORT=4000 npx getmyenv run --keep-existing -- npm start

Names run refuses

Some names change how programs start or where their traffic goes, like NODE_OPTIONS, PATH, LD_PRELOAD, GIT_*, NPM_CONFIG_*, PYTHON* and HTTPS_PROXY. When the context sets one, run stops and names it. NODE_ENV stays allowed. --allow-unsafe-env runs anyway.

The list is best effort. No list covers every program, so give write access to a context only to people you would let run code on the machine.

Names starting with GETMYENV_ are the CLI's own settings. run never passes them from a context, even with --allow-unsafe-env.

Chaining with other tools

getmyenv reads the parent environment, so you can chain it with other tools, like a password manager.

op run -- npx getmyenv run staging -- npm start
npx getmyenv run -- pm2 start ecosystem.config.js

Docker Compose: /docs/docker. Vercel and Netlify read their own copy, written by push: /docs/deploy-platforms.

AI agents

Start the app with getmyenv run. Do not wrap the agent itself. The agent then works on code, and the app process gets the values.

Ask the human once, in one message: where will the app run, and use getmyenv at runtime or as a manager only? Recommend runtime: npx getmyenv run -- <command> passes the values to the process, with no .env file on disk. Manager only: npx getmyenv export writes a plaintext .env for tools that read one, and the scripts stay as they are. Run getmyenv where your app starts: your machine, the server, the CI job, or the container's start command. It needs Node 24 or newer there. run is the default. If getmyenv can't run where the app starts, export writes a plaintext .env instead. If you cannot ask, use runtime for local development. With runtime, remove --env-file=.env only from scripts that load that file. run already puts the values in the environment, and node stops with an error when the file is missing.

No code changes

Your code keeps reading environment variables, for example process.env.OPENAI_API_KEY or os.environ["OPENAI_API_KEY"]. Examples: /docs/languages.