Deploy and Host DocuSeal on Railway

DocuSeal is an open-source document signing platform — a self-hosted DocuSign alternative. Build fillable PDF forms in a WYSIWYG editor, send them for signature, collect legally binding e-signatures with a PKCS#7 signing certificate, and keep every document on infrastructure you control. This template runs DocuSeal 3.1.7 with Postgres, an admin account seeded before the URL is ever reachable, and a volume so signed documents survive redeploys.

About Hosting DocuSeal

DocuSeal is a Rails application that stores its records in Postgres and its actual files — uploaded PDFs, signed documents, attachments, the audit trail — on disk through ActiveStorage, under WORKDIR (/data/docuseal), unless S3, GCS or Azure is configured. Two things about that matter on a platform that redeploys containers:

The files need a volume. Without one, Postgres keeps the template and submission rows while the documents themselves vanish on the next deploy — the app still lists them, and every download 404s.
The instance must be claimed at boot. DocuSeal's first-run /setup page skips authentication for as long as no user exists, so on a public URL the first stranger who opens it becomes the administrator of an account holding your documents.

This template addresses both. The admin account, the app_url config and the e-signature certificate are created before Puma binds a port, and the volume is created and given to the service user before the app starts. Puma's worker count is computed from the container's own CPU and memory limits rather than the host's core count. The image is pinned by digest, because DocuSeal ships roughly weekly and migrates its database forward on boot.

Credentials are generated per deploy. The admin e-mail is admin@example.com and the password is the generated DOCUSEAL_ADMIN_PASSWORD variable — change the e-mail before deploying if you like, and change the password inside the app after your first sign-in. Re-seeding runs on every boot, so setting a new DOCUSEAL_ADMIN_PASSWORD and redeploying is also a supported password reset.

Why Deploy DocuSeal on Railway?

Railway gives DocuSeal exactly the three pieces it needs — a container, a managed Postgres and a persistent volume — with TLS, a public domain and private networking already wired together. There is no VPS to patch, no reverse proxy to configure and no S3 bucket to create before the first document can be signed. Usage-based billing suits a signing service well: it idles cheaply between signature requests and scales up for the bursts.

Common Use Cases

Client contracts, statements of work and NDAs signed without per-seat DocuSign fees
HR paperwork — offer letters, policy acknowledgements, onboarding forms
Embedding signing into your own product through DocuSeal's REST API and webhooks
Keeping signed documents and personal data inside your own infrastructure for privacy or regulatory reasons

Dependencies for DocuSeal

A PostgreSQL database (included in this template)
A persistent volume for uploaded and signed documents

Deployment Dependencies

DocuSeal: https://www.docuseal.com
Source: https://github.com/docusealco/docuseal
Railway wrapper image: https://github.com/bon5co/docuseal-railway

Implementation Details

Two services: DocuSeal on a volume mounted at /data, and Postgres on a volume at /var/lib/postgresql. No separate Redis service is billed — with REDIS_URL unset the DocuSeal image runs its own Redis and an embedded Sidekiq inside the web container. The healthcheck is Rails' /up.