Deploy to a cluster

Last published : Nov 10, 2026
Citrix SecurSpaces™ runs on any Kubernetes-compatible cluster, including OpenShift. Preparing that cluster is the part that differs between platforms; everything after it is the same.
Note
This page is for a production deployment. If you only need to evaluate SecurSpaces, you do not need a cluster at all — the 1-Click VM runs the whole platform on a single virtual machine, and is the quickest route to a working environment for a proof of concept or a demonstration. See Deploy an evaluation environment. It is not intended for production use.
Related information
Deploy
Amazon EKSAzure AKSGoogle GKEDeploy SecurSpaces on Red Hat OpenShiftNutanix Kubernetes Platform

The deployment sequence

  1. Prepare your infrastructure — a Kubernetes cluster, a container registry, and a MongoDB database. This is platform-specific; use the page for your platform below.
  2. Install with the Strong Installer CLI — pull the Helm chart, push images to your registry, and create the configuration file.
  3. Deploy to the cluster — install the ingress controller, upload the TLS secret, and apply the Helm chart.
  4. Configure the platform — identity, repositories, and access. See the table at the end of the install page.
Important:
Every deployment needs an ingress controller. The chart installs one for you only if you use NetScaler CPX™. Decide which controller you are using before you start, because it affects the cluster you build and how workspace SSH is exposed. See Ingress.

Choose your platform

Platform Page Notes
Amazon EKS Amazon EKS EKS, ECR, and MongoDB Atlas
Azure AKS Azure AKS AKS, ACR, and MongoDB Atlas or Cosmos DB
Google GKE Google GKE GKE Standard, Artifact Registry, and MongoDB Atlas. Autopilot is not supported
Red Hat OpenShift Red Hat OpenShift Self-contained guide, including the OpenShift-specific wildcard route policy
Nutanix Kubernetes Platform Nutanix Kubernetes Platform NKP 2.17 or later, with NetScaler CPX ingress
Self-hosted clusters and other managed distributions follow the same sequence: create the cluster, provide a registry and a database, then install. See System requirements for the supported Kubernetes versions and sizing.

Before you start

Requirement Detail
Domains A host domain, and a wildcard subdomain for proxy support such as *.proxy.example.com
TLS Certificates for both domains
Database MongoDB, hosted or in-cluster. See The SecurSpaces database
Registry A container registry you control, which the installer pushes images to
Sizing Node pools for the service and workspace tiers. See Sizing
Licence A SecurSpaces licence. See Licensing
For an evaluation rather than a production deployment, the 1-Click VM is considerably faster. See Deploy an evaluation environment.

Prepare for resource policies

Some clusters require every container to declare CPU and memory requests and limits. SecurSpaces sets resources for platform initialization, workspace initialization, data bucket jobs, and warm-node image caching. You must still configure enabled third-party components to match your policy.
The Helm setting platform.resourcePolicyCheck defaults to true. During a cluster-connected install or upgrade, the chart checks live Kyverno cluster and namespace policies for enforcing resource-limit rules. If it finds such a rule and an enabled third-party component lacks complete resources, rendering stops with a list of values to configure.
  1. Ask your cluster administrator which resource policies apply to the target namespace, including rules for initialization containers.
  2. Set CPU and memory requests and limits for each enabled component identified by the check. Select values appropriate to your workload, rather than copying platform-job defaults.
  3. Apply the Helm deployment with access to the target cluster.
  4. Confirm that pods and initialization containers start without resource-policy admission errors.
The check covers these third-party resource blocks when their components are enabled:
  • psmdb-operator.resources
  • perconaServerMongoDB.backup.resources
  • mongodb.resources
  • netscaler-cpx-with-ingress-controller.resources
  • netscaler-cpx-with-ingress-controller.nsic.resources
  • netscaler-cpx-with-ingress-controller.exporter.resources
  • metrics-server.resources
For the database migration job and node initialization DaemonSet, these are the default Helm values:
platform:
  podResources:
    dbBackfillJob:
      requests:
        cpu: 125m
        memory: 256Mi
      limits:
        cpu: 2000m
        memory: 4Gi
    sysctlFixer:
      requests:
        cpu: 10m
        memory: 32Mi
      limits:
        cpu: 1000m
        memory: 1Gi
sysctlFixer applies to both the initialization and resident containers. These settings don't remove privileged-container requirements or guarantee compliance with every admission policy.
Important:
Offline helm template, client-side dry runs, and GitOps rendering without cluster access can't inspect live Kyverno policies. Successful rendering in those environments isn't proof that the cluster will admit the workloads. If a detected policy doesn't apply, review that conclusion with your cluster administrator before setting platform.resourcePolicyCheck: false. Disabling the check doesn't disable admission.
The NetScaler CPX wait-for-config initialization container has no resource setting in the bundled chart. If your policy covers that container, arrange a narrowly scoped, approved policy exception before deployment.