For PKI operators
Run Confium in production
A Mode 2 or Mode 3 deployment lives or dies on operational discipline. This page covers the deployment runbook, the monitoring hooks, the backup and recovery procedures, and the upgrade path.
Deployment topology
A production Confium deployment has four moving parts:
- Coordinator — long-lived service that orchestrates signing sessions. Deploy one per region for redundancy; they share session state via the transparency log.
- Signers — processes holding individual threshold shares. One per authorized party. Can be online or offline; async sessions tolerate both.
- Transparency log — append-only Merkle tree recording every signing event. Run as a separate service with its own persistence layer.
- Witness(es) — services that gossip tree heads between coordinators. Required for split-view attack detection.
Deployment runbook
Step 1: Provision the coordinator
# Install the Confium CLI and daemon.
cargo install confium-cli --locked
# Generate the deployment manifest.
cat > deploy.toml <Step 2: Provision signers
# On each signer host (director-1 through director-5):
confium signer init --share /etc/confium/share.enc
# (the share was generated during the initial key ceremony)
confium signer start \
--bind 0.0.0.0:7500 \
--coordinator coord.internal:7443 \
--identity director-1Step 3: Provision the transparency log
confium-log init --backend lmdb --path /var/lib/confium/log
confium-log serve --bind 0.0.0.0:7444Step 4: Provision a witness
confium witness serve \
--bind 0.0.0.0:7445 \
--peers coord-eu.internal:7443,coord-apac.internal:7443 \
--anchor-interval 3600Step 5: Smoke test
echo "test message" | confium sign \
--coordinator coord.internal:7443 \
--algorithm ECDSA-P256
# Expected: a DER-encoded signature, anchored in the transparency log
# with an inclusion proof.Coordinator session lifecycle in production
Sessions are async. A signer in Tokyo can submit during their workday; a signer in New York submits hours later; the coordinator combines when quorum is reached. Below is a representative 9-hour session.
Monitoring
Export Prometheus metrics from the coordinator, signers, and transparency log. The critical metrics to alert on:
| Metric | Alert threshold |
|---|---|
confium_signing_sessions_in_flight | Sustained > 100 (load) |
confium_signing_session_age_seconds p99 | > 24h (signers not joining) |
confium_signing_failures_total | Any non-zero (signer errors) |
confium_quorum_reached_total | Drops to zero (no successful signing) |
confium_transparency_log_tree_size | Stops growing (writer broken) |
confium_witness_divergence_detected_total | Any non-zero (SPLIT-VIEW — investigate immediately) |
confium_policy_violations_total | Any non-zero (something tried to use a disallowed algorithm) |
Also alert on standard process health: CPU, memory, disk (the transparency log grows monotonically), and TLS certificate expiry on the coordinator's QUIC listener.
Backup and recovery
Signer shares
Each signer's share is encrypted at rest. Back up the encrypted
share file to your standard key-management infrastructure (HSM,
KMS, password manager). Never back up an unencrypted share —
if you lose it, use confium-tc-reshare to re-share
and assign a new share to a replacement signer.
Transparency log
The transparency log is append-only. Back it up via standard snapshot tooling (LMDB hot backup, ZFS snapshot, etc.) at hourly cadence. The log's Merkle root is reproducible from the entries, so backups are content-addressable.
Coordinator state
The coordinator holds in-flight session state. This state can be reconstructed from the transparency log (which records every session) — the coordinator itself is stateless across reboots.
Upgrading
Coordinator upgrade
Coordinators can be upgraded one at a time if you run multiple. Drain sessions from the old coordinator (let in-flight sessions complete), shut it down, deploy the new version, restart. In-flight session state is recoverable from the transparency log.
Signer upgrade
Signers can be upgraded independently as long as the protocol version is compatible. The FROST / CMP20 / GG18 protocols are versioned; the coordinator negotiates the highest mutually-supported version per session.
Share re-sharing (proactive refresh)
Run confium-tc-reshare on a fixed cadence
(monthly is common; quarterly for lower-assurance deployments).
This re-randomizes all shares without changing the underlying
secret, defeating any long-running share-aggregation attack.
# Trigger a re-share. All signers must participate.
confium reshare \
--coordinator coord.internal:7443 \
--new-threshold 3 \
--new-total 5Capacity planning
Per-signer throughput (FROST-P256, single core):
- Sign share: ~5ms
- Verify share: ~2ms
- Aggregate (coordinator): ~1ms per share
End-to-end session latency (3-of-5 quorum, same region): ~30ms over QUIC. Cross-region: 100–200ms typical. Async sessions (hours-long): not throughput-bound; bounded by signer availability.
For high-throughput Mode 2 deployments (TLS signing for a high-traffic site), batch multiple messages per session to amortize round-trip cost.
Incident response
- Coordinator compromise. Replace from clean image. Signing key is not on the coordinator — it's split across signers. Resume sessions from transparency log.
- Signer compromise. Trigger immediate re-share excluding the compromised signer. Investigate which sessions the compromised signer participated in via the audit log.
- Transparency log compromise. Witnesses detect divergence via gossip. Switch to backup log; replay recent tree heads. OTS anchors in Bitcoin preserve irrefutable history.
- Algorithm break. Deploy composite-signature update that includes the broken algorithm alongside a post-quantum one. Issue new certificates under the composite profile.
Where to go next
- Architecture overview
- Architect\'s guide — threat model and integration patterns.
- Transparency logs deep dive
- Workspace map — pick the right crates for your deployment.