Broker Configuration - Coreflux Documentation

Configure your Coreflux MQTT Broker to match your deployment requirements. This guide covers network settings, security options, TLS certificates, and deployment-specific configurations.

Most configuration changes require a broker restart to take effect. Plan those updates during a maintenance window. Updated bytes in the TLS certificate files are the exception: the broker re-reads them on a timer and uses them for new handshakes. See TLS Server Certificate.

To keep retained messages, persistent sessions, and queued QoS 1/2 across restarts, configure the separate Durability section (or COREFLUX_DURABILITY_* environment variables).

To expose the broker as an MCP server for AI clients, configure the separate Mcp section (or COREFLUX_MCP_* environment variables). TYPE MCP_SERVER was removed — this is not a LoT connector.

To accept an OIDC access token as the MQTT CONNECT password, configure the Oidc object in this file. There is no COREFLUX_OIDC_* variable. Enabling it forces AnonymousLogin off.

Configuration Overview

The broker configuration is stored as a JSON object. The structure below shows every supported property (the file is encrypted on disk; this is an illustrative representation):

{
  "Name": "Coreflux DataHub",
  "Port": 1883,
  "TlsPort": 8883,
  "WebsocketPort": 5000,
  "WebsocketPortTls": 443,
  "BindIPForMQTT": "0.0.0.0",
  "BindIPForMQTTwithTls": "0.0.0.0",
  "BindIpForWebSockets": "0.0.0.0",
  "BindIpForWebSocketsTls": "0.0.0.0",
  "AnonymousLogin": false,
  "CleanSession": false,
  "SessionExpiryInterval": 0,
  "SharedSubscriptions": false,
  "MaxPendingMessagesPerClient": 20000,
  "FullDebugLog": false,
  "CloudLogging": false,
  "ResendRetainTopics": false,
  "ClientCertificationValidation": false,
  "CheckCertificateChainValidation": false,
  "CheckCertificateRevokationList": false,
  "ServerCertificatePath": "",
  "ServerCertificateKeyPath": "",
  "ServerCertificatePassword": "",
  "ServerCertificateReloadIntervalSeconds": 3600,
  "RootCACertificatePath": "",
  "ClientCertificateSourcePath": "",
  "ClientCertificateRevocationListPath": "",
  "ProjectPath": "",
  "UsersFile": "",
  "EnvsPath": "",
  "SecretsPath": ""
}

First-Run Defaults

When no config file exists, the broker creates one with these values:

Property	Default
`Name`	`"Coreflux DataHub"`
`Port`	`1883`
`TlsPort`	`8883`
`WebsocketPort`	`5000`
`WebsocketPortTls`	`443`
Bind IPs (MQTT / TLS / WebSocket)	`"0.0.0.0"` (all interfaces)
`AnonymousLogin`	`true`
`FullDebugLog`	`false`
`ClientCertificationValidation`	`false`
`MaxPendingMessagesPerClient`	`20000`
`CleanSession`	`false`
`SessionExpiryInterval`	`0`
`SharedSubscriptions`	`false`

On a brand-new install the broker creates the config with AnonymousLogin: true. Set it to false and configure user credentials before exposing the broker to any untrusted network.

Network Settings

Ports

The broker listens on multiple ports for different connection types:

integer

default:"1883"

Standard MQTT port for unencrypted connections. This is the default port used by most MQTT clients.

integer

default:"8883"

MQTT port for TLS-encrypted connections. Requires valid server certificate configuration.

integer

default:"5000"

Port for MQTT over WebSocket connections. Used by browser-based clients and applications that cannot use raw TCP.

integer

default:"443"

Port for MQTT over WebSocket with TLS. The default is 443 on the broker host. A port below 1024 needs permission to bind it on the broker host. Linux APT and DNF packages grant that permission. See Ports below 1024.

All ports must be between 1 and 65535. Ensure chosen ports are not already in use by other services.

IP Bindings

Control which network interfaces the broker listens on:

string

IP address to bind for standard MQTT connections. Use 0.0.0.0 to listen on all interfaces, or a specific IP to restrict access.

string

IP address to bind for TLS-encrypted MQTT connections.

string

IP address to bind for WebSocket connections.

string

IP address to bind for WebSocket connections with TLS.

Example: Restrict to Local Network

{
  "BindIPForMQTT": "192.168.1.100",
  "BindIPForMQTTwithTls": "192.168.1.100",
  "BindIpForWebSockets": "192.168.1.100",
  "BindIpForWebSocketsTls": "192.168.1.100"
}

