External Co-Signers

Some signing providers need an operator-managed co-signer or automation process in addition to the SDP API. Run those processes outside the default self-hosted SDP stack.

infra/self-hosted/compose.yml is intentionally unchanged by default. It starts the SDP API, web app, docs app, database, cache, and migrations. Provider co-signers are separate operational services because they usually have their own secret handling, identity, ingress, and availability requirements.

Production pattern

Use a managed container service such as Google Cloud Run, or the equivalent in your cloud, for provider-specific co-signer runtimes.

• Use the provider- or operator-supplied co-signer image and runtime.
• Store co-signer secrets in a cloud secret manager, not in the SDP compose file.
• Run the co-signer with a dedicated service account that can read only the secrets it needs.
• Configure ingress and invoker IAM for the provider flow. Prefer private or authenticated ingress when the provider does not require a public callback.
• Set minScale to 1 when callback latency or provider availability matters; use scale-to-zero only when cold starts are acceptable.
• Keep development, staging, and production co-signers separated 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 readiness

Utila is the motivating future provider for this pattern. When Utila signer support lands, the co-signer should be hosted as an external operator service, for example on Cloud Run, while SDP keeps its API, web, docs, database, and cache inside the normal self-hosted stack.

This page does not make Utila a live SDP signing provider. Do not set SIGNING_PROVIDER=utila until the Utila signer integration explicitly adds that provider option and the required runtime configuration.

Operator scaffolding for a Utila Cloud Run deployment lives in infra/utila/cloud-run/.

That scaffold is intended to host the co-signer endpoint before Utila becomes a default self-hosted service. Operators can deploy their own co-signer image, protect the endpoint with Cloud Run IAM or runtime-level request verification, and pass the resulting service URL and token into a custom SDP Utila integration.