Universal CI/CD Integration

Use Envault as a runtime wrapper in any pipeline with a read-only Service Token.

Use this guide when you want to run builds, tests, or app start commands in CI/CD without writing secrets to disk.

Envault injects variables at process runtime through envault run, so secrets stay in memory and never get committed into files, image layers, or build artifacts.

CI/CD uses read-only Service Tokens (envault_svc_).

1. One-time setup

Generate a Service Token

In the Envault dashboard, open your project and create a Service Token.

The token prefix should be envault_svc_.

Add it to your CI/CD provider

Save the token as a secret named ENVAULT_TOKEN.

Use your provider's secret manager (for example GitHub Actions Secrets, GitLab CI Variables, Render Environment Variables).

Use the runtime wrapper pattern

Wrap your existing command:

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

2. Direct templates

Frontend / Serverless (Vercel, Cloudflare, Netlify)

Do not use the CLI wrapper (envault run) for Serverless runtime injection. Serverless workers do not reliably inherit build-wrapper process env at runtime.

For Vercel, use Envault's native integration to sync secrets directly into Vercel project env storage. For other serverless providers, store variables in provider-native env storage.

Recommended Vercel flow:

Link Envault project to Vercel project in the integration UI.
Select enabled environments (Development, Preview, Production).
Save mapping and run initial sync.
Manage secrets in Envault as source of truth; updates sync to Vercel.

Container pipelines (Docker / GitHub Actions / GitLab)

.github/workflows/build.yml

name: Build

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci

      - name: Build with Envault
        env:
          ENVAULT_TOKEN: ${{ secrets.ENVAULT_TOKEN }}
        run: npx @dinanathdash/envault run --env production -- npm run build

PaaS (Render / Railway)

Set your start command to:

npx @dinanathdash/envault run --env production -- node server.js

Docker

FROM node:20-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci

COPY . .
RUN npm install -g @dinanathdash/envault

# Provide ENVAULT_TOKEN at runtime (docker run / orchestrator secret).
CMD ["envault", "run", "--env", "production", "--", "node", "server.js"]

3. Development usage (optional)

For local development, keep using your normal developer auth (envault login) and run:

npx @dinanathdash/envault run --env development -- npm run dev

Use Service Tokens only for non-human automation contexts (CI/CD, bots, deploy systems).

Network Resilience and Timeouts

By default, the Envault CLI is highly resilient to transient network drops. If the Envault API is temporarily unreachable during a CI/CD run, envault run will automatically retry with exponential backoff for up to 5 minutes.

If you have strict CI/CD billing constraints and prefer your pipeline to fail faster during an outage, override this behavior using the --timeout flag or the environment variable:

# Fail fast after 30 seconds
envault run --env production --timeout 30s -- npm run build

Alternatively, set ENVAULT_RETRY_MAX_DURATION=30s in your pipeline secrets.

Universal CI/CD Integration

On this page