Configuration reference

All customer-facing configuration lives in two files at the root of the deployment package:

• config.yaml: OpenLM Platform configuration (domain, databases, ingress, and more)
• passwords.yaml: Passwords used by the bundled databases

The installer reads both files and renders them into Helm chart values and Kubernetes secrets at install time. Running the installer again renders everything from the current files.

Required fields

Set these three fields. The installer stops if they are empty.

openlm_system_domain: "openlm.yourcompany.com"    # FQDN used to access the platform
tls_cert_path:        "/etc/openlm/certs/tls.crt"
tls_key_path:         "/etc/openlm/certs/tls.key"

Every other field has a default that works for a single-VM, all-bundled deployment.

Database options

OpenLM Platform uses two database roles:

• Operational: live state, identity, allocations. High write throughput, small queries.
• Reporting: historical usage and ETL output for BI tools. Large analytical queries.

Each role can use one of these backends:

Back end	Mode	Valid for	Notes
MariaDB	Bundled	Operational	Default for operational
PostgreSQL	Bundled	Reporting only	Default for reporting. Not a valid operational or identity back end.
SQL Server	External	Either role	Customer-supplied
MySQL	External	Operational only	Customer-supplied

Recommended patterns

Use one of these two patterns:

1. All-bundled: operational on MariaDB, reporting on PostgreSQL. Self-contained, nothing extra to manage. Use this if you have no SQL Server infrastructure or DBA team.
2. All-external on SQL Server: both roles on the same external SQL Server instance, in separate databases. Use this if you already run a SQL Server fleet.

Mixing bundled and external is supported but uncommon.

Reporting database

Set the reporting database fields in config.yaml:

reporting_db_type:     "PostgreSQL"    # or "SqlServer_SQLServerAuth"
reporting_db_host:     "postgres-postgresql.openlm-infrastructure.svc.cluster.local"
reporting_db_port:     5432
reporting_db_username: "postgres"
reporting_db_password: "GENERATED"     # Substituted from passwords.yaml
reporting_db_name:     "openlm_reporting_db"

When using external SQL Server, set reporting_db_password to the real password (not GENERATED), and either pre-create the database or grant the user permission to create it. The bundled PostgreSQL is not installed when the type is SqlServer_SQLServerAuth.

Schema bootstrap is yours on external SQL Server

The installer applies the reporting schema scripts only to the bundled PostgreSQL. When reporting_db_type is SqlServer_SQLServerAuth it skips that step entirely, so creating the reporting schema is the customer's responsibility.

Operational database

Set the operational database fields in config.yaml:

operational_db_type:     "MariaDB"     # Options: MariaDB, MySQL, SqlServer_SQLServerAuth
operational_db_host:     "mariadb.openlm-infrastructure.svc.cluster.local"
operational_db_port:     3306
operational_db_username: "root"
operational_db_password: "GENERATED"
operational_db_name:     "openlm_operational_db"
identity_db_name:        "openlm_identity_db"
dss_db_name:             "openlm_dss_db"

The operational role uses three logical databases: operational, identity, and DSS. With the bundled MariaDB, all three are created automatically.

The operational database name gets a _none suffix

operational_db_name is a prefix, not the database name OpenLM Platform connects to. OpenLM Platform connects to <operational_db_name>_none. With the default value, that is openlm_operational_db_none.

The bundled MariaDB creates the suffixed database for you. On an external SQL Server, the DBA must create it under the suffixed name. A database created as openlm_operational_db leaves OpenLM Platform unable to connect.

The identity and DSS databases use identity_db_name and dss_db_name exactly as configured, with no suffix.

Message broker (Kafka)

Set the Kafka fields in config.yaml:

kafka_bootstrap_servers: "kafka.openlm-infrastructure.svc.cluster.local:9092"

# Only set the SASL fields when connecting to an external/managed Kafka:
kafka_sasl_mechanism:         ""    # e.g. ScramSha512
kafka_sasl_username:          ""
kafka_sasl_password:          ""
kafka_security_protocol:      ""    # e.g. SASLSSL
kafka_ssl_endpoint_algorithm: ""    # e.g. https
kafka_consumer_timeout_ms:    ""    # e.g. 6000

• Default: Bundled Kafka inside the cluster, no authentication.
• External Kafka: Set kafka_bootstrap_servers to the external endpoint and fill in the SASL fields. Contact OpenLM support if you also want to turn off the bundled Kafka.

kafka_consumer_timeout_ms overrides the consumer poll timeout. Leave it empty unless OpenLM support asks you to raise it for a high-latency managed broker.

Document store (MongoDB)

Set the MongoDB connection string in config.yaml:

mongo_connection_string: "mongodb://admin:GENERATED@mongodb.openlm-infrastructure.svc.cluster.local:27017"

The literal string GENERATED is replaced at install time with mongodb_root_password from passwords.yaml. External MongoDB is not a supported configuration. OpenLM Platform expects the bundled MongoDB.

Warning

Don't end the MongoDB connection string with a trailing /. Some clients reject it.

Cache (Redis)

Set the Redis connection string in config.yaml:

redis_connection_string: "redis-master.openlm-infrastructure.svc.cluster.local:6379"

Redis runs cluster-internal with no authentication. External Redis is not a supported configuration.

Ingress

Set the ingress fields in config.yaml:

ingress_type:       "traefik"    # Options: traefik, nginx, gateway-api, openshift
ingress_class_name: "traefik"

traefik is the default and is installed with K3s, so the default values need no changes on a standard VM deployment.

