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:
Before beginning the deployment, ensure the following requirements are met:
ACTIVATE relies on several supporting services for identity, 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 <repository-url>
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, for example pw-users.
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: pw-system
---
apiVersion: platform.parallelworks.com/v1alpha1
kind: ParallelWorks
metadata:
name: customer
namespace: pw-system
spec:
image:
registry: ghcr.io
repositoryPrefix: parallelworks
tag: v5.203
pullPolicy: IfNotPresent
pullSecrets:
- name: image-pull-secret
# Default scale for all services that don't specify their own replicas
# Services default to enabled=true, so you only need to specify services
# if you want to customize them or disable them
defaultScale: 1
# Host is the ingress hostname for the platform
host: customer.parallel.works # can be your own domain
# TLSSecretName for TLS certificate
tlsSecretName: pw-tls-secret
# Database configuration
database:
# PostgreSQL configuration
postgres:
endpoint: 'pw-pgsql-service.postgres.svc.cluster.local:5432'
database: 'pworks'
username: 'postgres'
urlSecretRef:
name: 'postgres-secret'
key: 'password'
# MongoDB configuration (no authentication configured)
mongodb:
replicaSetName: 'rs0'
endpoints:
- 'mongodb-0-external.mongo.svc.cluster.local:27017'
- 'mongodb-1-external.mongo.svc.cluster.local:27017'
- 'mongodb-2-external.mongo.svc.cluster.local: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.