External Co-Signers

Host provider-specific signing services outside the default self-hosted SDP stack.

Some signing providers need a co-signer or automation process that you run beside the SDP API. Run it outside compose.yml, which starts only SDP's own services: a co-signer has its own secrets, identity, ingress, and availability needs.

Production pattern

Run each co-signer on a managed container service, such as Google Cloud Run or your cloud's equivalent.

  • Use the image and runtime the provider or your operator team supplies.
  • Store co-signer secrets in a cloud secret manager, never in the SDP .env.
  • Give the co-signer a dedicated service account that can read only the secrets it needs.
  • Set ingress and invoker IAM for the provider's flow. Keep ingress private or authenticated unless the provider needs a public callback.
  • Keep at least one instance running (minScale: 1 on Cloud Run) when callback latency or availability matters. Scale to zero only when cold starts are acceptable.
  • Separate development, staging, and production co-signers by provider account, cloud project, service account, and secrets.
  • Alert on failed signing attempts, container restarts, authentication failures, and stale or expired key material.

Utila

SDP signs with Utila directly: select utila in the configurator and fill in its UTILA_* credentials. SDP submits each transaction to Utila and polls until it's signed, up to UTILA_MAX_POLL_ATTEMPTS times every UTILA_POLL_INTERVAL_MS (60 tries, a second apart, by default). Like the local signer, Utila needs a per-organization activation.

UTILA_DESIGNATED_SIGNERS lists the Utila users asked to sign each transaction. Left empty, it's the service account itself.

If your Utila setup runs an automated co-signer, host it outside the stack. infra/utila/cloud-run/ in the repository has Cloud Run scaffolding for one: a service template and a deploy script for an image you supply.