Prerequisites

This is what you will need to get up and running with a Virtual Signer connected to your io.sign environment.

• Compute for the Broker and MPC Core, isolated according to your deployment architecture. The self-hosted Compose example runs separate containers; your production topology may use separate hosts.
• Firewalls and other appropriate security measures enabled. We recommend disabling all incoming ports except SSH or whichever you need to access your instance remotely. Set up appropriate SSH brute force protection and disable root logins.
• Machine-client credentials, an organisation ID, and service URLs issued for your io.sign environment.
• An HTTPS policy service that handles approval calls from the Virtual Signer. This is separate from io.sign event webhooks. See the Approvals in API mode section for more information.
• An ML-KEM-768 disaster recovery key pair, generated by your Product Owner (Business User) before the Virtual Signer is started for the first time. See below.

The machine you decide to run this on should be appropriately hardened (disk encryption turned on, SSH keys required, no root login, etc.)

Disaster recovery key pair

The key pair is generated with the script shipped in the io.finnet Disaster Recovery tool, on a secure workstation that is not the Virtual Signer host. It requires OpenSSL 3.5.0 or later:

./scripts/posix/gen_mlkem768.sh          # macOS / Linux
.\scripts\windows\gen_mlkem768.ps1       # Windows

This produces mlkem768_pub.pem, which is deployed with the Virtual Signer, and mlkem768_priv.pem, which must be stored offline and never placed on the Virtual Signer host. The private key is the only thing that can decrypt the signer's disaster recovery files; if it is lost, those files cannot be recovered.

For the full procedure, including how the Product Owner verifies the deployed key, see Virtual Signer disaster recovery.

Deployment requirements

Use the compute, operating system, container images, and confidential-computing configuration qualified for your release. Confirm sizing against your expected vault count and signing workload; the Broker and MPC Core have different resource requirements.

For the self-hosted Compose guide you need Docker with Compose v2, persistent Broker storage, and certificate/key pairs for mutual TLS between Broker and MPC Core. Production MPC Core needs a supported confidential-computing environment; on the SEV-SNP path this includes a correctly configured guest exposing /dev/sev-guest. An ordinary container on a compatible CPU does not by itself establish that environment.

For AWS, obtain the supported region, instance type, and deployment template from io.finnet. Have your infrastructure team review the template's IAM permissions and scope the deployment role to the resources it creates. See Deploy on AWS.

For development hardware without the required confidential-computing support, simulated cryptography must be enabled explicitly through the development-only settings. Removing a device mount alone does not enable it. Never use this mode with production keys.

Networking requirements

Obtain the exact endpoints for your environment rather than copying a different environment's hostnames.

Permit DNS and the platform-specific supporting services required by your release. Expose health and metrics only to your management network. Configure private CA trust where required; do not bypass TLS validation.

Before first registration

1. Confirm the organisation, device name, and endpoints all belong to the intended environment.
2. Choose the approval mode and policy URL and test the policy response contract.
3. Mount the recovery public key and TLS files at the configured container paths.
4. Configure encryption and persistent storage, including off-host backups.
5. Follow Deploy self-hosted or Deploy on AWS, then Testing the deployment.

The approval mode, policy URL, recovery public key, and Broker–Core channel security are sealed at first registration. Check them before the signer joins a vault.