You've correctly identified the key distinction. Here's how Permit.io's hierarchy works for your scenario: Tenants vs Environments ​*Tenants*​ are designed to isolate users and data, but roles and policies are shared across tenants within the same environment. (1) (2) This means tenants work well when your customers share the same permission model but need data isolation. ​*Environments*​ are silos of policy and data, usually representing a specific deployment (e.g., dev, prod, staging) . (1) Each PDP syncs to a specific environment via its secret environment API key. Recommended Approach for Your B2B PaaS Since each of your customers needs ​*different policies, roles, and relationships*​, you have two main options: Option 1: Environments per Customer Use separate environments for each customer organization. (3) • Each environment has its own independent policy schema • Each PDP connects to its designated environment using a unique secret key • This provides complete policy isolation Option 2: Projects + Environments Structure it as: • ​*Projects*​ = each customer organization (or your own application) • ​*Environments*​ = deployment stages within each (dev, staging, prod) This aligns with the best practice: each application or major service should correspond to a Permit ​*Project*​, with deployments matched to specific Permit ​*Environments*​. For Your Own Dev/Staging/Prod Use environments within a single project for your internal deployment stages. You can implement environment-specific access control to manage who can make policy changes across different stages. The

copy-env

API can be used to merge/promote changes between environments.

To learn more, see the sources I considered: [[1] Concepts / Glossary](https://docs.permit.io/overview/glossary) [[2] Policy Basics](https://docs.permit.io/how-to/build-policies/policy-basics) [[3] Permit.io Best Practices](https://docs.permit.io/overview/best-practices)

Thanks for the feedback, glad I was helpful.

Will update here after trying out the suggestion.

Thanks

There are real benefits beyond just cleanliness when separating environments by project: ​*API Access Control*​ Each project can have its own set of API keys, and each environment within a project has its own secret key. (1) This means you can scope API access at the project level, giving different teams or systems access only to the projects they need. ​*Permit.io Account Access Control*​ You can implement environment-specific access control to manage who can make policy changes across different stages of deployment. (2) For example, a product manager may alter policies in the staging environment but would need a developer or DevOps to apply those changes to production. Member management allows you to allocate policy editor access to stakeholders based on their role and technical proficiency. ​*Structural Benefits*​ Projects represent different applications or services that need their own set of policies and roles. (1) Behind the scenes, Permit creates a Policy as Code repository for each project, and environments are branches in this repository. (3) Think of a ​*project*​ as different applications you would want different policies for. (1) Think of an ​*environment*​ as different deployments you would want different policies for. So separating by project gives you: • Independent policy schemas per project • Granular member access control at both project and environment levels • Separate GitOps repositories per project • Clearer organizational boundaries for different applications/services

To learn more, see the sources I considered: [[1] Projects & Environments](https://docs.permit.io/manage-your-account/projects-and-env) [[2] Permit.io Best Practices](https://docs.permit.io/overview/best-practices) [[3] Modeling and Implementation Components](https://docs.permit.io/how-to/SDLC/modeling-implementation-components)