End-of-Life (EoL)

System requirements

Before installing Prisma Cloud, verify that your environment meets the minimum requirements.


: Prisma Cloud has the following hardware requirements:
  • Console — 
    • When fewer than 100 Defenders are connected, Console requires 1GB of RAM and 10GB of persistent storage.
    • When more than 100 Defenders are connected, Console requires 3GB of RAM and 50GB 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.
  • 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

Host operating systems

Prisma Cloud is supported on the following host operating systems:
Amazon Linux 2
Latest LTS release v2
CentOS 7, CentOS 8
CoreOS latest stable channel (CoreOS 2345.3.0)
Host Defender isn’t supported on CoreOS. CoreOS is specifically designed for running containers. Install Container Defender instead.
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.
Red Hat
Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8
Ubuntu Server 18.04 LTS, 16.04 LTS
Ubuntu 14.04 LTS does not support system call monitoring. The required kernel option is not enabled in the default kernel.
Host Defender isn’t supported on Ubuntu 14.04.
Windows Server 2016, Windows Server 2019
Console must be installed on a supported Linux operating system, either natively or through virtualization (such as Hyper-V). 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


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

Since Prisma Cloud often adds new features that take advantage of new Docker capabilities, Prisma Cloud provides commercial support only for the versions of Docker Engine that Docker itself supports. This ensures that updates can be properly tested and supported throughout customers' environments. Prisma Cloud follows the same support lifecycle policy as Docker Enterprise Edition. For more information, see Docker’s Maintenance Lifecycle.
New versions of Docker Engine are supported shortly after they are released. Prisma Cloud supports the following and later versions. Only official mainstream Docker releases are supported.
  • CE 19.03, 18.06
  • EE 19.03, 18.03
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.


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.
The following version of Podman are supported:
  • Podman 1.6


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
1.17, 1.18, 1.19
Includes managed solutions that are CNCF Certified Kubernetes conformant.
3.11 - docker version only, 4.2, 4.3, 4.4, 4.5
VMware Tanzu Application Service - TAS (formerly Pivotal Cloud Foundry - PCF PAS)
N, N-1 support policy

Container runtimes

Prisma Cloud supports the following container runtimes:
Container runtime
See the Docker section
Client version: 1.2.8
Server version: 1.2.8
OS 4.2 - crio version 1.14.12-10
OS 4.3 - crio version 1.16.2-6
OS 4.4 - crio version 1.17.4-18.dev.rhaos4.4.gitfb8131a.el8


Prisma Cloud supports Istio 1.0 - 1.6.

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.


Prisma Cloud provides a Jenkins plugin that scans images for vulnerabilities after they are built.
The Prisma Cloud plugin supports the following Jenkins versions:
  • 2.190, 2.204 and 2.222 (these versions support Podman <2)
  • 2.235 (this version doesn’t support Podman)
Prisma Cloud tests the latest (or near-latest) LTS releases of Jenkins. These versions are guaranteed to be compatible with Prisma Cloud. Other recent LTS versions should also work. However, if you’re having issues with the Prisma Cloud plugin, we recommend that you upgrade to the version of Jenkins that Prisma Cloud has tested.


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).

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


Prisma Cloud can protect AWS Lambda functions at runtime. Prisma Cloud supports the following runtimes:
Serverless Runtime using Lambda Layers (including auto-protect)
  • Node.js 10.x
  • Python 2.7, 3.6, 3.7 and 3.8
Serverless Runtime using manually embedded Defenders
  • 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 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

Default UID/GID

When installing Console with twistlock.sh, the Prisma Cloud data folder (var/lib/twistlock) owner and group are set to a UID and GID of 2674, and the Console process runs as user 2674 by default. To configure Console to run as root, open twistlock.cfg and set RUN_CONSOLE_AS_ROOT to true before running twistlock.sh. You must run Console as root if you want it to listen on port 443 or some other privileged port.
When installing Console in a Kubernetes or OpenShift cluster, the Console process runs a root by default.
Defenders always run as root. Although Defenders run as root, they drop the capabilities they don’t need. For a list of capabilities that Defenders retain, see Defender Architecture.

Recommended For You