Architecture & components
The OpenLM Platform is a microservices-based system designed for scalability, built as 100+ containerized services running on Kubernetes. This page explains what the system looks like at a high level before we get into sizing, networking, and deployment details.
Platform layers
The system is organized into the following layers:
- Kubernetes cluster: The foundation. All platform components run as containers orchestrated by Kubernetes, which handles scheduling, scaling, and self-healing.
- Ingress controller: Terminates TLS and acts as the cluster's entry point for external traffic. Traefik is the default and is installed automatically on K3s; nginx, Gateway API, and OpenShift routes are also supported.
- API gateway: Tyk, sitting behind the ingress. Applies gateway policies and routes each request to the correct microservice.
- Application microservices: The core platform – license usage collection, administration, identity and authentication, and all user-facing services.
- Reporting engine: A Spark-based ETL pipeline that processes usage data and outputs reporting tables into PostgreSQL or SQL Server. This data is then connected to Power BI for dashboards and reporting. Apache Superset is also available as an open-source alternative, though it is currently under development.
- Data services: Kafka (event streaming between microservices), MongoDB (document storage), SQL databases (operational and reporting data), and Redis (caching and sessions).
How it is deployed
The platform is delivered as an umbrella Helm chart – a single package containing all the Kubernetes manifests (Deployments, Services, ConfigMaps, Secrets) needed to run the system. It is composed of over 100 sub-charts, one per service. A values file is configured with environment-specific settings (domain, database connections, certificates, storage) and the platform is deployed or upgraded with a single Helm command – allow a longer-than-default timeout, since that many services take more than Helm's standard five minutes to become ready.
The chart and its values template are distributed in the deployment package; contact OpenLM to obtain it for your target version.
For the Platform as VM path, an Ansible-based installer does all of this for you: a single entrypoint.sh script bootstraps Python, Ansible, and Helm, then runs one playbook that installs K3s, the infrastructure services, and both Helm releases end to end.
For the AWS, Azure, and on-premise-machines paths, you run the Helm installs yourself against an existing cluster – see Platform installation.
Field agents
Three agents can be installed on machines across the organization to collect data and send it to the platform. In most deployments, at least the Broker is used as it provides the core functionality of reading license server events.
| Agent | Where it runs | What it does |
|---|---|---|
| Broker | On machines running license servers | Collects license server events and usage data |
| Workstation Agent | On end-user workstations | Collects workstation-level application usage |
| Directory Sync Agent (DSA) | On a machine with directory access | Scans and synchronizes directory data (Active Directory, LDAP) |
All agents communicate with the platform over HTTPS (port 443) to the same domain name. See Networking for details.