The other options exist for clusters that already run their own ingress layer. If you set one of them, the corresponding controller must already be installed and ready before you run the installer. The installer does not deploy it for you. On K3s you also need to turn off the bundled Traefik, otherwise two controllers compete for ports 80 and 443.

ingress_class_name must match the IngressClass your controller registers (for example nginx for the ingress-nginx controller).

Node affinity

Set the node affinity labels in config.yaml:

affinity_label_main_workload:      ""
affinity_label_reporting_workload: ""

Leave both empty for Platform as VM, because everything runs on the single node. They exist for multi-node clusters that pin the main and reporting workloads to dedicated node pools.

Storage class

Set the storage class in config.yaml:

k8s_storage_class: "local-path"

local-path is the K3s default and stores persistent volume data on the VM's local disk. This is the right choice for a single-VM deployment and is automatically backed up when you snapshot the VM.

If you have a different provisioner already installed on the host (NFS, Longhorn, Ceph), you can switch it here. Confirm that it is installed and ready before you run the installer.

This setting does not move the databases

k8s_storage_class applies only to the OpenLM Platform services' persistent volume claims. The bundled MariaDB, PostgreSQL, MongoDB, Kafka, and Redis charts are pinned to local-path and ignore this setting, so their data stays on the VM's local disk regardless of what you set here.

Air-gapped network without DNS

If the VM is on a network with no DNS server that can host your OpenLM Platform domain, the installer can patch K3s's internal DNS so the domain resolves correctly inside the cluster. Set these values in config.yaml:

openlm_system_domain: "openlm.internal"
tls_cert_path:        "/etc/openlm/certs/tls.crt"
tls_key_path:         "/etc/openlm/certs/tls.key"

add_coredns_hosts_entry: true
coredns_hosts_entry_ip:  "10.20.30.40"    # The VM's IP

End users still need a way to reach the VM: its IP address, a hosts file entry on each client, or your own internal DNS server.

Passwords file

Set the passwords in passwords.yaml:

postgres_password:     "changeme"
mariadb_root_password: "changeme"
mongodb_root_password: "changeme"

These passwords are used to:

1. Initialize the bundled databases at install time.
2. Configure the OpenLM Platform services to connect with those passwords.

If a database is not used (for example, when reporting_db_type is SqlServer_SQLServerAuth), its password value is ignored.

Passwords are set at install time

Passwords are set when the databases are first created. Changing passwords.yaml after the install doesn't update the running databases. Rotate the passwords with each database's own commands afterwards.

Full configuration examples

The following patterns show complete config.yaml examples.

Default single-VM setup with everything bundled

This is the simplest deployment. Everything runs on one VM, including the databases. Set these values in config.yaml:

openlm_system_domain: "openlm.yourcompany.com"
tls_cert_path:        "/etc/openlm/certs/tls.crt"
tls_key_path:         "/etc/openlm/certs/tls.key"
# Everything else: defaults

External SQL Server for both database roles

Use this pattern if you already have a SQL Server instance. The bundled PostgreSQL and MariaDB are not installed. The DBA must pre-create the four databases (or grant create rights to the application user), and must also create the reporting schema.

With the values in this pattern, the four databases to create are:

Database	Name to create
Operational	openlm_operational_db_none (note the _none suffix)
Identity	openlm_identity_db
DSS	openlm_dss_db
Reporting	openlm_reporting_db

Set these values in config.yaml:

openlm_system_domain: "openlm.yourcompany.com"
tls_cert_path:        "/etc/openlm/certs/tls.crt"
tls_key_path:         "/etc/openlm/certs/tls.key"

reporting_db_type:     "SqlServer_SQLServerAuth"
reporting_db_host:     "mssql.yourcompany.com"
reporting_db_port:     1433
reporting_db_username: "openlm_app"
reporting_db_password: "<sql-server-password>"
reporting_db_name:     "openlm_reporting_db"

operational_db_type:     "SqlServer_SQLServerAuth"
operational_db_host:     "mssql.yourcompany.com"
operational_db_port:     1433
operational_db_username: "openlm_app"
operational_db_password: "<sql-server-password>"
operational_db_name:     "openlm_operational_db"
identity_db_name:        "openlm_identity_db"
dss_db_name:             "openlm_dss_db"

Replace <sql-server-password> with the password of the SQL Server user.

External Kafka, such as AWS MSK

Use this pattern if you already operate an event bus that you want OpenLM Platform to share. Set these values in config.yaml:

openlm_system_domain: "openlm.yourcompany.com"
tls_cert_path:        "/etc/openlm/certs/tls.crt"
tls_key_path:         "/etc/openlm/certs/tls.key"

kafka_bootstrap_servers:     "b-1.mycluster.xxxxx.kafka.us-east-1.amazonaws.com:9092"
kafka_sasl_mechanism:        "ScramSha512"
kafka_sasl_username:         "openlm-user"
kafka_sasl_password:         "<msk-password>"
kafka_security_protocol:      "SASLSSL"
kafka_ssl_endpoint_algorithm: "https"

Replace <msk-password> with the password of the Kafka user.

Air-gapped network with no external DNS

The VM has no DNS server that can host the OpenLM Platform domain. End users reach OpenLM Platform by IP or through local hosts entries. Set these values in config.yaml:

openlm_system_domain: "openlm.internal"
tls_cert_path:        "/etc/openlm/certs/tls.crt"
tls_key_path:         "/etc/openlm/certs/tls.key"

add_coredns_hosts_entry: true
coredns_hosts_entry_ip:  "10.20.30.40"