# Server Co-Signer

Your signing party, on your infrastructure — the client share on machines you control.

Mobile co-signing is right for human authorisation and wrong for continuous operations. The server
co-signer is the same client party as a binary you deploy: your own cloud, your own network, your
own key share, participating in every signing ceremony without waiting for someone to wake up.

## Deployment reality

- **Runs wherever you run** — Docker Compose or Kubernetes and Helm, in your cloud and your
  compliance zone.
- **Persistence is your choice** — PostgreSQL, SQLite, GCS or S3 for the share.
- **Auto-joins ceremonies** — once deployed the process joins signing sessions over authenticated
  channels, with no operator in the loop.
- **Your perimeter, your share** — Vaultody's two nodes still cannot reach quorum without it.
- **Available on Business and Enterprise.**

## Continuity without concession

Automated flows sign around the clock and stay bounded by the same policy your people operate
under. The co-signer is deployed, monitored and patched by your team like any other internal
service.

## FAQ

**How is this different from the mobile co-signer?**
Same idea, different residence: the co-signer binary on your infrastructure with the share in your
persistence layer. Maximum control, slightly more ops.

**What if the server is compromised?**
The attacker gets one share of three, not a key. A reshare rotates it out, and policy bounds what
it could ever have signed.

## Related

- [API Signer](/features/api-signer)
- [Mobile Co-signer](/features/mobile-co-signer)
- [Key Management](/features/key-management)
- [Enterprise](/enterprise)
