Skip to main content

Server Configuration Reference

Complete reference for Miren server configuration. Settings can be specified via config file, environment variables, or CLI flags.

Configuration Precedence

Settings are resolved in this order (highest priority first):

  1. CLI flags — e.g. --address :9443
  2. Environment variables — e.g. MIREN_SERVER_ADDRESS=:9443
  3. Config fileserver.toml
  4. Defaults

Config File

The server reads its config from the first file found:

  1. Path specified via --config
  2. /etc/miren/server.toml
  3. {data_path}/config/server.toml (default: /var/lib/miren/config/server.toml)

Example

mode = "standalone"

[server]
address = ":8443"
data_path = "/var/lib/miren"
http_request_timeout = 60

[ingress]
mode = "tls-autoprovision"

[tls]
acme_email = "admin@example.com"

[etcd]
start_embedded = true

[buildkit]
gc_keep_storage = "20GB"
gc_keep_duration = "14d"

Server Modes

Miren has two operating modes:

ModeDescription
standaloneAll components (etcd, containerd, buildkit, logs, metrics) run embedded within a single process. This is the default.
distributedComponents run as separate services. Experimental.

In standalone mode, embedded services start automatically unless explicitly disabled.

Top-Level Fields

FieldTypeDefaultEnv VarCLI Flag
modestringstandaloneMIREN_MODE--mode, -m
labsstring[][]MIREN_LABS--labs

[server] — Core Settings

FieldTypeDefaultDescriptionEnv VarCLI Flag
addressstring:8443Address to listen on (host:port)MIREN_SERVER_ADDRESS--address, -a
runner_addressstringlocalhost:8444Runner address (host:port)MIREN_SERVER_RUNNER_ADDRESS--runner-address
data_pathstring/var/lib/mirenRoot data directoryMIREN_SERVER_DATA_PATH--data-path, -d
runner_idstringmirenRunner identifierMIREN_SERVER_RUNNER_ID--runner-id, -r
release_pathstringPath to release directory containing binariesMIREN_SERVER_RELEASE_PATH--release-path
config_cluster_namestringlocalCluster name in client configMIREN_SERVER_CONFIG_CLUSTER_NAME--config-cluster-name, -C
skip_client_configboolfalseSkip writing client config to clientconfig.dMIREN_SERVER_SKIP_CLIENT_CONFIG--skip-client-config
http_request_timeoutint60HTTP request timeout in seconds (minimum: 1). Cluster-wide default; override per route with miren route timeout — see Request TimeoutsMIREN_SERVER_HTTP_REQUEST_TIMEOUT--http-request-timeout
stop_sandboxes_on_shutdownboolfalseStop all sandboxes when server shuts down (useful in development)MIREN_SERVER_STOP_SANDBOXES_ON_SHUTDOWN--stop-sandboxes-on-shutdown

[ingress] — Ingress Settings

Selects the deployment shape for Miren's HTTP/HTTPS ingress. The mode determines where Miren listens and whether it terminates TLS. See TLS for cert sourcing under each mode.

FieldTypeDefaultDescriptionEnv VarCLI Flag
modestringtls-autoprovisionIngress mode: tls-autoprovision, behind-proxy-http, or behind-proxy-httpsMIREN_INGRESS_MODE--ingress-mode
addressstringOptional bind override (full host:port). Replaces the mode's default bind entirely. Ignored under tls-autoprovision.MIREN_INGRESS_ADDRESS--ingress-address

Modes

ModeDefault bindTLS terminatedCert source
tls-autoprovision (default)0.0.0.0:443 plus :80 for redirect / HTTP-01 ACMEyes[tls] (ACME or self-signed)
behind-proxy-http127.0.0.1:80non/a
behind-proxy-https127.0.0.1:443yes[tls] (self-signed or DNS-01 ACME)

The behind-proxy-* modes default to localhost to keep accidental misconfigurations from quietly exposing an internal endpoint to the network. Set ingress.address = "0.0.0.0:80" (or similar) explicitly when the proxy is on a different host.

Unix socket addresses

unix:/path is reserved for a future release and rejected today with a clear error.

[tls] — TLS Settings

