Skip to main content

Docker image environment variables

Console properties reference

You can configure Console via environment variables or using the YAML file. Environment variables can be set on the container or imported from a file. When importing from a file, mount the file into the container and provide its path by setting the environment variable CDK_ENV_FILE. Use the .env file with key value pairs.
The logs will confirm, Sourcing environment variables from $CDK_ENV_FILE, or warn if set and the file is not found
Lists start at index 0 and are provided using the _idx_ syntax.If you set both the environment variable and a YAML value for a specific field, the environment variable will take precedence.

YAML property cases

YAML configuration supports multiple case formats (camelCase/kebab-case/lowercase) for property fragments such as:
  • clusters[].schemaRegistry.ignoreUntrustedCertificate
  • clusters[].schema-registry.ignore-untrusted-certificate
  • clusters[].schemaregistry.ignoreuntrustedcertificate
All are valid and equivalent in YAML.

Environment variable conversion

At startup, Conduktor Console will merge environment variables and YAML based configuration files into one unified configuration. The conversion rules are:
  • Filter for environment variables that start with CDK_
  • Remove the CDK_ prefix
  • Convert the variable name to lower case
  • Replace _ with . for nested properties
  • Replace _[0-9]+_ with [0-9]. for list properties. Lists start at index 0.
For example, the environment variable CDK_DATABASE_URL will be converted to database.url; CDK_SSO_OAUTH2_0_OPENID_ISSUER will be converted to sso.oauth2[0].openid.issuer. The YAML equivalent would be:
When converting environment variables to YAML configuration, environment variables in UPPER-KEBAB-CASE will be converted to kebab-case in the YAML configuration.

Conversion edge cases

Because of YAML multiple case formats support, the conversion rules have some edge cases when trying to mix environment variables and YAML configuration. Extra rules when mixing environment variables and YAML configuration:
  • Don’t use camelCase in YAML configuration. Use kebab-case or lowercase
  • Stick to one compatible case format for a given property fragment using the following compatibility matrix
Compatibility matrix: For example, the CDK_CLUSTERS_0_SCHEMAREGISTRY_IGNOREUNTRUSTEDCERTIFICATE environment variable :
And conversely, for CDK_CLUSTERS_0_SCHEMA-REGISTRY_IGNORE-UNTRUSTED-CERTIFICATE environment variable. That’s why camelCase is not recommended in YAML configuration when mixing with environment variables.

Shell expansion in the YAML configuration file

Console supports shell expansion for environment variables and home tilde ~. This is useful if you have to use custom environment variables in your configuration. For example, you can use the following syntax:
YAML configuration file
with the following environment variables: This will be expanded to:
Expanded configuration
If you want to escape the shell expansion, you can use the following syntax: $$. For example, if you want admin.password to be secret$123, set admin.password: "secret$$123".

Support for *_FILE environment variables

When an environment variable ending with _FILE is set to a file path, its corresponding unprefixed environment variable will be replaced with the content of that file. For instance, if you set CDK_LICENSE_FILE=/run/secrets/license, the value of CDK_LICENSE will be overridden by the content of the file located at /run/secrets/license.
The CDK_IN_CONF_FILE is not supported.

Global properties

Database properties

Console uses PostgreSQL to persist application state and operational data. The database maintains user accounts and their group memberships, along with associated permissions and role-based access controls. It also stores your cluster definitions and connection details, indexed metadata from connected clusters (including topics, schemas, and connectors), alert configurations and audit log entries that track system activity. Example configuration for PostgreSQL connection options:
To pass options via environment variable, use CDK_DATABASE_URL. The equivalent of the above configuration is:
Console supports all valid JDBC PostgreSQL configuration options. For Hikari configuration, only the following options are supported:
  • keepaliveTime
  • connectionTimeout
  • idleTimeout
  • maxLifetime

Session lifetime properties

Local user properties

Optional local accounts list, used to log into Console.

Monitoring properties

We provide a pre-configured monitoring solution based on Cortex (conduktor/conduktor-console-cortex). It’s a custom implementation of Prometheus used in several production systems including Amazon Managed Service for Prometheus (AMP). If using your own solution, set the monitoring.backend property. We support Cortex, Mimir and Prometheus. You can choose to not deploy any monitoring solution. If none is deployed, you won’t be able to see the monitoring graphs or configure alerts. Depending on the chosen solution, you’ll need to provide the corresponding URL and other properties. The mandatory column indicates whether the property is required for the chosen backend. For example, if you choose mimir, you have to provide the monitoring.mimir-url property but if you select conduktor, you have to provide the monitoring.cortex-url. If an alert manager URL isn’t provided, Console will use its built-in alert system.
monitoring.use-aggregated-metrics and monitoring.enable-non-aggregated-metrics are temporary flags to help you transition to the new metrics collection system. They will be removed in a future release.Swap their default value if you experience performance issues when Console is connected with large Kafka clusters:

SSO properties

LDAP properties

OAuth2 properties

JWT auth properties

Kafka cluster properties

Kafka vendor specific properties

Note that you only need to set the Kafka cluster properties to use the core features of Console. For additional benefits though, set the flavor of your cluster. To define that, go to Settings > Clusters and open the Provider tab.

Schema registry properties

Amazon Glue properties

Kafka Connect properties

ksqlDB properties

Indexing properties

Indexing fetches metadata from your Kafka cluster (e.g. topics, consumer groups, subjects). You should only modify these parameters if you see an issue with the performance.

Audit log export properties

The audit log can be exported to a Kafka topic, once configured in Console.

Conduktor SQL properties

In order to use Conduktor SQL, you need to configure a second database to store the Topics data. You can configure Conduktor SQL Database using CDK_KAFKASQL_DATABASE_URL or alternatively, set each value individually CDK_KAFKASQL_DATABASE_*. Find out more about database properties. These are advanced properties that typically won’t need to be changed.

Partner Zones properties

These are advanced properties that typically won’t need to be changed.

Data quality properties

These are advanced properties that typically won’t need to be changed.

Data quality overview properties

These properties configure the data quality overview page which provides coverage and health metrics.

Data policy properties

These are advanced properties that typically won’t need to be changed.

Chargeback properties

These properties enable and configure Chargeback functionality, both with and without Gateway.

Stream lineage properties

These properties control Stream lineage graph caching in Console.

UI settings properties

Customize Console UI behavior for your organization, including default topic creation settings and custom support links.