End-of-Life (EoL)

System requirements

Before installing Prisma Cloud, verify that your environment meets the minimum requirements.
For information about when Prisma Cloud adds and drops support for third party software, see our support lifecycle page.


: Prisma Cloud has the following hardware requirements:
: x86_64
  • Console — 
    • When up to 1,000 Defenders are connected, Console requires 4 vCPUs, 8GB of RAM, and 100GB of persistent storage.
    • When 1,001 - 10,000 Defenders are connected, Console requires 8 vCPUs, 30GB of RAM, and 500GB of persistent storage.
  • Defender — 256MB of RAM and 8GB of host storage.
    Defender uses cgroups to cap resource usage at 512MB of RAM and 900 CPU shares; typical load is ~1-5% CPU and 30-70MB RAM
    Defender stores its data in /var. When allocating disk space for Defender, be sure the required space is available in /var.
    Defenders are designed to be portable containers that collect data. Any data that must be persisted is sent to to Console for storage. Defenders themselves do not require persistent storage. Do not deploy persistent storage for Defenders because it can corrupt Defender files.
  • Defenders providing registry scanning-- 2GB of RAM, 20GB of storage, and 2 CPU cores.
  • CI integration (Jenkins, twistcli) — Required storage space depends on the size of the scanned images. The required disk space is 1.5 times the size of the largest image to be scanned, per executor. For example, if you have a Jenkins instance with two executors, and your largest container image is 500MB, then you need at least 1.5GB of storage space (500MB * 1.5 * 2).
: Prisma Cloud has been tested on the following hypervisors:
  • Microsoft Hyper-V
  • VirtualBox
  • VMware
: Prisma Cloud can run on nearly any cloud IaaS platform. Prisma Cloud has been tested on the following services:
  • Amazon Web Services
  • Google Compute Engine
  • IBM Cloud
  • Microsoft Azure
  • Oracle Cloud

File systems

If you’re deploying Prisma Cloud Console to AWS and you’re using the EFS file system, the following minimum performance characteristics are required:
  • Performance mode:
    General purpose
  • Throughput mode:
    Provisioned. Provision 0.1 MiB/s per deployed Defender. For example, if you plan to deploy 10 Defenders, provision 1 MiB/s of throughput.

Host operating systems

Prisma Cloud is supported on the following host operating systems:
Bottlerocket OS
Tested on OS 1.0.2
Vulnerability and compliance blocking policies are not supported on Bottlerocket
Amazon Linux and Amazon Linux 2
Latest release
CentOS 7, CentOS 8
Debian 9 (Stretch), Debian 10 (Buster)
Container-Optimized OS on Google Cloud latest
GCOOS is purposefully minimalistic. It doesn’t support installing new packages or writing new bins. Hence, Prisma Cloud’s vulnerability detection on GCOOS only covers Docker and Kubernetes package binary detection.
Runtime prevent capability is supported only for DNS events. Other prevent capablities are not supported.
Red Hat
Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux CoreOS (RHCOS) versions included in supported OpenShift releases
Ubuntu Server 20.04 LTS, 18.04 LTS, 16.04 LTS
Windows Server 2016, Windows Server 2019 Long-Term Servicing Channel (LTSC)
The Console container must be run on a supported Linux operating system. Defender is supported on Windows Server 2016 (vulnerability and compliance scanning), and Windows Server 2019 (vulnerability scanning, compliance scanning, and runtime defense for containers).
Photon OS 3.0 latest release
Runtime prevent capability is not supported
SLES 12 SP1 - SP5, SLES 15 SP1 - SP2
The following use cases are currently unsupported:
  • Vulnerability detection for SLES 15 SP2
  • runc support for containers
  • Detection of unknown binaries for hosts
  • Detection of OS security updates for host observation
  • Display OS distribution packages for SLES 15

Kernel capabilities

Prisma Cloud Defender requires the following kernel capabilities. More info about each capability can be found on the Linux capabilities man page.
When running on a Docker host, Prisma Cloud Defender uses the following files/folder on the host:

Docker Engine

Prisma Cloud provides support only for the versions of Docker Engine that Docker itself supports. Prisma Cloud supports the following and later versions. Only official mainstream Docker releases are supported.
  • CE 20.10.5, 19.03, 18.09
  • EE 19.03.4
