1. Overview

Some deployments are very large, running on more than 10,000 hosts. Other deployments must be compartmentalized, for regulatory or operational reasons. Projects solve two problems: Scale and multi-tenancy.

Projects let you deploy a single master Console, with a single URL, that can scale out to support an infinite number of container hosts. You can set up an environment that shares the same rules and configurations as the master Console, or deploy separate compartmentalized environments which operate independently with their own rules and configurations.

For example, you might have https://console.customer.com as the single URL for accessing the Console UI and API. Then you could deploy a Console to each of your regional data centers to support a scaled-out production environment, or segregated instances of Console for each business unit, or both, and manage all of them from a single Central Console.

Role-based access control (RBAC) rules manage who can access which project. When users log onto Prisma Cloud Central Console, they are shown a list of projects to which they have access and can switch between them.

2. Terminology

The following terms are used throughout this article:

Central Console

Also known as the master Console or just master. This is the interface from which administrators manage (create, access, and delete) their projects.


Secondary, slave Console responsible for the operation of a project. Supervisor Consoles are headless. Their UI and API are not directly accessible. Instead, users interact with a project from Central Console’s UI and API.


A deployment unit that consists of a Supervisor Console and up to 5,000 Defenders. There are two types of projects: scale projects and tenant projects.

Scale project

The Supervisor Console inherits all rules and settings from the Central Console. Stack multiple scale projects together to deploy Prisma Cloud to large environments with a large number of hosts. Each scale project supports 5,000 Defenders. Two scale projects can support an environment with 10,000 hosts, three scale projects supports 15,000 hosts, and so on.

Tenant project

Tenant projects maintain all their own rules and settings, separate from Central Console and any other Supervisor Consoles.

3. When to use projects

Carefully assess whether you need projects. Provisioning projects when they are not required will needlessly complicate the operation and administration of your environment.

1. Does your container environment have more than 5,000 hosts?

If yes, then provision a scale project, where each scale project can handle a maximum of 5,000 hosts (Defenders). Add a scale project for every 5,000 hosts in your environments. Stacked scale projects work together as a single, cohesive environment with shared rules and settings.

If your environment has fewer than 5,000 hosts, then you do not need to provision any scale projects. A single Console will be sufficient for your needs. You can always migrate to a project structure if your environment does grow past 5,000 hosts. For more information, see Migration strategies.

2. Do you have multiple segregated environments, where each environment must be configured with its own rules and policies?

If yes, then deploy a tenant project for each environment.

3. Are you upgrading from Prisma Cloud 2.3?

If yes, then your existing deployment will continue to work exactly as it did before.

Migrating to projects is not required. Projects are an optional feature that is disabled by default. There is no need to migrate to projects unless you have a specific need for the functionality it offers.

If you are using Prisma Cloud 2.3, and you’ve deployed multiple Consoles, you can easily adopt projects to fold your stand-alone Consoles under the management of a single Central Console. First upgrade all your Consoles to Twistock 2.4, then see Migration strategies.

4. If you choose not to use projects now, can you migrate to projects at a later time?

Yes. Even if you choose not to use projects now, you’re not locked into that decision. You can always migrate to projects at a later time.

4. Architecture

Projects federate the UI and API for multiple Consoles.

For example, if you have three separate instances of Consoles for development, test, and production environments, projects let you manage all of them from a single Central Console. With projects, one Console is designated as the master and all others are designated as supervisors. Thereafter, all UI and API requests for a project are proxied through the master and routed to the relevant supervisor. Supervisors do not serve a UI or API.

A single Central Console can support both scale and tenant projects simultaneously.