What Is a ConfigStack? A Better Way to Version and Share Environment Config

If you've ever chased "the right .env" across machines or pasted env vars into Slack, you've felt the pain of environment config that has no single source of truth. A ConfigStack is designed to fix that: it's a versioned snapshot of your environment configuration that you can create, update, and share without sending files or leaking secrets.

What Is a ConfigStack?

A ConfigStack (we call it a "Stack" in the product) is a versioned environment configuration. It holds the keys and values for one environment—e.g. development, staging, or production—in one place. Instead of maintaining a .env file per machine or pasting values into chat, you define a Stack per environment, add or edit variables, and share access through the app or API.

Key ideas:

• One Stack per environment — e.g. "My App – Staging." All keys and values for that environment live in that Stack.

• Versioning — Every change is saved as a version. You can see history, compare versions, and roll back. No more "which .env was correct?"

• Secrets are encrypted — Values you mark as secret are encrypted at rest (e.g. AES-256-GCM). In the UI they're shown masked; they're only decrypted when you explicitly pull or download with proper auth.

• Sharing is controlled — You don't email a .env or paste into Slack. You create shareable Stack Links that can show structure (masked) or allow download, and you can revoke them anytime.

So "what is a ConfigStack?" in practice: it's the replacement for "everyone has their own .env and we hope they're in sync." It's one place to version and share environment config with configuration integrity and drift prevention.

Why Version Environment Variables?

Env vars change: new keys, updated URLs, rotated API keys. Without versioning you get:

• Drift — Teammates have different copies; "works on my machine" often means "I have different env values."

• No rollback — If a change breaks something, you're left guessing what the previous values were.

• No audit — Hard to answer "what did staging look like last Tuesday?" or "who changed the API key?"

A ConfigStack keeps a history of every change. You can roll back to a previous version or compare two versions. That gives you a single source of truth and a clear audit trail.

Snapshots and Baselines

ConfigStack automatically records every change as a versioned snapshot. You can:

• Automatic snapshots — Each save creates a new snapshot. View diffs, see who changed what, and roll back when needed.

• Manual snapshots — Capture the current state at any time (e.g. before a big release) for later comparison.

• Baseline designation — Mark a snapshot (e.g. "known-good production") as the baseline. Stack Doctor and drift checks compare current state to the baseline to catch missing keys and mismatches before they reach production. See Baseline Snapshots.

• Rollback — One click to restore a previous snapshot if something goes wrong.

Stack Doctor

Stack Doctor detects configuration drift and structural issues without exposing secret values:

• Cross-environment comparison — Compare staging vs production, or current stack vs a baseline snapshot.

• High-risk missing detection — Keys containing "password", "token", "secret", etc. are flagged when missing in the target environment.

• Secret mismatch detection — Detects when a key is marked secret in one environment but not another (or vice versa), reducing accidental exposure.

• Similar key warnings — Warns about near-duplicate keys (e.g. API_KEY vs APIKEY) that might cause confusion.

• Suggested fixes — The UI suggests actionable fixes (e.g. add a key, mark as secret) so you can correct drift quickly.

Stack Contracts

Define rules that Stack Doctor validates against:

• Required keys — Enforce that certain keys must exist in every environment or in specific environments.

• Secret classification enforcement — Ensure keys matching patterns (e.g. *_SECRET, *_PASSWORD) are marked as secret.

• Allowed prefixes — Restrict which key prefixes are permitted in a Stack.

• CI enforcement — Use the CI Gate to fail builds when drift severity exceeds your threshold.

CI Enforcement

You can run drift checks in CI without storing secrets in repo config:

• CLI doctor — Run configstack doctor locally or in CI with a scoped token. See the CLI docs.

• /api/v1/doctor/check — Call the API to run a check and get a pass/fail result based on severity. Integrate with GitHub Actions or any CI. See CI Gate and GitHub Actions.

• Pro-only CI gating — Fail builds when severity >= threshold (e.g. fail on MEDIUM or HIGH). Available on Pro plans.

• failOn — Configure the minimum severity that causes a fail (CLEAN/LOW/MEDIUM/HIGH).

Drift Timeline

Stack Doctor runs are recorded as DoctorRun history:

• DoctorRun history — Every run (UI or CI) is stored. View the timeline to see when drift was introduced, when it was fixed, and how severity evolved over time.

• UI vs CI runs — Both manual runs from the app and CI runs appear in the history. Filter by source to debug "it passed locally but failed in CI" scenarios.

• Severity tracking — Track whether drift is improving (e.g. HIGH → MEDIUM → CLEAN) as you fix issues.

How ConfigStack Solves This

ConfigStack turns environment management into a small set of clear actions:

1. Create Stacks — One Stack per environment (e.g. dev, staging, prod). Import from .env or JSON if you already have files.

2. Edit and version — Change keys or values; each save is a new version. View diff and roll back when needed.

3. Mark secrets — Sensitive values are stored encrypted and shown masked in the UI. No accidental exposure on screen.

4. Share without leaking — Use Stack Links to share access. You can share a link that only shows variable names and masked values (so someone sees structure without secrets), or allow download for a time-limited or revocable link. When a link is revoked, it stops working—no more "everyone who had the Slack message still has the secret."

5. Pull from CLI or API — For local dev or CI, pull the current config via CLI or API using scoped tokens. No need to receive a .env by chat or email.

So you get versioning, encryption, controlled sharing, snapshots, baselines, Stack Doctor, and CI enforcement in one place—and you stop sending .env files or pasting secrets into Slack. For more detail, see What is a ConfigStack?, the Docs, Stack Doctor, and Baseline Snapshots.

When to Use a ConfigStack

• Small teams and indie devs — You want something simpler than a full enterprise secrets manager but safer than shared .env files or Slack.

• Multiple environments — You have dev/staging/prod (or more) and want one place to define and version each.

• Sharing with contractors or new hires — You want to grant access to "staging config" without emailing a file or pasting into chat, and revoke when the project ends.

• CI/CD — You need env vars in GitHub Actions or other CI; pull them via API with a scoped token instead of storing them in repo secrets or a long-lived paste.

Summary

A ConfigStack is a versioned environment configuration: one Stack per environment, with history, encryption for secrets, sharing via revocable Stack Links, snapshots, baselines, Stack Doctor for drift detection, and CI enforcement—instead of .env files or Slack. It answers "what is a ConfigStack?" with: a better way to version and share environment config so you have a single source of truth and configuration integrity. Create your first Stack for free, read What is a ConfigStack? for the full picture, and check Pricing for team plans.