Deployment paths
To choose where to deploy OpenLM Platform, compare the four deployment paths. Each path determines where Kubernetes runs, how infrastructure services are provisioned, and what you manage. For background, see Architecture, System requirements, and Networking.
Compare the deployment paths
The following table lists the four paths and what each one uses:
| Path | Kubernetes | Infrastructure services | Best suited for |
|---|---|---|---|
| Platform as VM | K3s (automated) | All automated on a single VM | Small customers, demos, proof of concept (POC), and evaluation environments |
| On-premises machines | Any Cloud Native Computing Foundation (CNCF) conformant distribution on your own servers | All self-hosted in-cluster | Organizations with existing data centers and Kubernetes expertise |
| Private cloud (AWS) | Amazon EKS (managed) | AWS managed services, in-cluster charts, or a mix | Organizations on AWS, or those without existing data center infrastructure |
| Private cloud (Azure) | Azure AKS (managed) | Mix of Azure managed and in-cluster | Organizations on Azure |
If your organization does not have an existing data center or dedicated infrastructure team, deploy on a cloud provider. Cloud-managed Kubernetes and data services significantly reduce operational overhead.
AWS is the best-supported cloud path. It has the most managed service coverage (RDS, MSK, ElastiCache), a Terraform reference configuration for infrastructure-as-code provisioning, and the most deployment experience within OpenLM.
Platform as VM
Use the Platform as VM path for small customers, demos, and evaluation environments. A single deployment script transforms a clean AlmaLinux 9, RHEL 9, or Rocky Linux 9 installation into a fully operational OpenLM Platform, and you need no Kubernetes or infrastructure expertise.
The script automates everything: K3s installation, database provisioning (MariaDB, PostgreSQL, MongoDB), Kafka, Redis, schema initialization, and OpenLM Platform service deployment. The result is a ready-to-use system on a single machine.
The script manages everything: Kubernetes, all databases, Kafka, Redis, MongoDB, schema creation, Kafka topics, and OpenLM Platform services.
You provide a VM or bare-metal server running AlmaLinux 9, RHEL 9, or Rocky Linux 9, a domain name, and a TLS certificate. AlmaLinux 9 is the actively validated option. RHEL-family 8 and 10 are not supported, and neither are Ubuntu, Debian, or SUSE.
The following table lists the minimum and recommended resources:
| Resource | Minimum (evaluation) | Recommended |
|---|---|---|
| CPU | 4 cores | 8+ cores |
| RAM | 32 GB | 64 GB |
| Storage | 200 GB SSD free | 500 GB+ SSD |
This path trades scalability for simplicity. All services share a single machine, so the system has a practical cap on the load it can handle. If the environment outgrows the single-VM capacity, consider migrating to one of the multi-node deployment paths described in the following sections.
For detailed requirements, see Platform as VM requirements.
For deployment steps, see Platform as VM deployment.
On-premises machines
The on-premises path runs everything on bare-metal servers or virtual machines that you manage. Kubernetes and all infrastructure services are installed on your hardware.
You manage everything: servers, OS, Kubernetes, databases, Kafka, Redis, MongoDB, networking, and certificates.
This path requires a team with Kubernetes and Linux administration experience. All infrastructure services run inside the cluster on a dedicated infrastructure node.
The following table lists the option for each service:
| Service | Option |
|---|---|
| SQL database | SQL Server, or MariaDB or MySQL and PostgreSQL (in the cluster) |
| Kafka | In-cluster |
| Redis | In-cluster |
| MongoDB | In-cluster |
On Red Hat OpenShift, you don't install Kubernetes yourself. See Red Hat OpenShift for the settings that differ from this path.
For detailed hardware requirements, see On-premises machines requirements.
For deployment steps, see On-premises machines environment setup.
Private cloud (AWS)
The AWS path uses Amazon EKS for Kubernetes and, where you want them, AWS managed services for the infrastructure components. This reduces what you operate while keeping everything within your own AWS account. OpenLM Platform needs only the endpoints of SQL Server, Kafka, Redis, and MongoDB, so each of them can also run in the cluster from the charts in the deployment package. Use Amazon MSK for Kafka. When your organization can't, run the same in-cluster Kafka as on the on-premises path.
AWS can manage the Kubernetes control plane, SQL Server (RDS), Kafka (MSK), and Valkey (ElastiCache).
You still manage the AWS account, networking and the virtual private cloud (VPC), EKS node groups, MongoDB (Atlas or in-cluster), and every service you run in the cluster instead of as a managed service.
The following table lists the option and status for each service:
| Service | Option | Status |
|---|---|---|
| SQL database | Amazon RDS for SQL Server | Supported |
| Kafka | Amazon MSK (recommended), or Kafka in the cluster from the deployment package | Supported. For MSK, ask OpenLM for the SASL/SCRAM connection settings, which the install guide doesn't cover. |
| Redis | Amazon ElastiCache for Valkey | Supported |
| MongoDB | MongoDB Atlas or in-cluster | Supported (DocumentDB is not supported) |
A Terraform reference configuration is available to provision the full AWS environment (VPC, EKS, RDS, MSK, ElastiCache, KMS, IAM) as infrastructure-as-code. It creates MSK in every case, so leave that part out when you run Kafka in the cluster.
For detailed sizing and costs, see AWS infrastructure requirements.
For deployment steps, see AWS environment setup.
Private cloud (Azure)
The Azure path uses AKS for Kubernetes with managed services for SQL and cache. Kafka and MongoDB run inside the cluster or through third-party managed services.
Azure can manage the Kubernetes control plane, the SQL database (SQL Managed Instance), and Redis (Azure Cache).
You still manage the Azure subscription, networking and the virtual network (VNet), AKS node pools, Kafka, and MongoDB.
The following table lists the option and status for each service:
| Service | Option | Status |
|---|---|---|
| SQL database | Azure SQL Managed Instance | Supported |
| Redis | Azure Cache for Redis | Supported |
| Kafka | Confluent Cloud or in-cluster | Event Hubs with Kafka layer not supported |
| MongoDB | MongoDB Atlas or in-cluster | Cosmos DB not supported |
Kafka and MongoDB can be provisioned through marketplace offerings (Confluent Cloud, MongoDB Atlas) billed through your Azure subscription, or deployed inside the Kubernetes cluster using the included Helm charts.
For detailed sizing, see Azure infrastructure requirements.
For deployment steps, see Azure environment setup.
SQL database options
Regardless of deployment path, you can configure the SQL layer in two ways:
- Option A, a single SQL Server instance: Use one SQL Server for operational, identity, and reporting databases.
- Option B, MariaDB or MySQL and PostgreSQL: Use MariaDB or MySQL for operational and identity databases, and PostgreSQL for reporting.
Option B exists because of these engine limits:
- Operational services support MariaDB, MySQL, or SQL Server.
- The reporting engine (Spark ETL) supports only SQL Server or PostgreSQL.
Select based on your existing database expertise and licensing.
The documentation team might draft this page using a large language model. A technical writer reviews every page and verifies it against the product before publishing it. A human makes the final decision.