Trust and subprocessors
Who touches the data, when, and what changes the moment you run Corsac Sign yourself.
Where the data lives
Postgres and the uploaded, stamped and sealed files are self-hosted in a volume beside the application. Neither is a managed third-party service, and no document content leaves the instance in the ordinary course of signing.
The sealing key is generated on the instance and never leaves it.
Subprocessors
| Party | Purpose | Data | When |
|---|---|---|---|
| Resend | Transactional email — invitations, reminders, completion and decline notices | Recipient name, email address, document title | Only when the email backend is set to Resend. Your own SMTP server, or no email at all, are the alternatives. |
| RFC 3161 timestamp authorities | Trusted time over the seal and over audit-chain heads | A SHA-256 digest only — never document content, never identities | On every seal and anchor, unless timestamping is turned off. DigiCert and Sectigo are the defaults; the list is per-instance configuration. |
| Hetzner | Hosting for the instance Codefox operates | Everything at rest, as the infrastructure provider | Not applicable when you host Corsac yourself |
| Optional operator sign-in via OAuth | Name and email address of operators — never of signers | Off unless an OAuth client is configured | |
| Codefox Admin | Optional central access grants for operators | Operator identity only | Off unless an admin origin is configured |
Self-hosting inverts this table
The list above describes the instance Codefox operates. Run Corsac Sign on your own infrastructure and the relationship turns over completely: you are the controller, the subprocessors are the ones you choose, and Codefox is not among them.
With no access to your database, your files or your sealing key, Codefox may not be a processor of your data at all. A data processing agreement naming us in that role would be describing a relationship that does not exist — which is worth saying out loud before anyone signs one.