CI/CD Deployment

This is the internal implementation reference for CI/CD usage of Envault.

Envault now supports two headless paradigms through envault run:

CI/CD integrations use read-only envault_svc_ Service Tokens.
AI agents (MCP) use short-lived delegated envault_agt_ tokens and HITL approvals.

This page only covers the CI/CD path.

For Vercel serverless runtime variables, prefer Envault native Vercel integration. envault run remains correct for build/test/start commands in generic CI pipelines, but should not be the only mechanism for Vercel runtime env propagation.

Service Tokens are strictly read-only. Mutating commands such as envault deploy are blocked when using envault_svc_ tokens.

Runtime Wrapper Pattern

In CI/CD we treat Envault as a runtime wrapper, not a file sync step.

envault run fetches and decrypts secrets before process start.
Secrets are injected into process memory.
Secrets do not need to be persisted to disk for build/start commands.

Canonical shape:

npx @dinanathdash/envault run --env production -- <command>

GitHub Actions

Use ENVAULT_TOKEN with a Service Token generated from the project dashboard.

.github/workflows/deploy.yml

name: Build and Deploy

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      ENVAULT_TOKEN: ${{ secrets.ENVAULT_TOKEN }}
    steps:
      - uses: actions/checkout@v3

      - name: Install Envault CLI
        run: curl -fsSL https://raw.githubusercontent.com/DinanathDash/Envault/main/install.sh | sh

      - name: Build Application with Envault Secrets
        run: envault run --env production -- npm run build

GitLab CI

For GitLab users, pipeline variables are defined in the repository settings and exposed to the .gitlab-ci.yml.

.gitlab-ci.yml

stages:
  - build

build_app:
  stage: build
  image: node:18
  variables:
    ENVAULT_TOKEN: $ENVAULT_TOKEN
  before_script:
    - curl -fsSL https://raw.githubusercontent.com/DinanathDash/Envault/main/install.sh | sh
  script:
    - npm ci
    - envault run --env production -- npm run build

Docker Entrypoint

Use Envault as the primary entrypoint to inject secrets dynamically just before a Node app boots inside a Docker container.

Dockerfile

FROM node:18-alpine

RUN curl -fsSL https://raw.githubusercontent.com/DinanathDash/Envault/main/install.sh | sh

WORKDIR /app
COPY . .
RUN npm install

CMD ["envault", "run", "--env", "production", "--", "node", "server.js"]

Provide ENVAULT_TOKEN at runtime through your orchestrator secret manager.

Headless Safety Rules

envault deploy requires explicit confirmation or --force; headless sessions should not use deploy with Service Tokens.
envault pull prompts before overwrite; in headless mode use --force if overwrite is intended.
Prefer envault run in CI/CD to avoid writing transient secrets to repository files.

Pipeline Auditing

To audit code commits for leaked environment keys using envault audit:

steps:
  - uses: actions/checkout@v3
  - name: Install Envault
    run: curl -fsSL https://raw.githubusercontent.com/DinanathDash/Envault/main/install.sh | sh
  - name: Audit Repository for Leaked Env files
    run: envault audit --strict --format=json