Runtime secret injection for applications and CI/CD

Start the process with its configuration

The CLI fetches the selected environment values and starts the child process with those values in its environment. For the `runenv run` path, secret values are not written to `.env`, `.env.local`, logs, or `.runenv.json`.

• Install the CLI with `npm install -g runenv-cli`.
• Link a repository to a project and environment.
• Run `runenv run -- npm start` or the command your application already uses.

Use the same model in CI/CD

RunEnv can provide configuration to GitHub Actions with a least-privilege service token and an explicit project and environment. Bind staging and production workflows to their intended deployment boundary instead of copying a shared file between jobs.

• Use a separate RunEnv environment for each deployment boundary.
• Scope automation identities to the smallest project and environment they need.
• Prefer process-level injection and avoid putting resolved values in artifacts or image layers.

Choose an SDK when the application needs it

The Node.js and Python SDKs support programmatic integration when an application needs to load configuration from code. Prefer `runenv run` when process-level runtime injection is enough, and use an SDK when the workload needs an explicit integration.

• Load configuration into the process environment through a supported SDK.
• Keep service tokens in the process environment or workload identity mechanism.
• Do not print, serialize, or commit resolved secret values.

Keep file delivery as an explicit exception

Some tools require a file. RunEnv documents file-secret, download, offline-cache, and temporary-file workflows separately so teams can choose the storage boundary deliberately instead of treating every delivery mode as zero-disk.