Environment Tiers for Teams: Dev, Staging, Production Safety

An environment tier is a safety classification applied to a ConfigSync environment. There are four tiers: development, staging, production, and custom. Each tier carries different confirmation requirements and visual indicators to prevent accidental operations in sensitive environments.

Without tiers, every push and pull operation works the same regardless of context. A developer who runs configsync push while connected to production databases gets no warning. Tiers add the guardrails that teams need when working across multiple environments.

Each tier has a different confirmation behavior:

The production tier uses the same pattern as destructive operations on cloud platforms: you must type the environment name to confirm. This makes accidental production operations nearly impossible.

Create environments with their tier and optional visual settings:

The --protect flag on the production environment enables the type-to-confirm behavior. The --color flag sets the visual indicator color.

When you are working in a non-development environment, ConfigSync provides visual cues so you always know your context:

The color setting applies a tint to the ConfigSync status output. Red for production, amber for staging — the visual language matches what developers already expect from deployment tools and cloud dashboards.

Each environment can carry its own set of secrets and .env files. When you push from a production environment, the .env files are stored separately from development secrets:

This scoping prevents accidental cross-contamination. A developer working in the development tier never accidentally pulls production database credentials. Production secrets are only accessible when the production environment is explicitly active.

Tiers enable sensible access patterns for teams of different experience levels:

Junior developers work exclusively in the development tier. They can push and pull freely without guardrails because there is nothing sensitive to break. Their development .env files contain local database URLs and test API keys.

Senior developers can switch between development, staging, and production tiers. When they switch to staging, the confirmation prompt adds a moment of pause. When they switch to production, typing the environment name ensures deliberate intent.

The practical benefit of tiers becomes clear with .env file management. When a developer runs configsync pull, they get only the .env files that belong to their active environment tier:

Same .env file paths, different values per tier. The developer's local files always match their active environment. No manual editing of database URLs, no accidentally running tests against production data.