Repository navigation
Feature: Expose all DoltDB config.yaml properties in the CRD #2
Description
Context
The DoltDB CRD currently exposes only a subset of the DoltDB config.yaml properties. Users who need to tune behavior, listener timeouts, TLS, system variables, or other native settings have no way to do so declaratively through the operator.
What we already expose
| Section | Property | CRD Path |
|---|---|---|
log_level |
log_level |
spec.server.logLevel |
behavior |
auto_gc_behavior.enable |
spec.server.behavior.autoGCBehavior.enabled |
listener |
host |
spec.server.listener.host |
listener |
port |
spec.server.listener.port |
listener |
max_connections |
spec.server.listener.maxConnections |
metrics |
host, port, labels, enabled |
spec.server.metrics.* |
remotesapi |
port |
spec.server.cluster.remotesAPI.port |
mcp_server |
port, user, password, database |
spec.server.mcpServer.* |
profiler |
enablePProf |
spec.server.profiler.enablePProf |
What's missing
Behavior tuning
| config.yaml Property | Type | Default | Notes |
|---|---|---|---|
behavior.read_only |
bool |
false |
Read-only mode for the entire server |
behavior.autocommit |
bool |
true |
Controls default autocommit for sessions |
behavior.dolt_transaction_commit |
bool |
false |
Every TX commit becomes a Dolt commit |
behavior.disable_client_multi_statements |
bool |
false |
Disables multi-statement queries |
behavior.event_scheduler |
string |
"ON" |
Controls the SQL event scheduler |
behavior.auto_gc_behavior.archive_level |
int |
1 |
Compression level for auto GC (0 or 1) |
behavior.branch_activity_tracking |
bool |
false |
Enables dolt_branch_activity system table |
log_format |
string |
"text" |
Log format: text or json |
Listener / connection tuning
| config.yaml Property | Type | Default | Notes |
|---|---|---|---|
listener.back_log |
int |
50 |
Connections that can block waiting |
listener.max_connections_timeout_millis |
int |
60000 |
Timeout for blocked connections |
listener.read_timeout_millis |
int |
28800000 |
Read timeout per connection |
listener.write_timeout_millis |
int |
28800000 |
Write timeout per connection |
TLS (application-level)
| config.yaml Property | Type | Default | Notes |
|---|---|---|---|
listener.tls_key |
string |
null |
Path to TLS key .pem file |
listener.tls_cert |
string |
null |
Path to TLS cert .pem file |
listener.ca_cert |
string |
null |
Path to CA cert for client verification |
listener.require_secure_transport |
bool |
null |
Enforce TLS connections |
listener.require_client_cert |
bool |
null |
Require client certificates |
listener.allow_cleartext_passwords |
bool |
null |
Allow mysql_clear_password plugin (for JWT) |
TLS support would likely require mounting cert Secrets into pods and referencing file paths in the config.
Advanced configuration
| config.yaml Property | Type | Default | Notes |
|---|---|---|---|
max_logged_query_len |
int |
0 |
Truncate query log lines (0 = unlimited) |
remotesapi.read_only |
bool |
null |
Make the remotesapi endpoint read-only |
system_variables |
map[string]string |
{} |
Set Dolt system variables at startup |
user_session_vars |
[]object |
[] |
Per-user session variable defaults |
jwks |
[]object |
[] |
JWT authentication configuration |
Intentionally NOT exposed (operator-managed)
These are controlled by the operator's reconciliation logic and probably shouldn't be user-configurable:
| config.yaml Property | Reason |
|---|---|
data_dir |
Operator manages volume mounts at /db |
cfg_dir |
Operator manages config directory |
privilege_file |
Operator manages via User / Grant CRDs |
branch_control_file |
Operator manages config directory |
cluster.* |
Auto-generated from spec.replicas and spec.replication |
Open questions
- Which groups of properties are most needed? Should we ship this incrementally or all at once?
- What's the best pattern for referencing TLS certs —
secretKeyReffields, cert-manager integration, or something else? - Would a generic
map[string]stringfor system variables be useful so users can set any Dolt variable without waiting for a CRD change?
Activity
realnedsanders commentedon Oct 22, 2026
The cluster remotesapi is exposed, but not the user-facing one.