This document describes the recommended technical process for deploying the Parallel Works ACTIVATE control plane into a customer-managed, self-hosted Kubernetes environment such as Red Hat OpenShift. The guide reflects a production-oriented deployment model and preserves flexibility for customer-specific infrastructure and security requirements. Parallel Works will provide validated Helm charts and Kubernetes manifests as part of the deployment engagement.
The following diagram illustrates the deployment architecture for ACTIVATE on Kubernetes:
The following tables outline the minimum resource requirements for deploying ACTIVATE.
| Deployment Size | Nodes | CPU per Node | RAM per Node | Total CPU | Total RAM |
|---|---|---|---|---|---|
| Minimum | 3 | 4 cores | 16 GiB | 12 cores | 48 GiB |
| Recommended | 5 | 8 cores | 32 GiB | 40 cores | 160 GiB |
Equivalent instance types: AWS m5.xlarge (minimum) / m5.2xlarge (recommended), GCP n2-standard-4 / n2-standard-8.
At defaultScale: 1, the ACTIVATE platform services require approximately:
| Category | CPU | Memory | Persistent Storage |
|---|---|---|---|
| Core platform services | 6 cores | 6 GiB | — |
| Background workers | 7 cores | 11 GiB | 11 GiB |
| Supporting services (message queue, secrets) | 2 cores | 4 GiB | 3 GiB |
| Billing and usage | 2.5 cores | 4 GiB | — |
| Total | 17.5 cores | 25 GiB | 14 GiB |
Additional headroom is required for Kubernetes system pods (CoreDNS, kube-proxy, CNI) and the database services below.
| Database | CPU | Memory | Storage |
|---|---|---|---|
| PostgreSQL | 2 cores | 6 GiB | 50 GiB |
| MongoDB (3-node replica set) | 2 cores per node | 4 GiB per node | 50 GiB |
A shared filesystem with ReadWriteMany access is required for platform file storage:
| Purpose | Minimum Size | Access Mode |
|---|---|---|
| User uploads, media, and workflow assets | 10 GiB | ReadWriteMany |
Additional ReadWriteOnce volumes (~10 GiB total) are provisioned automatically for internal caching and message queue data.
Supported shared storage backends include AWS EFS, GCP Filestore, or any other NFS or ReadWriteMany-capable storage class.
Before beginning the deployment, ensure the following requirements are met:
ACTIVATE relies on several supporting services for metadata, billing, and secret management. These services are deployed into the cluster using Helm charts and Kubernetes manifests provided by Parallel Works.
The ACTIVATE control plane is deployed via Helm and a custom Kubernetes resource managed by the Parallel Works operator.
pw-systemReadWriteMany access modeCreate Kubernetes secrets in the core platform namespace for the following:
Add the Parallel Works Helm repository and install the operator:
helm repo add corerepo https://parallelworks.github.io/helm
helm upgrade --install parallelworks-operator corerepo/operator \
--namespace pw-operator-system \
--create-namespaceDeploy the ACTIVATE platform by applying a ParallelWorks custom resource. This resource defines image versions, scaling defaults, ingress configuration, TLS, and database connectivity. Key configuration elements include:
Parallel Works will provide a validated YAML manifest customized for the customer environment. See Sample Configuration below for a YAML example.
Once applied, the operator provisions all ACTIVATE services into the designated core namespace (for example pw-system). This namespace hosts the control plane components and ingress services.
User workspaces are isolated into a separate namespace. Each user is assigned a dedicated Kubernetes StatefulSet that manages a single pod. Pods are scaled up when the user is active and scaled down when idle.
Each user workspace is provisioned with the following default resource allocation:
| CPU | Memory | |
|---|---|---|
| Requests | 500m | 512 MiB |
| Limits | 1 core | 2 GiB |
These values are configurable per user through the ACTIVATE platform.
Each user is provisioned a 5 GiB home directory. Storage can be configured in one of two modes through the platform:
An ingress controller or external load balancer must be configured to expose port 443 to the ACTIVATE ingress service running in the core platform namespace.
After ingress is operational, access the ACTIVATE web interface via HTTPS on the configured domain.
The initial setup workflow allows you to:
Once completed, the platform is ready for user onboarding and workspace provisioning.
Below is a sample ParallelWorks custom resource YAML configuration:
---
apiVersion: v1
kind: Namespace
metadata:
name: <namespace>
---
apiVersion: platform.parallelworks.com/v1alpha1
kind: ParallelWorks
metadata:
name: <deployment-name>
namespace: <namespace>
spec:
image:
registry: <registry-url>
repositoryPrefix: <repository-prefix>
tag: <version>
pullPolicy: IfNotPresent
pullSecrets:
- name: <image-pull-secret-name>
# Default scale for all services that don't specify their own replicas
defaultScale: 1
# Ingress hostname for the platform
host: <your-domain>
# TLS certificate secret
tlsSecretName: <tls-secret-name>
# Database configuration
database:
postgres:
endpoint: '<postgres-host>:<postgres-port>'
database: '<database-name>'
username: '<username>'
urlSecretRef:
name: '<postgres-secret-name>'
key: '<password-key>'
mongodb:
replicaSetName: '<replica-set-name>'
endpoints:
- '<mongodb-node-0-host>:27017'
- '<mongodb-node-1-host>:27017'
- '<mongodb-node-2-host>:27017'Customization
This is a sample configuration. Parallel Works will provide a validated and customized manifest tailored to your specific environment during the deployment engagement.
After completing the deployment:
For additional assistance, please contact Parallel Works support or your deployment engineer.