Basic Usage#
The BaSyx Configuration Service is designed as a run-once startup job. It executes its registered initialization sequences and then exits.
Command-Line Options#
Hint
These command-line options are only relevant when the service is not run as part of a Docker container.
The service binary supports these options:
/app/basyxconfigurationservice \
-config /app/config.yaml \
-databaseSchema /app/base.sql \
-customPatchPath /app/patches
Option |
Purpose |
Default |
|---|---|---|
|
Path to the BaSyx configuration file. |
Empty path, using common config loading behavior. |
|
Path to the base schema SQL file or a directory containing |
|
|
Directory containing registered patch files. |
|
Configuration Example#
The service uses the common BaSyx postgres configuration section.
postgres:
host: db
port: 5432
user: admin
password: admin123
dbname: basyxTestDB
maxOpenConnections: 50
maxIdleConnections: 25
connMaxLifetimeMinutes: 5
connMaxIdleTimeMinutes: 0
Environment variables can also be used in the same style as other BaSyx services, for example:
POSTGRES_HOST=db
POSTGRES_PORT=5432
POSTGRES_USER=admin
POSTGRES_PASSWORD=admin123
POSTGRES_DBNAME=basyxTestDB
POSTGRES_MAXOPENCONNECTIONS=50
POSTGRES_MAXIDLECONNECTIONS=25
POSTGRES_CONNMAXLIFETIMEMINUTES=5
POSTGRES_CONNMAXIDLETIMEMINUTES=0
The Configuration Service owns its own pool while the job is running. Include it in the PostgreSQL connection budget during startup and upgrades. Runtime services create separate pools in their own processes or pods. See General Configuration for zero-value semantics and pool sizing.
Patch Execution#
Patches are registered by the service implementation. The current service registers 101.sql with target schema version v1.0.1.
A patch is executed only if the current value in basyxsystem.schema_version is lower than the registered target version. Successful initialization and patching leaves basyxsystem.state as clean.
See the developer documentation for details about creating new patches.