Self-hosting

A self-hosted Virtual Signer runs in your infrastructure and connects to either your io.sign backend or an io.finnet-managed backend. It has two services with different responsibilities.

Services and connections

Service	Responsibility	Connections
Broker	Registers the signer, receives requests, evaluates policy, and persists signer state.	Authentication, io.sign signing stream, HTTPS policy service, storage, and MPC Core.
Multi-Party Computation (MPC) Core	Performs cryptographic operations and participates in signing ceremonies.	Broker over mutual TLS (mTLS), MQTT messaging, and the configured key-management infrastructure.

The Compose example runs these as vs-broker and vs-core on an isolated container network. Only the Broker mounts the persistent signer state and backup volumes. Each service receives its own private key and the certificate it needs to pin its peer.

Network boundary

Keep the Core RPC listener private to the Broker. The example uses port 8181 for Core RPC, 8182 for the Broker, and 2114 for Core health. Metrics use 2112 for Core and 2113 for Broker by default. Bind management listeners to localhost or an access-controlled management network.

The Broker connects to the backend's HTTP/2 signing stream. MPC Core uses the environment's secure MQTT WebSocket endpoint. The approval service is a separate HTTPS integration; an event webhook receiver cannot substitute for its decision contract.

Confidential computing and encryption

Production MPC Core requires the confidential-computing host configuration supported by your release. For SEV-SNP deployments, verify the guest and device configuration, not just the CPU model. Simulated cryptography is an explicit development-only option.

Configure the supported encryption path before first registration. Azure Secure Key Release (SKR) and the direct-key fallback use different key-custody arrangements; see Configuration. Host or cloud storage encryption provides an additional storage control.

Persistent state and recovery

Preserve the Broker's signer identity and state across container replacement. The Compose example uses signer_data at /var/vsigner and signer_backups at /var/vsigner-backups. Cloud storage is configured separately through IOSIGN_SIGNER_BROKER_STORAGE_BUCKET_URL.

Back up operational state with its required encryption material. Export disaster recovery bundles after key generation and resharing, and store them off the host. Keep the disaster recovery private key in offline custody; only its public half belongs on the Broker. See Virtual Signer disaster recovery.

Availability and capacity

For independent signing capacity, register separate signers with separate state and choose vault weights and a threshold that tolerate the intended outage. Do not create availability by copying one signer's volume and running both identities concurrently.

Test CPU, memory, storage, and network capacity against your workload. A restart test must verify the same signer can still sign, not merely that its containers start. Collect logs and metrics in your own monitoring system, with retention and alerts appropriate to your operations.

Next steps

Review Prerequisites.
Configure and run Deploy self-hosted.
Complete Testing the deployment before assigning production signing power.