Example: Listen on All Interfaces

{
  "BindIPForMQTT": "0.0.0.0",
  "BindIPForMQTTwithTls": "0.0.0.0",
  "BindIpForWebSockets": "0.0.0.0",
  "BindIpForWebSocketsTls": "0.0.0.0"
}

Security Settings

Authentication

When true, clients may connect without a valid username/password, and unknown usernames are treated as anonymous. When false, only registered users in the users store can connect.The class default is false, but on a brand-new install the broker writes the first-run config with AnonymousLogin: true. Enforced at runtime in ValidateConnectionAsync, which rejects unauthenticated connects when false and the user is not found.

Never leave AnonymousLogin enabled in production environments. Always require authentication for broker access.

When Oidc.Enabled is true, the broker forces AnonymousLogin off at startup. Passwords that are access tokens are checked with the identity provider. Any other password is still checked against the user store.

TLS Server Certificate

Configure TLS encryption for secure client connections:

string

Path to the server certificate file (PEM or PFX format). Required to enable the TLS listeners — MQTTS and WSS endpoints are only started when a server certificate is loaded successfully. If set but the file is missing, a warning is logged and the broker may still start without TLS.The broker re-reads this file (and ServerCertificateKeyPath, when set) on the interval below. A renewed certificate is used for new MQTTS and WSS handshakes. Clients that are already connected stay on the certificate they negotiated.

string

Path to the private key file when the certificate and key are in separate PEM files. Leave empty if the key is embedded in the certificate file. File contents are re-read on the same interval as the certificate.

string

Password for an encrypted private key or PFX bundle. If ServerCertificatePath is set but this is empty, a warning is logged at startup. $SYS/Coreflux/Config shows it as ********. Publishing that mask back to $SYS/Coreflux/Config/New keeps the stored password.You need a password only when the PEM key is encrypted. cert-manager writes an unencrypted tls.key by default, so leave this empty for that key. A password set beside an unencrypted key does not block loading.

integer (seconds)

default:"3600"

How often the broker checks ServerCertificatePath and ServerCertificateKeyPath for new file contents. Default 3600 (one hour). Set 0 to disable reloading.When the contents change, the next MQTTS or WSS handshake uses the new certificate. Existing sessions stay connected. The broker compares file contents, so a timestamp change with the same bytes does not swap the certificate. A detected change is read again after one second so a file that is still being written is not loaded. If the new files fail to load, the previous certificate stays in use.The first check runs one full interval after startup. Changing this value, the certificate paths, listener ports, or mTLS mode still requires a broker restart.Allowed values are 0 or a positive number of seconds, up to 4294966 (about 49.7 days).

Keep the reload interval shorter than your certificate renewal margin. With the default of one hour, a renewed file can wait up to an hour before new handshakes pick it up. cert-manager renews at renewBefore, which for a typical 90-day certificate is days ahead of expiry, so the default sits inside that margin. Use a shorter interval (for example 60 to 300) for short-lived certificates. Each check is two file reads and a hash.

Do not mount the certificate with subPath. A subPath mount captures the file at mount time and never updates when the Secret changes, so the broker never sees a renewal. Mount the Secret as a directory and point ServerCertificatePath at a file inside it.

string

Path to the root CA certificate for certificate chain validation.

Example: TLS Configuration

{
  "ServerCertificatePath": "/certs/server.crt",
  "ServerCertificateKeyPath": "/certs/server.key",
  "ServerCertificatePassword": "your-certificate-password",
  "ServerCertificateReloadIntervalSeconds": 3600,
  "RootCACertificatePath": "/certs/ca.crt"
}

Mutual TLS (mTLS)

For environments requiring client certificate authentication:

string

