Deployment

The Platform as VM deployment uses a single script that transforms a clean RHEL-family operating system into a fully operational OpenLM Platform. The script handles K3s installation, database provisioning, schema initialization, Kafka topic creation, and platform service deployment automatically.

Make sure you have completed everything on the Requirements page before starting.

What the script does

The installer runs an Ansible playbook that:

1. Verifies prerequisites (operating system family, RAM, CPU).
2. Installs and configures firewalld, opening the Kubernetes API port (6443).
3. Installs K3s as a lightweight Kubernetes environment, with Traefik as the ingress controller.
4. Creates the cluster namespaces, stores your TLS certificate as a Kubernetes secret, and loads the same certificate into an in-cluster trust bundle mounted by every service.
5. Deploys the infrastructure services: Redis, Kafka, MongoDB, and the operational and reporting databases.
6. Initializes the operational database schema, and the reporting schema when the reporting database is the bundled PostgreSQL.
7. Creates the Kafka topics required by the platform.
8. Deploys the OpenLM API gateway and the OpenLM Platform services.

note

Step 6 applies the reporting schema scripts only to the bundled PostgreSQL. If you configured an external SQL Server for reporting, you must create that schema yourself – see the Configuration reference.

Total install time is 20 to 40 minutes, dominated by the initial container image pulls.

Deployment steps

1. Download the deployment package

Get the release archive directly from OpenLM: platform-as-vm-20260514-171145-1b03d94.zip. The filename follows the pattern platform-as-vm-<date>-<commit>.zip, where <date> is the build date and <commit> the source revision.

Version-specific link

That link points at one specific build – there is no "latest" alias. Contact OpenLM to confirm you are installing the current release before you deploy, and to obtain the release notes for it. Upgrades work by obtaining a newer bundle and re-running the installer, so keep track of which build you deployed.

Unzip it on your workstation:

unzip platform-as-vm-*.zip

This produces a platform-as-vm/ directory containing the installer scripts, Helm charts, Ansible playbook, and database schemas.

(Optional) Print the archive's SHA-256 checksum so you can confirm it with OpenLM before installing:

sha256sum platform-as-vm-*.zip

2. Transfer the deployment package

Copy the unzipped platform-as-vm/ directory to the target VM:

scp -r platform-as-vm/ <user>@<vm-ip>:~/

3. Place the TLS certificate

SSH into the VM and put your certificate and key at the paths you will reference in config.yaml. The default locations are:

sudo mkdir -p /etc/openlm/certs
sudo cp tls.crt /etc/openlm/certs/tls.crt
sudo cp tls.key /etc/openlm/certs/tls.key
sudo chmod 600 /etc/openlm/certs/tls.key

You can store the files anywhere – just update the corresponding paths in config.yaml.

4. Edit config.yaml

Open ~/platform-as-vm/config.yaml and set the three required fields:

openlm_system_domain: "openlm.yourcompany.com"        # Your OpenLM FQDN
tls_cert_path:        "/etc/openlm/certs/tls.crt"    # Path to the TLS certificate
tls_key_path:         "/etc/openlm/certs/tls.key"    # Path to the TLS private key

Every other field has a sensible default for a single-VM deployment. See the Configuration reference for advanced patterns such as external SQL Server, external Kafka, or air-gapped installations.

5. Edit passwords.yaml

Open ~/platform-as-vm/passwords.yaml and set strong passwords for the three bundled databases:

postgres_password:     "<a strong password>"
mariadb_root_password: "<a different strong password>"
mongodb_root_password: "<another strong password>"

warning

These passwords are baked in when the databases are initialized. Changing them in passwords.yaml after the first install does not update the running databases. Treat them as one-time-set values and rotate them later using each database's native commands.

6. Run the installer

From inside the deployment directory:

cd ~/platform-as-vm
chmod +x entrypoint.sh
./entrypoint.sh

The script prompts for your sudo password twice:

1. Immediately, when it updates OS packages and installs Python.
2. Again when the Ansible playbook starts, as a separate BECOME password: prompt – this can be several minutes later, after the package, pip, and Helm installs finish.

Stay at the terminal until the playbook is running. After the second prompt it runs end-to-end without further input.

If the installer fails partway through, fix the cause and re-run ./entrypoint.sh. The playbook is idempotent: it re-checks every step and skips the work already done rather than starting over. It does not resume from a saved position, so expect the early steps to be re-evaluated (quickly) on each run.

Verify the deployment

Check pods

kubectl get pods -A

You should see:

• kube-system – all pods Running (CoreDNS, Traefik, metrics-server, local-path-provisioner).
• openlm-infrastructure – all pods Running (Redis, Kafka, MongoDB, MariaDB, PostgreSQL).
• openlm – approximately 100 pods, most Running. A handful may stay in Init or ContainerCreating for a few minutes after the installer exits – this is normal while services pull images and wait for their dependencies.

If pods stay in CrashLoopBackOff after 15 minutes, see Troubleshooting.

Check Helm releases

helm list -A

Seven releases should be present, each showing STATUS: deployed:

Namespace	Releases
openlm-infrastructure	redis, mariadb, mongodb, postgres, kafka
openlm	openlm-gateway, openlm-platform

Fewer releases than this, or any release not in deployed state, means a step failed – check Troubleshooting.

Open the platform

Open https://<your-domain>/ in a browser. The OpenLM login page should appear.

If you see a browser TLS warning, it means your certificate is self-signed or from a CA the browser does not trust – that is expected for those cases.

First login

Reaching the login page means the deployment succeeded, but you cannot sign in yet. The installer deploys the platform without creating any users or roles, and it sets no default administrator password – authentication is handled entirely by the OpenLM identity service.

To get from the login page to a working platform:

1. Contact OpenLM for the initial administrator credentials for your deployment.
2. Configure the identity service for your organization – to federate against Active Directory, LDAP, or an SSO provider, see the OpenLM Identity Service configuration guides.
3. Create your own users and roles from the platform's administration UI.

Wire up Power BI (optional)

To connect Power BI or another BI tool to the reporting database:

Setting	Value
Server	<vm-ip-or-fqdn>:30432
Database	openlm_reporting_db
Username	postgres
Password	The postgres_password you set in passwords.yaml

In Power BI Desktop, select Get Data → PostgreSQL database, enter the server and database, then provide the credentials.

What's next

• Operate the platform – Operations covers health checks, logs, backups, and upgrades.
• Tune the configuration – Configuration reference covers external SQL Server, external Kafka, and other patterns.
• Run into an issue – Troubleshooting lists the most common problems and how to fix them.