Projects and environments

Projects

A project is the top-level grouping that isolates one application’s flags, configs, and segments (ADR-0011). When several services share one Featly database (the shared-database deployment pattern), each service’s definitions stay in their own project and never collide.

On first boot Featly auto-creates a default project so the quickstart needs zero setup (ADR-0019). You can disable that (Featly:Server:AutoCreateDefaultProject=false) and manage projects explicitly.

Environments

An environment is a deployment target — development, staging, production, and whatever else you define. A flag has per-environment values and rules: the same new-checkout flag can be on for everyone in development, a 5% canary in staging, and off in production, all at once.

Environments also carry governance state:

• Approval policy — whether mutations require review (see Governance).
• ReadOnly lock — a freeze that rejects all mutations during an incident, toggled from the dashboard or featly env lock <key> from the CLI.

API keys are environment-scoped

An API key is scoped to a single environment (ADR-0009). A leaked SdkRead key for staging can read staging and nothing else — it cannot read production and cannot mutate anything. Keys also carry a scope (SdkRead for the SDK API, AdminWrite for the admin API) and can be bound to a user so that actions attribute to a real person in the audit log and approvals (ADR-0023).

featly apikey generate --name web-prod --scope SdkRead --environment production \
  --user ci@example.com

Promoting changes between environments

Because each environment holds its own values, promoting a configuration is an explicit act. The featly export / featly import commands move flag/config/segment definitions between environments as a JSON bundle — definitions only, never users, keys, or audit history.

Next

• Governance — RBAC, approvals, and the audit log.
• Deployment — the three deployment patterns.