Projects & Environments

A Permit environment is a silo (a logical grouping) of your policy (roles, conditions, etc.) and data (users, tenants, role assignments, etc.). You can create multiple environments for each of your projects.

For example, you can create a production environment for your production deployment and a staging environment for your staging deployment. Environments can be used for CI/D flows, testing, and more.

In this section we will dive into details of how Projects and Environments work within Permit.io.

Projects

Projects are the highest level of encapsulation for your authorization. Every unique service or application that requires its own set of policies and roles is a project. In addition, each project can support multiple environments - allowing different policies for different deployments or configurations.

Within your organization, you can have multiple projects. Each project represents your offerings, where an offering can be a different product, software or tool. By default, we defined the "Default Project" for you.

You can manage projects from the Projects page.

Creating a new project

If your organization needs to deal with multiple projects, you can add this project directly within the Projects page.

Editing, Filtering and Deleting projects

We also provide the functionality for filtering through projects, to provide you with a more concrete view, and of course, you also get the ability to edit and delete projects as you wish.

Getting the project id

To retrieve the project ID, click on the three dots and the key will be visible in the pop-up, or you can consult this guide for details on obtaining both the project and environment ID's via the API.

note

You will need a project and environment ID for most API calls to Permit.

Managing access to a project

If you want to dive deeper into understanding member roles, refer to the Member Management guide.

Environments

Within your project, you create environments that suit your needs e.g. dev, staging, production etc.

info

Notice when you switch environment the Policy Editor will be updated to reflect the new environment.

Every environment has a secret key that you use to check for permissions with the Permit's SDK and API. We offer simple functionality so that you can easily copy your keys, rotate them if you want to maintain your security to your desired standard, edit the environment to you liking, delete it if need be, and most importantly change environment which is as simple as a click of a button.

You can manage environments from the Project page.

Creating a new Environment

Creating a new environment is as simple as clicking the New Environment button and filling in the details.

Environments can be created from scratch or copied from an existing environment. See Creating Environments for more details.

Getting the environment id

To retrieve the environment ID, click on the three dots and the key will be visible in the pop-up, or you can consult this guide for details on obtaining both the project and environment ID via the API.

note

You will need a project and environment ID for most API calls to Permit.

Fetching and rotating the API key

Editing and deleting environments

Managing access to an environment

If you want to dive deeper into understanding member roles, refer to the Member Management guide.

Working with the Permit Hierarchy

Your workspace, or in other words, your organization, is at the root of the Permit object model. Within your workspace you can have multiple projects, and each project can have multiple environments, each with their own set of policies and roles.

tip

Think of a project as different applications you would want different policies for.

Think of an environment as different deployments you would want different policies for.

Under each environment you will find:

• your tenants (think: your customers)
• your users
• your policy and roles
• your resources and actions (think: the components in your application and their enforcement points)

Within each environment, Users are linked to Tenants via Roles (e.g. user alice has role admin on tenant my-customer).

For example, let's assume we have e-learning platform deployed into production. One of the customers named John Smith, has been enrolled as a student in the paid "Introduction to Web Development" course.

You can have the same user belong to multiple tenants in the same environment.