Deploy

Secure deployment

Nexir supports mutual TLS on its RESP client and Raft peer listeners, but still depends on network and host controls for several security boundaries.

Required deployment boundary

• Run Redis, Raft, and metrics listeners on private interfaces or behind tightly scoped network controls.
• Allow the Raft gRPC port only between intended Nexir nodes.
• Use separate mutual-TLS trust domains for RESP clients and Raft peers.
• Protect the plaintext, unauthenticated Prometheus endpoint with a private scrape network, VPN, proxy, or service mesh.
• Restrict cluster administration to trusted operator networks.
• Run Nexir as a dedicated, unprivileged OS user.
• Set least-privilege permissions on data directories, CA bundles, certificates, and private keys.
• Use disk or volume encryption when required by your threat model.
• Monitor logs, certificate expiry, quorum health, storage growth, and free disk.

Network surfaces

Enable client mTLS

[server.tls.client]
mode = "require"
cert_file = "/etc/nexir/redis-listener.pem"
key_file = "/etc/nexir/private/redis-listener.key"
ca_bundle = "/etc/nexir/client-ca-bundle.pem"

Clients must present a certificate chained to the configured client CA. Nexir authenticates certificate trust but does not assign identities or permissions from a certificate.

Enable Raft peer mTLS

[server.tls.cluster]
mode = "require"
cert_file = "/etc/nexir/cluster-node.pem"
key_file = "/etc/nexir/private/cluster-node.key"
ca_bundle = "/etc/nexir/cluster-ca-bundle.pem"

The cluster certificate is used as both server and client credentials and must allow serverAuth and clientAuth. Nexir validates the chain but does not bind certificate SANs to a node ID. Cluster UUID and target-ID checks prevent common misconfiguration; they are not authorization.

Restrict administration

After bootstrap, block mutating commands on application-facing RESP listeners when topology changes are not required:

NEXIR__SERVER__ENABLE_ADMIN_COMMANDS=false

This blocks INIT, membership changes, address updates, and leadership changes. Read-only cluster introspection remains available. The setting is not authentication and does not secure Raft gRPC.

Host and file permissions

sudo useradd --system --home /var/lib/nexir --shell /usr/sbin/nologin nexir
sudo install -d -o nexir -g nexir -m 0700 /var/lib/nexir /etc/nexir/private
sudo chown nexir:nexir /etc/nexir/private/*.key
sudo chmod 0600 /etc/nexir/private/*.key

Adjust for your operating system. Do not run two nodes against one directory. Keep CA private keys offline from database hosts after issuing leaf certificates.

Backups and data protection

Nexir has no supported logical backup, restore, or point-in-time recovery interface. Internal snapshots are not backups. For replaceable beta data only, a stopped-node cold copy of the entire storage path can serve as a same-version node-local recovery artifact. Never copy individual storage files or take a copy from a live process.

Certificate rotation

There is no hot TLS reload. Rotate one node at a time while retaining a voting majority:

1. Restart non-leader voters individually and wait for zero lag.
2. Transfer leadership to a caught-up voter.
3. Restart the former leader.
4. Verify quorum writes and nexir_tls_cert_not_after_timestamp_seconds{surface}.

For CA rotation, first deploy a bundle containing old and new roots, then move leaf certificates, then remove the old root—one rolling restart pass for each phase. Never temporarily disable verification.

Security checklist

• Private network and narrowly scoped firewalls
• Client mTLS and separate Raft peer mTLS
• Protected metrics endpoint
• Admin commands disabled when not needed
• Dedicated OS identity and 0600 private keys
• Encrypted persistent volumes where required
• Certificate-expiry, quorum, disk, and error alerts
• No untrusted multi-tenant access