Folder of trusted client certificates (the mTLS trust store). The broker loads every .pem, .crt, .cer, .der, and unprotected .p12/.pfx file in it (not recursive). Certificates in its revoked/ sub-folder are rejected. Empty means the default trust store under the broker data directory: $COREFLUX_DATA_PATH/certs, else $CONFIG_PATH/certs. That is /etc/project/certs in the Docker and Kubernetes images and /var/lib/coreflux/certs for apt/dnf packages; with neither variable set it is /var/lib/coreflux/certs on Linux and macOS, and C:\ProgramData\Coreflux\certs on Windows.The broker creates the folder at startup if it is missing. If it can’t (read-only, or not owned by the broker user), the broker starts with an empty trust store and the HUB shows the path as Unavailable. In containers, keep the default so certificates live on the /etc/project volume; a custom path must be on a writable, persisted volume owned by UID/GID 10001.When you set it from the HUB or with -brokerCertificates, the path must be absolute, outside system folders and the server certificate’s folder, and, on Linux and macOS, under an allowed root (/var/lib, /opt, /srv, /data, /mnt, /media, /home, /Users, temp folders, or the COREFLUX_DATA_PATH / CONFIG_PATH folders). Extend the roots with COREFLUX_CERT_STORAGE_ROOTS. Symbolic links are resolved before the check.A subfolder of CONFIG_PATH is allowed even under a system folder, so /etc/project/certs works in Docker. Use a certs subfolder on the project volume. The CONFIG_PATH folder itself is refused, and so is anything under /etc when CONFIG_PATH is /etc. Uploads through the HUB or import accept certificates only (.crt, .pem, .cer, .der, .p12, .pfx); private keys and CSRs are refused. See HUB Certificates.

integer (days)

default:"30"

Days before expiry at which a client certificate, the server certificate, or the Root CA is reported as expiring on $SYS/Coreflux/Certificates/Summary. 1 to 365.

boolean

default:"false"

Enable client certificate validation. When true, TLS connections require a client certificate (ClientCertificateMode.RequireCertificate). When false, client certificates are optional (AllowCertificate).

string

Path to the Certificate Revocation List (CRL) file for checking revoked certificates. When it is a folder, certificates in it are also treated as revoked, alongside the trust store’s revoked/ sub-folder.

boolean

default:"false"

Enable CRL checking for client certificates.

boolean

default:"false"

Enable full certificate chain validation for client certificates against RootCACertificatePath. When false, only the trusted list is checked. Changing it from the HUB takes effect immediately.

In HUB 2.12, System Config → Certificates shows and edits these settings, replaces the server certificate and Root CA without a restart, and uploads or revokes client certificates. See Certificates.

Example: mTLS Configuration

{
  "ServerCertificatePath": "/certs/server.crt",
  "ServerCertificateKeyPath": "/certs/server.key",
  "ServerCertificatePassword": "your-password",
  "ClientCertificateSourcePath": "/certs/trusted-clients/",
  "ClientCertificationValidation": true,
  "CheckCertificateChainValidation": true,
  "CheckCertificateRevokationList": true,
  "ClientCertificateRevocationListPath": "/certs/crl.pem"
}

mTLS is recommended for high-security environments where you need to verify client identity at the transport layer, in addition to username/password authentication.

Sessions and MQTT Behavior

boolean

default:"false"

Broker policy (not the client CONNECT flag).

false — allow persistent sessions; honour each client’s Clean Session / Clean Start flag.
true — require clean sessions only; reject clients that connect with a persistent session (returns NotAuthorized).

Wired in via ValidateConnectionAsync (reject policy) and WithPersistentSessions(!CleanSession) at startup.

Naming note: CleanSession = true on the broker means “force clean sessions from clients”, not “enable clean session”.

Clean Session enforcement — per the MQTT 5.0 spec, a broker with CleanSession = true rejects any client connecting with CleanSession = false (persistent session). Make sure your clients connect with a clean session when this policy is enabled.

integer (seconds)

default:"0"

MQTT 5 only — maximum session lifetime cap, in seconds. Defines how long the broker holds a session after a client disconnects. (Previously hardcoded to 10 minutes; now configurable.)

0 — no cap; the client’s CONNECT value is used as-is.
> 0 — reject persistent connects where the client requests more than this many seconds.
4294967295 (uint.MaxValue) — allow “never expire” client requests.

Applied in MqttService.ApplyConfiguredSessionExpiry during connection validation.MQTT 3.1.1: ignored — persistence is controlled by CleanSession + WithPersistentSessions only.Important: Coreflux has no server-builder API for session expiry. Clients that need MQTT 5 persistence must set SessionExpiryInterval > 0 in their CONNECT packet.

Shared subscriptions

boolean

default:"false"

Enables MQTT 5 shared subscriptions ($share/{group}/{filter}). Each message that matches the filter is delivered to exactly one member of that group — round-robin, preferring members that are connected. A client subscribed to the same filter without $share still receives every matching message.Use this when a pool of workers should share the load on one topic. $share/workers/jobs/# and $share/other/jobs/# are separate groups, because the group is the full share filter.

