When you sign up for Canopy, you create an Account — the top-level container that owns billing, admin users, and everything inside it. Inside an Account you create Applications, one for each product whose access you want to manage. Inside each Application you create Environments — independent copies of your permissions, roles, and hierarchy (typically one per stage: development, production, etc.). The three layers — Account → Application → Environment — are the structural backbone of every other concept in Canopy.

An Account is your company's container in Canopy. It owns billing, the admin users who log into the dashboard, and the directory of identities — your end users — that every Application in the Account can draw from. Identities can exist purely at this Account layer with no Application or Environment access at all, useful for pre-provisioning, federated/SSO directories, or staged onboarding. Granting access into a specific Application is a separate AppMembership row, and granting permissions within an Environment is a separate role assignment — three layers, three independent decisions. See the Identities overview for the full model. When you sign up, you create exactly one Account, and everything else you build in Canopy lives somewhere inside it.

An Application is a single product whose access you want to manage. If you have one product, you have one Application; if you run multiple products under the same company — say a customer-facing app and an internal admin tool — each one is its own Application. Two Applications under the same Account are completely independent: they don't share permissions, roles, hierarchy nodes, OAuth clients, or API keys.

An Environment is where all of Canopy's access-control configuration actually lives. Two Environments inside the same Application are fully isolated — they share no access-control state. Each Environment picks its own access model (flat or hierarchical), defines its own hierarchy and schema, and owns its own permissions, roles, role assignments, API keys, OAuth clients, and webhooks. One env can run in flat mode while a sibling runs in hierarchy mode — they don't constrain each other. A permission you add in development, a role you create, a user you assign at a node, an API key you issue — none of it exists in production until you explicitly promote it.