apps/docs/content/guides/manage/console/projects-overview.mdx
import ProjectDescription from "../../../concepts/structure/_project_description.mdx";
A Project is the vessel that holds your Applications and Roles. It defines the security context for a specific software solution.
Imagine you are building a Point of Sales (POS) platform. In ZITADEL, you would create one Project (e.g., named POS).
admin, cashier, viewer) inside this Project.Applications define the different clients (web apps, native mobile apps, server-side APIs) that share the same roles and security context. At the moment, we support OIDC and almost every OAuth2 client. We'll be expanding this with SAML shortly. Go to Applications for more details.
A role consists of different attributes, but only the Key is relevant to the role assignment and must be unique within the project.
role.admin).Read more about managing roles here.
When creating a new ZITADEL instance, you will find an automatically created project in the first organization. This Default Project (named "ZITADEL") protects the ZITADEL Management Console and APIs.
<Callout type="caution"> We do not recommend changing any settings in the Default Project or using it for your own applications, as this could influence the behavior of ZITADEL itself. </Callout>To create a project:
Navigate to your Organization in the Console.
Go to Projects (or visit https://${CUSTOM_DOMAIN}.zitadel.cloud/ui/console/projects).
Click the Create New Project button.
Enter your project name and continue.
A powerful feature of ZITADEL is the ability to Grant a project to other organizations. This is essential for B2B scenarios where you sell your software to business partners.
Using the POS example above: You could grant the POS project to a partner organization. That partner can then log in with their own domain, use their own branding, and manage their own cashier users, all while using your underlying application structure.
Navigate to the Project you want to share (e.g., POS).
In the Project Grants section, click New.
Enter the Domain of the partner organization you want to grant access to.
Search and select the organization.
Select the Roles you want to grant to this organization and click Save.
You can customize the behavior of your project, particularly regarding how login screens look and how tokens are issued.
If you have different designs for your organizations (Private Labeling), you can define the login behavior on the project detail page.
| Setting | Description |
|---|---|
| Unspecified | If nothing is specified, the system default settings will trigger. |
| Enforce project's policy | This forces the branding of the organization that owns the project throughout the entire login process. Useful if you want your users to always see your brand, even if they belong to a partner org. |
| Allow login user policy | The login starts with the project's branding. However, as soon as the user is identified (e.g., by entering their email), the branding switches to match the user's organization. |
In a B2B use case, you would typically use Allow login user policy. If you want to skip the detection step, you can preselect an organization using the Organization Domain scope (e.g., urn:zitadel:iam:org:domain:primary:{domainname}).
You can configure strict security checks regarding roles during authentication.
If you want roles to appear directly inside your Access or ID Tokens (to avoid calling the Userinfo endpoint), you must enable this per application.
You can learn more about Application and Token settings here.