How to
How to use RunEnv in GitHub Actions
CI should use a service token scoped to one project and environment, not a human session. Prefer process-level injection during the job. Never commit a token or print resolved secret values to logs, artifacts, or the job summary.
How it works
Three steps for the supported path.
- 01
Create a scoped automation identity
Create a service token limited to the project and environment the job needs. Store it in GitHub Actions secrets as `RUNENV_TOKEN`. Do not put it in the workflow file.
- 02
Call the action or CLI
Use `Jambo-company/runenv-action@v1` with token, project, environment, and command, or run `runenv run -- npm run build` with `RUNENV_TOKEN` in the step environment.
- 03
Keep values out of artifacts
Do not upload resolved env files, pass secrets through Docker `ARG`/`ENV`, or print them in logs. If retrieval fails, debug token scope and project/environment without printing credential material.
Bind each workflow to one environment
Use a staging RunEnv environment on protected staging branches and production only on protected production branches. Give each workflow token only the project and environment permissions it needs.
Prefer injection over files
Avoid exporting values into a tracked `.env` file or a Docker image layer. If a build tool requires a file, create it in the job workspace only for that step, keep it out of artifacts, and delete it afterward.
Self-hosted runners
Self-hosted runners must use the HTTPS URL of your RunEnv deployment and a job-scoped identity. Do not use a human user token as a long-lived runner credential.