Requirements

To run OpenLM Platform on a single virtual machine or bare-metal server, prepare a clean RHEL-family machine, DNS, and a TLS certificate. The deployment script installs Kubernetes (K3s), the databases, the message broker, the cache, and all OpenLM services on top of the clean RHEL-family operating system. You don't need any Kubernetes, Ansible, or Helm experience to run it.

This page lists what you need in place before you start. For the install, see Deployment.

Licensing

A valid OpenLM license is required to use OpenLM Platform. Contact sales@openlm.com to obtain or extend a license before deploying to production.

System requirements

The following table lists the minimum and recommended resources:

Resource	Minimum (evaluation)	Recommended (production)
CPU	4 vCPU	8+ vCPU
RAM	32 GB	64 GB
Storage	200 GB free SSD	500 GB+ SSD
Network	100 Mbps	1 Gbps

The installer checks CPU and RAM before it does anything else and fails immediately if either falls short. Network throughput figures are guidance for image pulls and agent traffic, not enforced values.

Disk space is not checked

The installer does not verify free disk space. An undersized disk installs successfully and then fails later with pod evictions under disk pressure, which is much harder to diagnose. Confirm you have 200 GB free on the filesystem holding /var/lib/rancher before you start.

Warning

The minimum specification is suitable for evaluation, demo, and proof-of-concept (POC) environments with low load. For production use with active Brokers and users, use the recommended specification or higher.

Operating system

The following operating systems are supported:

• Officially supported: RHEL 9, AlmaLinux 9, or Rocky 9 (RHEL-family 9.x).
• Actively validated: AlmaLinux 9. Use it if you have no existing preference.

Ubuntu, Debian, and SUSE are not supported. Older RHEL-family major versions (7 and 8) and RHEL-family 10 are not officially validated.

Note

The installer only checks that the OS is RHEL-family. It does not check the major version. The installer therefore starts on RHEL-family 8 or 10, but those versions are untested and unsupported.

User account

You need a non-root user account on the VM with sudo privileges. The installer prompts for the sudo password twice: once at the start, when it installs OS packages, and again when the Ansible playbook starts a few minutes later. Stay at the terminal until the playbook is running.

Network requirements

The VM needs outbound access during installation and inbound ports during operation.

Outbound (during installation)

The VM needs outbound HTTPS access to the following hosts so the installer can pull Kubernetes, container images, and Helm charts:

• Your distribution's package mirrors: The installer runs dnf update and installs Python 3.12.
• pypi.org, files.pythonhosted.org: Ansible and its Python dependencies.
• get.k3s.io: K3s installer.
• get.helm.sh: Helm binary.
• public.ecr.aws: OpenLM container images.
• docker.io: Infrastructure container images (Redis, Kafka, MongoDB, MariaDB, PostgreSQL), published under the bitnamilegacy repositories.
• openlm-helm.github.io: Umbrella chart sub-chart metadata, during the OpenLM Platform chart install.

If the VM is behind an HTTPS proxy, set HTTPS_PROXY and NO_PROXY in your shell before running the installer.

After installation

public.ecr.aws and docker.io remain required for the life of the deployment so that images can be pulled when pods are rescheduled, restarted, or upgraded. The rest are needed only during installation.

Inbound (during operation)

Open the following ports on whatever firewall sits in front of the VM:

Port	Source	Purpose
443	End users	HTTPS for the OpenLM Platform UI and APIs
80	End users	HTTP redirect to 443
6443	Admins	Kubernetes API (for kubectl access from off-VM)
30432	BI tools	Reporting database (PostgreSQL) for Power BI and similar
22	Admins	SSH

Open 80, 443, and 30432 in the VM's own firewalld

The installer configures firewalld on the VM, but it opens only port 6443 (the Kubernetes API). It does not open the ports that carry OpenLM Platform traffic, so after a successful install the UI is still unreachable until you open them yourself:

sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --permanent --add-port=30432/tcp   # Only if BI tools need the reporting DB
sudo firewall-cmd --reload

DNS

You need a fully qualified domain name (FQDN) that resolves to the VM, such as openlm.yourcompany.com. Create an A record pointing the FQDN at the VM's IP address before running the installer.

Verify resolution from a client machine (not from the VM itself):

dig openlm.yourcompany.com +short
# Should print the VM's IP address.

If the VM is in an air-gapped network where you cannot publish a DNS record, see the add_coredns_hosts_entry pattern in the configuration reference.

TLS certificate

You need a TLS certificate and matching private key in PEM format. This can be:

• A certificate from a public certificate authority (CA), for example Let's Encrypt or DigiCert
• A certificate from your internal or corporate CA
• A self-signed certificate (acceptable for evaluation, but browsers show a warning)

The certificate's Common Name or Subject Alternative Name must cover the FQDN you configured.

Verify the certificate and key match before installation:

openssl x509 -noout -modulus -in tls.crt | md5sum
openssl rsa  -noout -modulus -in tls.key | md5sum

The two outputs must be identical.

Capacity considerations

This deployment path is designed for small customer environments, evaluation, and POC. All services share a single machine, so the load the system can handle has a practical cap compared to a multi-node cluster deployment.

If the environment outgrows the single-VM capacity, consider migrating to one of the multi-node deployment paths: On-premises machines, AWS, or Azure.