The diom server accepts the following environment variables:

| Environment Variable | Description |
|----------------------|-------------|
| `$DIOM_ADMIN_TOKEN` | An auth token for admin access to Diom<br/><br/>It's useful for bootstrapping a new Diom cluster, or using it in CI pipelines or other automated testing environments where you need a stable, well-known token for testing or scripted setup.<br/><br/>If you're using it to bootstrap a new Diom cluster, it’s recommended that you only use it during bootstrapping, and remove this configuration once done. |
| `$DIOM_BACKGROUND_CLEANUP_INTERVAL_MS` | How often to run background cleanup/garbage collection jobs<br/><br/>Correctness should never be affected by this, just wasted memory/disk. |
| `$DIOM_BOOTSTRAP_CFG` | Inline bootstrap script, applied before any `bootstrap_cfg_paths`. |
| `$DIOM_BOOTSTRAP_CFG_PATHS` | Paths to bootstrap scripts, applied in order. |
| `$DIOM_BOOTSTRAP_MAX_WAIT_TIME_MS` | Maximum time to wait for cluster initialization at startup<br/><br/>If this is unset, we will wait indefinitely. |
| `$DIOM_CLUSTER_ADVERTISED_ADDRESS` | Address that other nodes should use to communicate with this one.<br/><br/>If not passed, we'll attempt to discover it at boot time. This cannot currently be changed after cluster initialization. |
| `$DIOM_CLUSTER_AUTO_INITIALIZE` | Automatically initialize the cluster on bootup if we can't discover any peers and we don't have any existing state.<br/><br/>If you initialize all peers at exactly the same time, this can potentially cause errors. |
| `$DIOM_CLUSTER_CONNECTION_TIMEOUT_MS` | Timeout for new connections.<br/><br/>If you want to be tolerant of dropped packets, this should be set to at least TO + ε, where TO is the initial TCP retransmission timer (typically either 1s or 3s, depending on your operating system). |
| `$DIOM_CLUSTER_DISCOVERY_REQUEST_TIMEOUT_MS` | Timeout for discovery requests.<br/><br/>This should be set to approximately 2X the RTT of your farthest-apart nodes. |
| `$DIOM_CLUSTER_DISCOVERY_TIMEOUT_MS` | Timeout for the entire discovery process |
| `$DIOM_CLUSTER_ELECTION_TIMEOUT_MAX_MS` | The minimum time to let an election run for.<br/><br/>This should be set to at least 5x the RTT of your farthest-apart nodes and must not be less than `cluster_election_timeout_max`. |
| `$DIOM_CLUSTER_ELECTION_TIMEOUT_MIN_MS` | The minimum time to let an election run for.<br/><br/>This should be set to at least 4x the RTT of your farthest-apart nodes, and must not be less than `heartbeat_interval_ms`. |
| `$DIOM_CLUSTER_FORWARD_OPENTELEMETRY_CONTEXT` | Store an openetelemetry context in logs, for tracing.<br/><br/>This will make it possible to trace individual requests through the Raft layer, but greatly increases the size of raft logs, and may result in confusing traces when there are multiple nodes in a cluster. |
| `$DIOM_CLUSTER_HEARTBEAT_INTERVAL_MS` | How often to send heartbeats.<br/><br/>This controls how fast lost leaders can be detected. Must not be less than `replication_request_timeout`. |
| `$DIOM_CLUSTER_LISTEN_ADDRESS` | The address to listen on for replication. |
| `$DIOM_CLUSTER_LOG_INDEX_INTERVAL_MS` | How often to write commit log indexes<br/><br/>This controls the granularity for purging of old logs, and should not be set to a value smaller than 1 second or larger than one hour |
| `$DIOM_CLUSTER_LOG_LEVEL` | Level to use for cluster (human-readable) debugging logs.<br/><br/>If not passed, will use the application-wide `log_level`. |
| `$DIOM_CLUSTER_LOG_PATH` | Location to store replication commit logs.<br/><br/>For high-throughput systems, this should be a separate volume. Defaults to a subdirectory under the persistent DB path if not passed. |
| `$DIOM_CLUSTER_LOG_SYNC_INTERVAL_AUTO` | Automatically attempt to determine the log sync interval from observed fsync timings |
| `$DIOM_CLUSTER_LOG_SYNC_INTERVAL_COMMITS` | Interval (in transactions) between fsyncing the commit log.<br/><br/>This can be used to force transactions to fsync logs more often than the default `log_sync_interval_ms` timer. If `log_sync_mode` is set to "buffer", it's reasonable to set this value to `1` to flush to the OS buffer on every log.<br/><br/>If this is set to 0, only the interval timer will be used<br/><br/>If this is set to a value higher than 1 and the interval timer is long, then single-threaded clients (including bootstrap) will be extremely slow. |
| `$DIOM_CLUSTER_LOG_SYNC_INTERVAL_DURATION_MS` | Interval (in milliseconds) between fsyncing the commit log.<br/><br/>If `log_sync_interval_auto` is set to true, this is just the initial estimate and will be auto-scaled |
| `$DIOM_CLUSTER_LOG_SYNC_MODE` | Should a commit log sync actually trigger an fsync?<br/><br/>If this is set to "buffer" and a node suffers a catastrophic failure where OS buffers are not written to disk, that node should be erased and re-snapshotted before being re-added to the cluster. |
| `$DIOM_CLUSTER_NAME` | Human-facing name for this cluster.<br/><br/>Only used in discovery and debugging. |
| `$DIOM_CLUSTER_REPLICATION_LAG_THRESHOLD` | How many commits behind must the current node be to be considered "lagging" and eligible for re-snapshotting?<br/><br/>The ideal value here depends both on your data-set size and on your average write-rate. If your data is large, then setting this value too small can mean that a snapshot can never catch up because it'll take too long to replicate. Typically this should be around twice the number of commits that you generate in the time it takes to replicate a full snapshot. |
| `$DIOM_CLUSTER_REPLICATION_REQUEST_TIMEOUT_MS` | Timeout for replication requests.<br/><br/>This should be set to approximately 2X the RTT of your farthest-apart nodes. |
| `$DIOM_CLUSTER_SECRET` | Shared secret for intra-cluster communications.<br/><br/>This must be the same on all nodes. |
| `$DIOM_CLUSTER_SEED_NODES` | Other nodes that we should attempt to join a cluster with at boot time. |
| `$DIOM_CLUSTER_SEND_SNAPSHOT_TIMEOUT_MS` | The hard timeout for sending a snapshot<br/><br/>This should be at least twice as long as it takes to send the entire copy of your database. |
| `$DIOM_CLUSTER_SNAPSHOT_AFTER_TIME_MS` | Trigger a background snapshot after this many milliseconds. |
| `$DIOM_CLUSTER_SNAPSHOT_AFTER_WRITES` | Trigger a background snapshot after this many writes. |
| `$DIOM_CLUSTER_SNAPSHOT_PATH` | Location to store snapshots.<br/><br/>This volume must have at least as much space as the persistent DB path and ephemeral DB path combined. Defaults to a subdirectory under the persistent DB path if not passed. |
| `$DIOM_ENVIRONMENT` | The environment (dev, staging, or prod) that the server is running in. |
| `$DIOM_EPHEMERAL_DB_CACHE_SIZE` | Amount of memory to reserve for the database layer's caches for this database type.<br/><br/>Can be specified as a bare value of bytes (e.g., 1024000), a unit-ed amount (e.g., 1024MiB), or a percentage (e.g., 20%), which will be applied against the current cgroup limit if present and the total system memory otherwise |
| `$DIOM_EPHEMERAL_DB_FILENAME` | Filename under the directory specified in `path`. |
| `$DIOM_EPHEMERAL_DB_PATH` | Directory in which this database is stored |
| `$DIOM_EPHEMERAL_DB_WORKER_THREADS` | Number of worker threads<br/><br/>If not passed, defaults to min(# CPU cores, 4) |
| `$DIOM_FSYNC_MODE` | When fsyncing, should we use fsync(2) or fdatasync(2) |
| `$DIOM_JWT_ALGORITHM` | JWT signature algorithm |
| `$DIOM_JWT_AUDIENCE` | Expected `aud` values. When set, the token must contain one of these values in its `aud` claim. When absent, `aud` is not validated. |
| `$DIOM_JWT_ISSUER` | Expected `iss` values. When set, the token's `iss` claim must match one of these values. When absent, `iss` is not validated. |
| `$DIOM_JWT_PUBLIC_KEY_PEM` | Public key PEM for JWT algorithms RS256 / RS384 / RS512 / ES256 / ES384 / PS256 / PS384 / PS512 |
| `$DIOM_JWT_SECRET` | Secret for JWT algorithms HS256 / HS384 / HS512 |
| `$DIOM_LISTEN_ADDRESS` | The address to listen on |
| `$DIOM_LOG_FORMAT` | The log format that all output will follow. Supported: default, json |
| `$DIOM_LOG_LEVEL` | The log level to run the service with. Supported: info, debug, trace |
| `$DIOM_OPENTELEMETRY_ADDRESS` | The OpenTelemetry address to send events to if given.<br/><br/>Currently only GRPC exports are supported. |
| `$DIOM_OPENTELEMETRY_METRICS_ADDRESS` | The OpenTelemetry address to send metrics to if given.<br/><br/>If not specified, the server will attempt to fall back to `opentelemetry_address`. |
| `$DIOM_OPENTELEMETRY_METRICS_PERIOD_MS` | How often to send metrics to opentelemetry receivers |
| `$DIOM_OPENTELEMETRY_METRICS_PROTOCOL` | OpenTelemetry metrics protocol<br/><br/>By default, metrics are sent via GRPC. Some metrics destinations, most notably Prometheus, only support receiving metrics via HTTP. |
| `$DIOM_OPENTELEMETRY_SAMPLE_RATIO` | The ratio at which to sample spans when sending to OpenTelemetry.<br/><br/>When not given it defaults to always sending. If the OpenTelemetry address is not set, this will do nothing. |
| `$DIOM_OPENTELEMETRY_SERVICE_NAME` | The service name to use for OpenTelemetry. If not provided, it defaults to "diom". |
| `$DIOM_PERSISTENT_DB_CACHE_SIZE` | Amount of memory to reserve for the database layer's caches for this database type.<br/><br/>Can be specified as a bare value of bytes (e.g., 1024000), a unit-ed amount (e.g., 1024MiB), or a percentage (e.g., 20%), which will be applied against the current cgroup limit if present and the total system memory otherwise |
| `$DIOM_PERSISTENT_DB_FILENAME` | Filename under the directory specified in `path`. |
| `$DIOM_PERSISTENT_DB_PATH` | Directory in which this database is stored |
| `$DIOM_PERSISTENT_DB_WORKER_THREADS` | Number of worker threads<br/><br/>If not passed, defaults to min(# CPU cores, 4) |
| `$DIOM_SINK_MAX_CONCURRENCY` | Maximum number of topic sinks that can be drained concurrently.<br/><br/>Larger values allow for faster forwarding (when the number of sinks exceeds `sink_max_concurrency`), at the expense of memory/CPU. |
| `$DIOM_SINK_MAX_TASK_DURATION_MS` | Maximum time a single sink drain task may run before yielding to others.<br/><br/>When the number of sinks exceeds `sink_max_concurrency`, shorter durations improve fairness across sinks; longer durations are generally more throughput-efficient. |
| `$DIOM_SVIX_POLLER_MAX_CONCURRENCY` | Maximum number of Svix Ingest pollers that can run concurrently.<br/><br/>Larger values allow for faster processing (if the number of svix pollers exceeds svix_poller_max_concurrency), at the expense of memory/disk. |
| `$DIOM_SVIX_POLLER_MAX_TASK_DURATION_MS` | Maximum time a single poller task may spend running before being killed/restarted.<br/><br/>If the number of pollers exceeds `svix_poller_max_concurrency`, then shorter durations will enable better fairness for all configured pollers. Longer durations will generally be more performant. |
| `$DIOM_SYNC_MODE` | How to persist data to the actual underlying database<br/><br/>This is similar to the `cluster.log_sync` options, but applies to the actual primary data as opposed to the log, and is applied at every batch commit from the underlying replication system. |


This list can be shown at runtime with `diom-server describe-environment-variables`