Settings under [tls] cover two kinds of certs. acme_email, acme_dns_provider, and self_signed configure the ingress cert and only apply when Miren terminates TLS (tls-autoprovision or behind-proxy-https); they're rejected at startup under behind-proxy-http. additional_names and additional_ips are different: they extend the SANs on the API server and etcd certs, which exist regardless of ingress mode, so they're valid under any mode. See TLS for setup guides.

additional_ips does more than its name suggests. Alongside adding SANs, every address listed there is passed straight through to the addresses the server advertises to Miren Cloud, skipping the filtering that discovered addresses go through. That makes it the way to pin an address discovery gets wrong — a host behind a static NAT, or one where you want a specific interface used. See Running Miren on a Tailnet for a worked example, and run miren debug advertise on the host to see what discovery decided and why.

FieldTypeDefaultDescriptionEnv VarCLI Flag
additional_namesstring[][]Extra DNS names for the server certificateMIREN_TLS_ADDITIONAL_NAMES--dns-names
additional_ipsstring[][]Extra IPs for the server certificate, and forced into the advertised address listMIREN_TLS_ADDITIONAL_IPS--ips
acme_dns_providerstringDNS provider for ACME DNS-01 challenges (e.g. cloudflare, route53). Required under behind-proxy-https if not using self_signed.MIREN_TLS_ACME_DNS_PROVIDER--acme-dns-provider
acme_emailstringEmail for ACME account registrationMIREN_TLS_ACME_EMAIL--acme-email
self_signedboolfalseUse self-signed certificates (development only, or behind a TLS-terminating proxy that doesn't verify)MIREN_TLS_SELF_SIGNED--self-signed-tls

[etcd] — Etcd Settings

Miren uses etcd as its entity store. In standalone mode, an embedded etcd server starts automatically.

FieldTypeDefaultDescriptionEnv VarCLI Flag
endpointsstring[][]Etcd endpoints (auto-configured when embedded)MIREN_ETCD_ENDPOINTS--etcd, -e
prefixstring/mirenKey prefix in etcdMIREN_ETCD_PREFIX--etcd-prefix, -p
start_embeddedbooltrue*Start embedded etcd serverMIREN_ETCD_START_EMBEDDED--start-etcd
client_portint12379Embedded etcd client portMIREN_ETCD_CLIENT_PORT--etcd-client-port
peer_portint12380Embedded etcd peer portMIREN_ETCD_PEER_PORT--etcd-peer-port
http_client_portint12381Embedded etcd HTTP client port (bound to loopback)MIREN_ETCD_HTTP_CLIENT_PORT--etcd-http-client-port

* Defaults to true in standalone mode only.

Embedded etcd is loopback-bound unless mTLS is on

client_port binds to all interfaces only when etcd mTLS is configured, which today means when distributed runners are enabled. Otherwise it binds 127.0.0.1, as do peer_port and http_client_port in either case. etcd's JSON gateway is disabled outright; its health and metrics endpoints are unaffected.

[containerd] — Containerd Settings

FieldTypeDefaultDescriptionEnv VarCLI Flag
start_embeddedbooltrue*Start embedded containerd daemonMIREN_CONTAINERD_START_EMBEDDED--start-containerd
binary_pathstringcontainerdPath to containerd binaryMIREN_CONTAINERD_BINARY_PATH--containerd-binary
socket_pathstringPath to containerd socketMIREN_CONTAINERD_SOCKET_PATH--containerd-socket

* Defaults to true in standalone mode only.

[buildkit] — BuildKit Settings

Controls the BuildKit daemon used for building container images.

FieldTypeDefaultDescriptionEnv VarCLI Flag
start_embeddedbooltrue*Start embedded BuildKit daemonMIREN_BUILDKIT_START_EMBEDDED--start-buildkit
socket_pathstringPath to external BuildKit socket (distributed mode)MIREN_BUILDKIT_SOCKET_PATH--buildkit-socket
socket_dirstringDirectory for embedded BuildKit socketMIREN_BUILDKIT_SOCKET_DIR--buildkit-socket-dir
gc_keep_storagestring10GBMaximum BuildKit layer cache sizeMIREN_BUILDKIT_GC_KEEP_STORAGE--buildkit-gc-storage
gc_keep_durationstring7dHow long to keep cache entriesMIREN_BUILDKIT_GC_KEEP_DURATION--buildkit-gc-duration

* Defaults to true in standalone mode only.

[victorialogs] — Log Storage Settings

Controls the embedded VictoriaLogs instance used for application log storage.

FieldTypeDefaultDescriptionEnv VarCLI Flag
start_embeddedbooltrue*Start embedded VictoriaLogs serverMIREN_VICTORIALOGS_START_EMBEDDED--start-victorialogs
http_portint9428HTTP port in embedded modeMIREN_VICTORIALOGS_HTTP_PORT--victorialogs-http-port
retention_periodstring30dRetention period (e.g. 30d, 2w, 1y)MIREN_VICTORIALOGS_RETENTION_PERIOD--victorialogs-retention
addressstringvictorialogs:9428Address when not using embeddedMIREN_VICTORIALOGS_ADDRESS--victorialogs-addr

* Defaults to true in standalone mode only.

[victoriametrics] — Metrics Storage Settings

Controls the embedded VictoriaMetrics instance used for application metrics.

FieldTypeDefaultDescriptionEnv VarCLI Flag
start_embeddedbooltrue*Start embedded VictoriaMetrics serverMIREN_VICTORIAMETRICS_START_EMBEDDED--start-victoriametrics
http_portint8428HTTP port in embedded modeMIREN_VICTORIAMETRICS_HTTP_PORT--victoriametrics-http-port
retention_periodstring1Retention period in monthsMIREN_VICTORIAMETRICS_RETENTION_PERIOD--victoriametrics-retention
addressstringvictoriametrics:8428Address when not using embeddedMIREN_VICTORIAMETRICS_ADDRESS--victoriametrics-addr

* Defaults to true in standalone mode only.

[app_version] — Version Retention

Every deploy creates a new version of an app, and Miren keeps a bounded history of them rather than retaining every version forever. Pruning old versions frees the disk space their container images take up and keeps the server's per-app state from growing with every deploy.

A version is retained if it is among the most recent retention_count or newer than retention_period — whichever rule keeps it. The two settings are a floor, not a budget: raising either one keeps more versions. The currently active version is always retained regardless of these limits, and ephemeral (preview) versions are managed separately by their own TTL.

On a frequently-deployed cluster this window can pin more image data than the disk can hold, so Miren tightens retention automatically under pressure: once storage reaches 80%, a sweep drops the retention_period floor and keeps the active version plus retention_count (plus anything still in use). That makes retention_count a hard floor, always honored, while retention_period is best-effort and yields when the disk is tight. See Managing Disk Space for how the reclaim works end to end and what to tune.

FieldTypeDefaultDescriptionEnv VarCLI Flag
retention_countint10Most-recent versions to keep per app, regardless of ageMIREN_APP_VERSION_RETENTION_COUNT--app-version-retention-count
retention_periodstring30dKeep versions newer than this, regardless of count (e.g. 30d, 2w)MIREN_APP_VERSION_RETENTION_PERIOD--app-version-retention-period

[saga] — Saga Execution Retention

Miren records a saga execution for multi-step operations like creating a sandbox or running a build, so that a server crash mid-operation can resume or roll back cleanly instead of leaving things half-done. Each record holds the outputs of every step it ran.

Once an execution finishes, that record is only useful for looking back at what happened, so Miren deletes it after retention_period. Successes and failures are treated the same way. Executions still in progress are never deleted regardless of age, including ones stuck retrying a rollback, since those are exactly what the server needs to recover.

Indefinite retention grows without bound

Setting retention_period to 0 keeps finished executions forever. That's useful while investigating an incident, but a cluster where one app repeatedly fails to start can write thousands of executions a day, so it's worth putting back afterward.

FieldTypeDefaultDescriptionEnv VarCLI Flag
retention_periodstring7dDelete finished saga executions older than this (e.g. 7d, 24h). 0 keeps them indefinitelyMIREN_SAGA_RETENTION_PERIOD--saga-retention-period

Workload Identity Anchor

The anchor is the iss claim in the tokens this cluster mints for its apps, and the address an outside verifier fetches its public keys from. The signing key is generated on the cluster and never leaves it either way — the anchor decides who serves the keys, not who holds them.

There is no configuration field for it, because it is a property of the registration rather than of the server. A cluster registered with Miren Cloud is anchored there, and Miren Cloud serves its discovery; a cluster installed with --without-cloud anchors at its own hostname and serves its own.

To change it on a registered cluster, use miren server identity-anchor, which handles the restart and the verification overlap that keeps in-flight tokens working. See Moving the anchor.