Infrastructure requirements

To plan machines for OpenLM Platform on bare-metal servers or virtual machines that you manage, use these hardware and software requirements.

How the cluster is organized

OpenLM Platform runs on Kubernetes and is made up of 100+ microservices, data infrastructure (databases, message broker, cache), and a reporting engine. To keep the system stable and reliable, workloads are split across dedicated node groups, each with a clear responsibility. This separation keeps resource-heavy processes like reporting from competing with the core application, and keeps critical data services isolated from application load.

The cluster uses four node roles. Each role runs on its own set of machines. Roles are not combined.

Control plane

The control plane node runs only the Kubernetes system processes (API server, etcd, scheduler, controllers) and the ingress controller. It is tainted so that no application workloads are scheduled on it. This is a hard requirement. Keeping the control plane free from application load ensures cluster stability and reliable ingress routing.

Main workload

The main workload nodes run the OpenLM application microservices, the API gateway, and telemetry. This is where the core OpenLM Platform logic runs: license management, identity, administration, and all user-facing services.

Reporting workload

The reporting nodes are dedicated to the Spark ETL engine and reporting services. Spark processes usage data and outputs reporting tables into PostgreSQL or SQL Server, which customers rely on for dashboards and compliance reporting. Spark is resource-intensive, so it runs on its own nodes to avoid competing with the core application for CPU and memory.

Infrastructure

The infrastructure node runs all data services: Kafka (message broker), MongoDB, MariaDB or MySQL (operational databases), PostgreSQL or SQL Server (reporting database), and Redis (cache). These are the most critical components in the system. If any of them go down, OpenLM Platform stops functioning. Isolating them on a dedicated node with SSD storage protects them from application I/O and ensures consistent database performance.

Node specifications

This is the minimum layout for a stable production deployment under small-to-medium load. The 8-node configuration is the baseline. Kubernetes requires a healthy number of nodes to maintain reliability, schedule workloads effectively, and handle node failures.

The following table lists the node roles and their sizes:

Role	Count	vCPU	RAM	Storage	Notes
Control plane	1	4	8 GB	50 GB	Tainted, no application workloads
Main workload	3	8	16 GB	50 GB	Core platform microservices
Reporting workload	3	8	16 GB	50 GB	Spark ETL and reporting services
Infrastructure	1	8	32 GB	300 GB (SSD)	Databases, Kafka, Redis

In total, the layout uses 8 nodes, 60 vCPUs, 136 GB RAM, and 650 GB storage.

Note

The infrastructure node requires SSD storage for database performance. All other nodes need only 50 GB for the OS and container images. They store no persistent data.

Infrastructure services

The following services run on the infrastructure node:

Service	Purpose	Approximate storage
Kafka	Event streaming between microservices	100 GB+
MongoDB	Document storage	20 GB+
MariaDB or MySQL	Operational and identity databases	50 GB+
PostgreSQL or SQL Server	Reporting database (Spark ETL output)	50 GB+
Redis	Caching and session storage	Minimal

Total persistent storage: 250 to 400 GB on the infrastructure node.

Operating system

Use an RHEL-based distribution:

• Preferred: AlmaLinux 9
• Alternatives: RHEL 9 or Rocky Linux 9

Kubernetes distribution

Any Cloud Native Computing Foundation (CNCF) conformant Kubernetes distribution is supported for on-premises deployments (for example, MicroK8s, kubeadm, RKE2, K3s). Red Hat OpenShift is supported too. For the settings it needs, see Red Hat OpenShift.

Minimum Kubernetes version: 1.29.

Storage class

A local-path or equivalent storage provisioner is needed for persistent volumes, isolated to the infrastructure node.

Network requirements

For detailed port tables, firewall rules, and network topology, see Networking.

The network requirements are:

• All nodes must reside on the same L2 network or have full inter-node connectivity.
• Ports 80 and 443 must be open on the control plane node for ingress.
• Inter-node ports 6443 (API), 8472 (VXLAN), 10250 (kubelet), and 51820 (WireGuard) must be open.
• A DNS A record must point your domain to the control plane node IP.
• Outbound access to public.ecr.aws/r3q3q2f4 (OpenLM images), docker.tyk.io (API gateway images), and docker.io (in-cluster infrastructure images: Kafka, MariaDB, MongoDB, PostgreSQL, Redis, and the gateway's busybox init container). An allowlist with only the OpenLM registry leaves the infrastructure services and the gateway in ImagePullBackOff.

Sizing notes

Review the following sizing guidelines:

• This is the baseline for a stable production system under small-to-medium load.
• Increase worker node count for higher Broker counts or user volumes.
• Increase infrastructure node storage for longer data retention periods.
• Monitor resource utilization after deployment and scale accordingly.