We need something better than environment variables for releases

Absolutely — if you’re trying to make releases safer, more reproducible, and easier to audit, environment variables are usually too implicit.

A better pattern is to move release configuration into a versioned, declarative release spec and keep env vars only for truly runtime-local secrets or machine-specific settings.

Better options than env vars

1. Release manifest / config file

Put release settings in a checked-in file like:

• release.yaml
• deploy.json
• service.config.toml

Example:

service: billing-api
version: 1.42.0
image: registry.example.com/billing-api:1.42.0
region: us-east-1
strategy: canary
healthcheck:
  path: /health
  timeoutSeconds: 10

Why better:

• versioned in git
• reviewable in PRs
• reproducible across environments
• easier to diff and audit

---

2. Release artifacts with metadata

Treat the release itself as an artifact, not a set of shell variables.

Example:

• container image + immutable tag/digest
• build metadata file
• signed manifest

{
  "service": "billing-api",
  "version": "1.42.0",
  "imageDigest": "sha256:abc123...",
  "buildId": "ci-8842",
  "commit": "f3d91aa"
}

Why better:

• immutable
• traceable back to source and build
• avoids “what env was this deployed with?” problems

---

3. Parameterized release pipeline

Store release inputs in the CI/CD system as typed parameters rather than ad hoc env vars.

Examples:

• GitHub Actions inputs
• GitLab CI variables with typed/locked scopes
• Argo CD app config
• Helm values files

Why better:

• explicit schema
• RBAC and approvals
• less hidden coupling

---

4. Secret manager for secrets, config for everything else

Split concerns:

• Non-secret release config → file / manifest / pipeline parameters
• Secrets → Vault, AWS Secrets Manager, GCP Secret Manager, Kubernetes Secrets, SOPS

This avoids overloading env vars for both config and secrets.

---

Practical recommendation

If your problem is “releases depend on a bunch of env vars,” I’d suggest:

1. Create a release.yaml
2. Make the CI pipeline consume only that file
3. Keep secrets in a secret manager
4. Build immutable artifacts tagged with commit SHA and version
5. Require the release manifest to be reviewed and stored in git

---

Rule of thumb

Use env vars only for:

• local runtime overrides
• ephemeral CI job details
• secrets injected by platform tooling

Use release manifests for:

• version
• image tags/digests
• rollout strategy
• feature flags
• environment-specific config
• approval metadata

If you want, I can sketch:

• a release manifest format for your stack,
• a migration plan from env vars, or
• a sample CI/CD flow that uses manifests instead.