Secrets management for CI/CD pipelines

Inject end-to-end encrypted secrets into GitHub Actions and GitLab CI from a single source of truth.

To manage secrets in CI/CD with Envless, store your variables once, encrypted client-side, then pull them into GitHub Actions or GitLab CI at runtime with a single scoped API key. Your pipeline calls the Envless CLI or SDK, fetches the values for a chosen environment, and runs your build or deploy step with them in memory. The server only ever holds ciphertext. You stop copy-pasting secrets into each provider's settings UI, keep CI reading the same source of truth as local and production, and get an attributed change history showing who changed what.

Where CI/CD (GitHub Actions, GitLab CI) secrets get painful

  • Secrets are duplicated across GitHub repo settings, GitLab CI variables, and local .env files, so they drift and rotation means editing them in several places.
  • CI provider secret stores show plaintext to anyone with project admin rights and offer no per-environment history of who changed a value.
  • Plaintext .env files get committed by accident or printed into build logs, leaking credentials to anyone who can read the pipeline output.
  • Adding a new variable for staging or production means clicking through a provider UI instead of versioning it alongside the rest of your config.

Manage secrets for CI/CD (GitHub Actions, GitLab CI) with Envless

  1. 1

    Store secrets once, encrypted on your device

    Add your variables to an Envless project and pick an environment (for example staging or production). Values are encrypted client-side before upload, so the server and your CI provider never see plaintext. This becomes the single source of truth your pipelines pull from.

  2. 2

    Create a scoped CI API key

    In the dashboard, generate an API key with read-only scopes, limited to the projects your pipeline needs. Store only that key in your provider's secret store. It is the one credential CI holds, and it unlocks values at runtime instead of exposing them at rest. 

    # GitHub: Settings > Secrets > Actions
# GitLab: Settings > CI/CD > Variables
ENVLESS_TOKEN=<your-api-key>
  3. 3

    Pull secrets in GitHub Actions

    Add a step that runs the Envless CLI to load the environment, then run your build or deploy command. Secrets stay in memory for the job and are never written to a committed file. 

    - name: Build with secrets
  env:
    ENVLESS_TOKEN: ${{ secrets.ENVLESS_TOKEN }}
  run: envless run -- npm run build
  4. 4

    Pull secrets in GitLab CI

    Do the same in .gitlab-ci.yml: expose the API key as a CI variable and wrap your job command with the CLI so values are injected for that job only. 

    deploy:
  script:
    - envless run -- npm run deploy
  5. 5

    Rotate and track changes from one place

    Update or rotate a value in Envless and every pipeline picks it up on the next run, with no provider UI edits. Versioning and the attributed per-variable history record each change, every change can also be delivered to your own systems as a signed webhook, workspace roles limit what each teammate can do, and key scopes limit which projects a key can reach.

CI/CD (GitHub Actions, GitLab CI) secrets FAQ

Common questions about using Envless with this stack.

Envless injects values into the job's environment at runtime rather than writing them to a committed file. Because the CLI loads them into memory for the process you run, they are not printed unless your own build step echoes them. Treat the Envless API key like any other secret and avoid logging environment variables.

Only for one value: the Envless API key. That scoped key is the single credential your pipeline holds, and it fetches the rest at runtime. Your application variables live in Envless instead of being duplicated across each provider's settings, so rotation and history happen in one place.

Yes. Each pipeline asks for the environment it needs, such as staging or production. Create a separate API key per pipeline, give it read-only scopes, and limit it to the projects it should reach. Key access is scoped by project rather than by environment, so keep anything a pipeline must never see in its own project.

Rotate the value once in Envless and the next pipeline run pulls the new value automatically. There is no provider UI to update. Versioning and the attributed per-variable history record the change, so you can see exactly when a value moved and who changed it.

Get Started

Ship secrets, not chaos.

Start free today and discover why developers trust Envless for end-to-end encrypted, versioned secrets across every environment.