Deploy and Host Let's Seal on Railway

Let's Seal is the open standard for proving any file is real: unaltered, sealed by a known certificate, and in existence by a certain date. Seal PDFs, images, email, and software artifacts; send documents for signature; issue branded certificates and credentials. Anyone can verify a seal forever, free, with no account. It is the Let's Encrypt of document proof: open source (Apache-2.0), run as a public-benefit project, and free forever.

About Hosting Let's Seal

This template deploys the full Let's Seal engine, the same code that runs the hosted service, with no hosted-only paths. Three services come up wired together:

Let's Seal (web): the dashboard, sealing and signature flows, the public verification portal, and the REST API. Public, health-checked, with sealed files stored on a persistent volume.
Signing Service: holds your certificate authority and performs all cryptographic signing. It has no public domain and is only reachable by the web app over Railway's private network.
PostgreSQL: the database, with daily volume backups.

On first boot the signing service creates your own certificate authority on its volume automatically: a root certificate, a signing intermediate, the transparency-log key, and the identity issuer. There is no manual key ceremony. Every secret (session keys, audit-chain key, service tokens, key passphrases) is generated fresh per deployment, so no two deployments share anything. There is no telemetry and no phone-home.

Common Use Cases

Seal contracts, reports, invoices, and certificates so anyone can verify they are genuine and unchanged
Send documents out for signature (remote or in person) with a tamper-evident audit trail
Issue branded certificates and credentials that verify against your own portal
Sign software artifacts, SBOMs, and CI builds under your own certificate authority
Timestamp any file against Bitcoin via OpenTimestamps, with a public transparency log

Dependencies for Let's Seal Hosting

PostgreSQL (included in this template)
Persistent volumes for the certificate authority, sealed-file storage, and the database (included, with daily backups on the CA and database)

Deployment Dependencies

Implementation Details

Getting started (5 minutes)

Click Deploy. No configuration is required; every secret is generated for you.
Open the web service's URL and create your account and organisation.
Seal a file, then open its proof page and verify it. That round trip exercises the whole stack: web app, private network, signing service, your CA, and the database.

First-week checklist

Back up your root key. root-ca.key on the Signing Service volume (/app/ca/out) is the root of your entire trust chain. Copy it somewhere safe and offline (for example with railway ssh). Day-to-day signing only uses the intermediate key, so you can remove the root key from the volume after backing it up.
Leave the daily volume backups on for the CA and database volumes.
Verify a sealed file offline once, so you know your verification story does not depend on any single server.

Optional extras (each is a couple of variables on the web service, then a redeploy; see upstream's web/.env.example for the full reference)

Email: set SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS, SMTP_FROM to send signature invites, completion notices, and credential emails. Without SMTP, invites fall back to share-a-link and the UI says so.
OAuth sign-in: set AUTH_GOOGLE_ID + AUTH_GOOGLE_SECRET (or GitHub, Microsoft, Apple, and others) and the matching button appears on the sign-in page. Email + password always works without this.
Object storage: create a Railway bucket and set the STORAGE_S3_* variables to store sealed files in S3-compatible storage instead of the disk volume. Recommended for high volume or multiple web instances.
Custom domain: add your domain to the web service in Railway, then update APP_URL and AUTH_URL to match.

Operational notes

The app advances pending Bitcoin anchors itself on an internal 30-minute timer; no cron service is needed.
The signing service serves both IPv6 (Railway's private network) and IPv4 (Railway's health checker); this is already handled in the image.
Scaling: a single web instance uses in-memory rate limits. For multiple instances, set the UPSTASH_REDIS_REST_* variables for shared rate limiting and move file storage to a bucket.
The REST API lives under /api/v1 on your domain (seal, verify, anchor, attest), authenticated with an organisation API key from the dashboard. Verification endpoints are public by design.

Why Deploy Let's Seal on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Let's Seal on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.