CI/CD & production

Authenticate CI with workload identity (recommended)

If your CI runs on GitHub Actions, Kubernetes, or GitLab CI, prefer workload identity federation over a static token. The job authenticates with the OIDC identity its runtime already issues it, so there is no VAULTIC_TOKEN in your repo secrets at all — and the credential it gets is scoped to that one job run and expires in minutes:

permissions:
  id-token: write
env:
  VAULTIC_WORKLOAD_PROVIDER: acme-github
steps:
  - run: vaultic run --env production -- node deploy.js

Everything below still applies — a federated credential is an ordinary scoped Vaultic token once exchanged. Use a static service token when your runtime doesn't issue an OIDC identity, or as the break-glass path.

Authenticate CI and deploys with service tokens

Never use a personal login in a pipeline. Create a scoped service token instead:

vaultic tokens create ci-deploy --env production --read-only --expires 90d

Then either inject secrets directly into the running process:

vaultic run --env production -- node server.js

or export them to a file your deploy step reads:

vaultic export --env production --format dotenv

Both accept credentials the same way a human login would — set VAULTIC_API_URL and log the token in via vaultic login --token <token>, or store it however your CI system holds secrets and pass it through ~/.vaultic/credentials.json.

Guard against config drift with --check

If a service (or a teammate) reads from a committed or previously-generated .env instead of calling vaultic run directly, add a drift check as its own CI step:

vaultic export --env production --check

Exits non-zero if the local file is stale against the server — catch a forgotten vaultic sync before it ships, instead of after.

Lock production against direct writes

Any environment can be locked:

vaultic env lock production

Once locked, secrets set and secrets delete no longer apply immediately — they become pending change proposals instead, requiring approval:

vaultic env proposals production
vaultic env approve production <proposalId>

The same queue is visible workspace-wide from the web app's Change Requests page, showing a diff (removed value struck through, added value highlighted) for each pending change before you approve or reject it.

Next steps