Self-Host DocuSeal for Production

A private signing service needs more than a container that starts. The deployment must preserve application secrets and documents, isolate the database and application ports, terminate HTTPS, support accountable administration, and provide tested recovery and upgrade procedures.

The living guide uses a pinned DocuSeal release, PostgreSQL, Caddy-managed HTTPS, persistent application, database, and certificate storage, and separate internal Docker networks. Only the reverse proxy publishes host ports.

Application encryption secrets must remain stable across container recreation and disaster recovery. They belong in a restricted environment file with a protected offline copy, never in source control, tickets, chat, or shared command history.

PostgreSQL and the DocuSeal application should remain private to the Compose network. Attachment storage must be persistent and private, whether it uses a local volume or a separately controlled object store. Administrative access should be named, minimal, and recoverable.

A complete recovery set includes the PostgreSQL backup, attachment data, exact encryption secrets, deployment configuration, image tag, and any modified source or image digest. Copies should leave the server and remain encrypted.

Archive readability is not application recoverability. Scheduled restore drills should verify login, template previews, attachments, submissions, and audit records in an isolated environment. Upgrades should be tested against a restored backup and retain an immediate rollback path.

An HTTP success from the health endpoint confirms that the web process responds. It does not prove database recovery, attachment access, email delivery, or a complete signing workflow.

Monitoring should cover HTTPS, containers, PostgreSQL, storage, backups, mail-provider authentication, message trace, failed invitation jobs, webhooks, host capacity, and administrative changes. A controlled synthetic workflow can test the path without using client documents.

Standard self-hosting should be validated before an agent or MCP integration is introduced. The agent should receive a named, revocable credential for bounded tools, not database or administrator access.

The stable site article avoids treating one release as permanently current. The living Gist contains the version-specific Compose baseline, backup and restore commands, email controls, acceptance checklist, and licensing considerations and should be rechecked against upstream releases before deployment.