For storage drivers, overlay2, overlay, and devicemapper are supported. For more information, please refer to Docker’s guide to selecting a storage driver.
The versions of Docker Engine listed in this section apply to versions independently installed on a host. These versions might not be the same as the versions shipped as a part of an orchestrator, such as Red Hat OpenShift. In such cases, Prisma Cloud supports the version of Docker Engine that ships with any Prisma Cloud-supported version of the orchestrator.

OCI runtimes

Prisma Cloud supports the following container runtimes:
Container runtime
See the Docker section
Native Kubernetes 1.19 (containerd 1.4.4)
GKE 1.18.16 containerd 1.4.3
AKS 1.20.2 containerd 1.4.3
OS 4.5 - CRIO version 1.18.3
OS 4.6 - CRIO version 1.19.0
OS 4.7 - CRIO version 1.20.0
K8s native - versions 1.19, 1.20


Podman is a daemon-less container engine for developing, managing, and running OCI containers on Linux. The twistcli tool can use the preinstalled Podman binary to scan CRI images.
Podman versions 2.0.4 and higher are supported.


Prisma Cloud is supported on the following orchestrators. We support the following versions of official mainline vendor/project releases.
Docker Swarm
CE 19.03 & 18.06, EE 19.03 & 18.03
Native Kubernetes CRIO 1.19, 1.20
Native Kubernetes 1.19 (containerd 1.4.4)
Native Kubernetes 1.19 (Docker 20.10.5)
GKE 1.18.16 (Docker and containerd 1.4.3)
GKE 1.17.17 (Docker)
3.11 (Docker version only), 4.5, 4.6, 4.7
VMware Tanzu Application Service - TAS
v2.10, v2.11
Latest Amazon Linux 2, Latest ECS engine
RKE v1.19.10-rancher1-1, RKE 2 v1.18.12+rke2r2


Prisma Cloud supports Istio 1.6-1.8. (Tested on 1.6.10, 1.7.6, 1.8.3)


The Prisma Cloud Jenkins plugin supports Jenkins LTS releases. For any given release of Prisma Cloud, the plugin supports those Jenkins LTS releases supported by the Jenkins project at the time of the Prisma Cloud release.

Image base layers

Prisma Cloud can protect containers built on nearly any base layer operating system. Comprehensive Common Vulnerabilities and Exposures (CVE) data is provided for the following base layers:
  • Alpine
  • Amazon Linux 2
  • BusyBox
  • CentOS
  • Debian
  • Red Hat Enterprise Linux
  • Ubuntu (LTS releases only)
  • Windows Server

Serverless runtimes

Prisma Cloud can protect AWS Lambda functions at runtime. Prisma Cloud supports the following runtimes:
Serverless runtimes using Lambda Layers
  • Node.js 10.x, 12.x
  • Python 2.7, 3.6, 3.7 and 3.8
Serverless runtimes using manually embedded Defenders
  • C# (.NET Core) 2.1, 3.1
  • Java 8, 11
  • Node.js 10.x, 12.x
  • Python 2.7, 3.6, 3.7 and 3.8
Prisma Cloud can also scan serverless functions for vulnerabilities and compliance benchmarks. Prisma Cloud supports the following runtimes for vulnerability and compliance scans in AWS Lambda, Google Cloud Functions, and Azure Functions:
Serverless vulnerability and compliance scanning
  • C# (.NET Core 2.1, .NET Core 3.1)
  • Java 8, Java 11
  • Node.js 10.x
  • Python 2.7, 3.6, 3.7 and 3.8


Prisma Cloud can detect vulnerabilities in Go executables for Go versions 1.13 and greater.


For Linux, Prisma Cloud depends on the Bash shell. For Windows, Prisma Cloud depends on PowerShell.
The shell environment variable DOCKER_CONTENT_TRUST should be set to 0 or unset before running any commands that interact with the Prisma Cloud cloud registry, such as Defender installs or upgrades.


Prisma Cloud supports the latest versions of Chrome, Safari, and Edge.
For Microsoft Edge, we only support the new Chromium-based version (80.0.361 and later).

Cortex XDR

Prisma Cloud Defenders can work alongside Cortex XDR agents. Currently, users need to manualy add exceptions in Console for both agents to work together. In a future release, there will be out-of-the-box support for co-existence. Users can disable the Defender runtime defense when a Cortex XDR agent is present.
To allow for both the solutions to co-exist:
  1. Add the Cortex agent as a trustable executable. For more information, see to Creating a trusted exeuctable.
  2. Suppress runtime alerts from the Cortex agent by adding custom runtime rules that allow the Cortex agent process and file path.