Skip to main content

​
Overview

shipd scopes everything to an organization, a project, and an environment. The same three scopes appear on management API keys, SDK keys, and every shipd command (--org, --project, --env).

​
Hierarchy

A project has at most one live production environment. Its slug can be production, canary, or production-eu; protection comes from the isProduction setting, not the name. Admins and owners can click Mark as production on the dashboard’s Environments page. The confirmation identifies the current production environment, which loses that status when you promote another environment. Click Remove production status to clear the setting. MCP environment tools also support isProduction for authorized write connections.

​
What is project-global and what is per environment

Changing a definition (type, variants, and so on) applies to all environments, so shipd push warns you. When the project has a production environment, applying a definition change requires flag.production.toggle even with --env staging. Default-only updates on a non-production environment need only flag.state.update. See Organizations and access control.

​
Keys

Every credential is bound to part of this hierarchy. An SDK key belongs to exactly one environment, so a server in staging and a server in production use different SDK keys. A management API key is bound to one organization, project, and environment. shipd login picks all three in the browser and stores a management API key, not a user session. For prefixes, where each key is created, and which one to use, see SDK keys, management API keys, and service account tokens.

​
Next