Testing the deployment

Test a Virtual Signer with a disposable vault and no real assets before assigning production signing power. Use the approval policy and deployment topology you intend to operate.

Check health and identity

For the ports in Deploy self-hosted:

curl --fail-with-body 'http://127.0.0.1:2114/core/v1/health?strict=true'
curl --fail-with-body 'http://127.0.0.1:8182/broker/v1/health?strict=true'

Both should return 200 and JSON with status: "ok". The Core health listener is separate from its TLS RPC listener. The Broker check probes Core connectivity and MQTT credentials; the Core check tests MQTT connectivity. Inspect probe details if a strict check returns 503.

Confirm the signer ID and organisation in the management interface or API. Record the ID so you can confirm it remains unchanged after a restart.

Exercise the full workflow

Test	Expected result
Create a vault with a policy-approved key-generation request	The vault completes key generation and has a public key.
Submit an allowed signing request	Policy returns `approve`; an eligible signer set completes signing; the signature verifies against the payload and vault public key.
Submit a disallowed request	This signer does not approve. The overall request can still complete if other signers meet the threshold.
Policy returns `abstain`, malformed JSON, or HTTP `4xx`	No approval from this signer.
Policy is unavailable, times out, or returns HTTP `5xx`	Bounded retries and eventual rejection as described in Custom policy server.
Disconnect a required signer	The request must not be mistaken for a completed signature merely because approvals exist.
Reshare the test vault	The new membership is reflected, the public key is retained, and the intended new signing set can sign.
Restart containers and reboot the host	The same signer ID and shares remain usable; repeat signing successfully.
Restore a backup in an isolated recovery exercise	The approved restoration procedure works without running two copies of the same signer identity.

Export a new recovery bundle after key generation and resharing, and verify it through Virtual Signer disaster recovery. Store it off the signer host.

Development smoke tests

Always approve can isolate connectivity problems on a disposable development signer. It is not a prerequisite for deployment and must not be used with production vaults.

Approval mode is sealed at registration. Do not plan to register with always-approve and then change the same signer to api-approval. Create the production signer with its reviewed policy configuration from the outset.

Record the result

Retain the tested image versions, signer ID, vault ID, request IDs, policy decisions, and final outcomes in your deployment record. Repeat the relevant checks after changing an image, policy, network, certificate, or storage configuration.