false (default) — a $share/... SUBSCRIBE is refused with reason code 0x9E (Shared Subscriptions Not Supported). CONNACK reports Shared Subscription Available = 0.
true — share filters are accepted. CONNACK reports Shared Subscription Available = 1. A malformed share filter (empty group name, + or # in the group name, or a missing filter) is refused with 0x8F (Topic Filter Invalid).

COREFLUX_MQTT_SHARED_SUBSCRIPTIONS overrides this field: 1 or true enables shared subscriptions, 0 or false disables them. Restart the broker after changing the field or the variable.In a cluster, in this version, each shared group is local to the broker host the members are connected to.

MQTT 3.1.1 clients can use the same $share/ prefix once shared subscriptions are enabled. See Shared subscriptions.

boolean

default:"false"

When true, the broker maintains a buffer of retained messages and re-publishes them in specific situations: on new subscriptions (copies retained messages into an internal buffer) and via periodic LogRetainedObjects publishing. Useful when clients need retained messages re-delivered after reconnect or subscription changes.

Performance and Back-Pressure

integer

default:"20000"

Maximum number of pending outbound messages queued per connected client before Coreflux drops messages (especially QoS 0). Protects broker memory when a client is slow to read.Wired in via WithMaxPendingMessagesPerClient at startup.

MaxPendingMessagesPerClient must be between 1 and 100000. A value outside this range prevents the broker from starting.

Per-connector wait-or-drop when a LoT connector cannot keep up is configured in LoT with ADD CONNECTOR_CONFIG (ADD ROUTE_CONFIG remains a supported alias). These environment variables set the broker-wide defaults (a restart is required to change them):

Variable	Default	Effect
`COREFLUX_ROUTE_OVERLOAD_POLICY`	`balanced`	Default for `OVERLOAD_POLICY`: `lossless` (wait forever, never drop), `balanced` (wait up to the timeout, then drop the arriving message), or `realtime` (drop immediately).
`COREFLUX_ROUTE_CHANNEL_FULL_TIMEOUT_MS`	`50`	Default wait budget in milliseconds for `balanced`.
`COREFLUX_ROUTE_CHANNEL_CAPACITY`	`100000`	Shared ceiling on how many connector updates the broker holds at once. Values below `1024` are raised to `1024`.

See Store and Forward Configuration for the LoT block, per-connector overrides, and what happens under load.

Deployment and Data Paths

These paths control where the broker stores its state. ProjectPath is the “base” that the other three resolve against.

string (directory path)

Overrides the broker data root (CFBasePath) so all state (bin, log, stats, config, projects, users, envs, secrets) lives under this path instead of the default install directory. Typical for Kubernetes volumes or custom install layouts. If not set, the broker uses its install directory.Precedence: COREFLUX_DATA_PATH (if set) wins over this field. CONFIG_PATH sets the initial data directory (used by Docker images) but a non-empty ProjectPath can still replace it unless COREFLUX_DATA_PATH is set. The -p / --path flag is applied late — prefer env vars.

string (file path)

Path to the file holding the broker’s user accounts (the username/password credentials used when AnonymousLogin is false). When set and valid, users load from this plaintext JSON array instead of the encrypted user store, and runtime user changes are written back to this file.

string (directory path)

Directory containing the .env file for environment variables the broker (and LOT logic) can reference at runtime — used to externalize deployment-specific values instead of hardcoding them in config. Resolves to {EnvsPath}/.env. Falls back to CFBasePath when empty. See Environment Variables & Secrets for usage.

string (directory path)

Directory containing secrets.json — the secrets store for sensitive values (tokens, keys, credentials) kept separate from the main config so they aren’t sitting in plain config JSON. Used by connectors and LOT GET SECRET. Resolves to {SecretsPath}/secrets.json. Falls back to CFBasePath when empty. See Environment Variables & Secrets for usage.

Logging

boolean

default:"false"

Enable detailed debug logging: connection validation details, every publish/subscription intercept, TCP health noise, etc. Useful for troubleshooting but may impact performance in production.

Only enable FullDebugLog for troubleshooting. Debug logging generates significant log volume and may impact broker performance.

boolean

default:"false"

When true, switches logging to stdout-only structured JSON (no rolling file sink). Intended for Docker/Kubernetes where log aggregators scrape container output. The COREFLUX_CLOUD_LOGGING=true environment variable also enables cloud logging.

Additional Settings

string

default:"Coreflux DataHub"

A human-readable name for this DataHub / broker instance. Used for identification in logs and UI; does not affect MQTT protocol behaviour.

Applying Configuration

Via MQTT Topic

Publish a configuration JSON to the system topic using any MQTT client (such as MQTT Explorer). A partial object is merged into the live configuration: only the fields you include change, and every field you omit stays as it is, including bind addresses.

Field	Value
Topic	`$SYS/Coreflux/Config/New`
Auth	Requires a user with system configuration permission

Payload: Full or partial configuration JSON object

{"Name":"ProductionBroker","Port":1883,"TlsPort":8883,"AnonymousLogin":false}

The runtime handler currently persists only a subset of fields (AnonymousLogin, bind IPs, ports, FullDebugLog). A restart is required for listener, session, and certificate path changes to take effect. The contents of the files at ServerCertificatePath and ServerCertificateKeyPath are picked up on ServerCertificateReloadIntervalSeconds and do not require a restart.

Configuration Validation

The broker validates configuration on load. The following checks are fatal — an invalid value prevents the broker from starting:

Check	Requirement
Port values	Must be between 1 and 65535
IP addresses	Must be valid IPv4 addresses
`MaxPendingMessagesPerClient`	Must be between 1 and 100000

Certificate-related issues are non-fatal: they log a warning at startup and the broker continues without TLS rather than refusing to start.

Condition	Behaviour
`ServerCertificatePath` set but file missing	Warning logged; TLS listeners not started
`ServerCertificatePath` set but `ServerCertificatePassword` empty	Warning logged
`ClientCertificateSourcePath` (or default trust store) missing	Folder created at startup; if that fails, an error is logged and the trust store starts empty

These process environment variables override or complement the JSON file. Restart the broker after changing them. Details and examples: Environment Variables & Secrets.

Variable	Effect
`COREFLUX_DATA_PATH`	Data directory, used as-is; takes precedence over `CONFIG_PATH` and `ProjectPath`
`CONFIG_PATH`	Data directory if `COREFLUX_DATA_PATH` is unset (Docker images set `/etc/project`)
`COREFLUX_MQTT_SHARED_SUBSCRIPTIONS`	Overrides `SharedSubscriptions`. `1` or `true` enables shared subscriptions; `0` or `false` disables them. See Shared subscriptions.
`COREFLUX_CLOUD_LOGGING`	Enables stdout JSON logging (same intent as `CloudLogging`)
`COREFLUX_LOG_LEVEL`	Log verbosity (`Verbose` … `Fatal`)
`COREFLUX_SECRET_KEY`	Base64 32-byte key for encrypted secrets
`COREFLUX_AUDIT_KEY`	Base64 32-byte key for audit log encryption
`COREFLUX_OPS_ENABLED`	Enable ops HTTP on `COREFLUX_OPS_PORT` (default `9100`) — `/health`, `/ready`, `/info`, `/license`, `/metrics`. See Operational endpoints.
`COREFLUX_OPS_PORT`	Ops listener port
`COREFLUX_OPS_BIND_IP`	Ops bind address
`COREFLUX_ACTIVATION_CODE`	Online license activation (`CFLX-…`). See Licensing and Enrollment
`COREFLUX_ROUTE_OVERLOAD_POLICY`	Broker-wide default for connector `OVERLOAD_POLICY`. See Store and Forward Configuration.
`COREFLUX_ROUTE_CHANNEL_FULL_TIMEOUT_MS`	Broker-wide default wait budget (ms) for `balanced` connectors
`COREFLUX_ROUTE_CHANNEL_CAPACITY`	Shared ceiling on queued connector updates (default `100000`)
`COREFLUX_DURABILITY_*`	See MQTT State Durability
`COREFLUX_CLUSTER_*`	See Clustering
`COREFLUX_DISABLE_PYTHON`	Skip in-process Python when `true`

Docker Configuration

When running Coreflux in Docker, configure the broker using environment variables or mounted configuration files.

Using Environment Variables

Docker Run
Docker Compose

docker run --pull=always -d \
  --name coreflux_broker \
  -p 1883:1883 \
  -p 5000:5000 \
  -p 9100:9100 \
  -v project-volume:/etc/project \
  -v /path/to/certs:/certs \
  coreflux/coreflux-mqtt-broker:latest

version: '3.8'
services:
  coreflux:
    image: coreflux/coreflux-mqtt-broker:latest
    container_name: coreflux
    ports:
      - "1883:1883"
      - "8883:8883"
      - "5000:5000"
      - "443:443"
    volumes:
      - ./config:/config
      - ./certs:/certs
    restart: unless-stopped

Mounting Configuration

Mount your configuration file to the container:

docker run -d \
  -v /path/to/config.json:/app/config.json \
  -p 1883:1883 \
  coreflux/coreflux-mqtt-broker:latest

TLS with Docker

When using TLS in Docker, ensure certificate paths in the configuration match the mounted paths inside the container:

version: '3.8'
services:
  coreflux:
    image: coreflux/coreflux-mqtt-broker:latest
    ports:
      - "1883:1883"
      - "8883:8883"
    volumes:
      - ./certs/server.crt:/certs/server.crt:ro
      - ./certs/server.key:/certs/server.key:ro
      - ./certs/ca.crt:/certs/ca.crt:ro

Configuration JSON should reference the container paths:

{
  "ServerCertificatePath": "/certs/server.crt",
  "ServerCertificateKeyPath": "/certs/server.key",
  "RootCACertificatePath": "/certs/ca.crt"
}

Configuration Examples

Development Environment

Minimal configuration for local development:

{
  "Name": "DevBroker",
  "Port": 1883,
  "AnonymousLogin": true,
  "FullDebugLog": true,
  "BindIPForMQTT": "127.0.0.1"
}

Production Environment

Secure configuration for production deployment:

{
  "Name": "ProductionBroker",
  "Port": 1883,
  "TlsPort": 8883,
  "WebsocketPort": 5000,
  "WebsocketPortTls": 443,
  "AnonymousLogin": false,
  "FullDebugLog": false,
  "BindIPForMQTT": "0.0.0.0",
  "BindIPForMQTTwithTls": "0.0.0.0",
  "BindIpForWebSockets": "0.0.0.0",
  "BindIpForWebSocketsTls": "0.0.0.0",
  "ServerCertificatePath": "/certs/server.crt",
  "ServerCertificateKeyPath": "/certs/server.key",
  "ServerCertificatePassword": "secure-password",
  "RootCACertificatePath": "/certs/ca.crt"
}

High-Security Environment

Configuration with mTLS for maximum security:

{
  "Name": "SecureBroker",
  "Port": 1883,
  "TlsPort": 8883,
  "AnonymousLogin": false,
  "FullDebugLog": false,
  "BindIPForMQTT": "0.0.0.0",
  "BindIPForMQTTwithTls": "0.0.0.0",
  "ServerCertificatePath": "/certs/server.crt",
  "ServerCertificateKeyPath": "/certs/server.key",
  "ServerCertificatePassword": "secure-password",
  "RootCACertificatePath": "/certs/ca.crt",
  "ClientCertificateSourcePath": "/certs/trusted-clients/",
  "ClientCertificationValidation": true,
  "CheckCertificateChainValidation": true,
  "CheckCertificateRevokationList": true,
  "ClientCertificateRevocationListPath": "/certs/crl.pem"
}

Next Steps

Broker Commands

Learn how to manage the broker via MQTT commands.

$SYS Topics

Monitor broker status through system topics.

​Configuration Overview

​First-Run Defaults

​Network Settings

​Ports

​IP Bindings

​Example: Restrict to Local Network

​Example: Listen on All Interfaces

​Security Settings

​Authentication

​TLS Server Certificate

​Example: TLS Configuration

​Mutual TLS (mTLS)

​Example: mTLS Configuration

​Sessions and MQTT Behavior

​Shared subscriptions

​Performance and Back-Pressure

​Deployment and Data Paths

​Logging

​Additional Settings

​Applying Configuration

​Via MQTT Topic

​Configuration Validation

​Related Environment Variables

​Docker Configuration

​Using Environment Variables

​Mounting Configuration

​TLS with Docker

​Configuration Examples

​Development Environment

​Production Environment

​High-Security Environment

​Next Steps

Broker Commands

$SYS Topics

Configuration Overview

First-Run Defaults

Network Settings

Ports

IP Bindings

Example: Restrict to Local Network

Example: Listen on All Interfaces

Security Settings

Authentication

TLS Server Certificate

Example: TLS Configuration

Mutual TLS (mTLS)

Example: mTLS Configuration

Sessions and MQTT Behavior

Shared subscriptions

Performance and Back-Pressure

Deployment and Data Paths

Logging

Additional Settings

Applying Configuration

Via MQTT Topic

Configuration Validation

Related Environment Variables

Docker Configuration

Using Environment Variables

Mounting Configuration

TLS with Docker

Configuration Examples

Development Environment

Production Environment

High-Security Environment

Next Steps