Self-Hosting Your Document Signing Platform: A Complete Guide

There is a growing recognition among engineering and compliance teams that not every SaaS tool should be someone else’s SaaS. Document signing — especially for terms acceptance and policy agreements — is one of those areas where self-hosting makes a compelling case. Your acceptance records are legal evidence, your document versions are compliance artifacts, and your signer data is PII. Hosting all of that on infrastructure you control is not paranoia; it is good engineering.

Why Self-Host Your Signing Platform?

Data Sovereignty

When a user accepts your terms of service, that acceptance record is a legal artifact. It may be subject to data residency requirements under GDPR, provincial privacy laws, or industry regulations. With a cloud-hosted signing service, your acceptance data lives on the vendor’s infrastructure, in the vendor’s jurisdiction, subject to the vendor’s data handling practices.

Self-hosting puts you in control. Your data stays on servers you choose, in regions you select, governed by retention policies you define. When a customer or regulator asks where their data is stored, you have a concrete answer.

Compliance Control

SOC 2, ISO 27001, HIPAA, and other compliance frameworks care about how you handle sensitive data. Terms acceptance records contain PII (names, email addresses, IP addresses) and constitute legal proof of consent. Keeping this data within your existing compliance perimeter — the same infrastructure where you already manage access controls, encryption, and audit logging — is simpler than extending your compliance boundary to cover a third-party vendor.

Security

Every external SaaS tool is an additional entry in your vendor risk assessment. Each one has its own authentication model, its own API surface, its own security posture. Self-hosting eliminates the vendor as an attack surface. Your signing platform inherits the same security controls — network policies, WAF rules, encryption at rest — that protect the rest of your infrastructure.

Cost Predictability

Cloud signing services typically charge per envelope, per user, or per API call. When you need thousands of users to accept updated terms, those costs add up. A self-hosted platform has fixed infrastructure costs that do not scale with signing volume. Your tenth acceptance costs the same as your ten-thousandth.

Uptime Independence

If your signing vendor has an outage during a product launch or a compliance deadline, your terms acceptance workflow is down and there is nothing you can do about it. Self-hosting means your signing platform has the same uptime characteristics as the rest of your infrastructure — and you have the ability to debug and recover on your own timeline.

TheTerms Self-Hosting Overview

TheTerms is designed for self-hosting from the ground up. It ships as a Docker image with PostgreSQL as its only external dependency. There is no Redis requirement, no separate worker process, no message queue — just the application server and the database.

Architecture

The self-hosted deployment consists of two components:

Application container: A Next.js standalone server that handles the web interface, tRPC API (for the UI), and REST API (for external integrations)
PostgreSQL database: Stores documents, versions, signing records, team data, and audit trails

Both components can run on a single server for small deployments or be separated across infrastructure for larger teams.

System Requirements

TheTerms is lightweight by design:

CPU: 1 vCPU minimum, 2 recommended
Memory: 512 MB minimum, 1 GB recommended
Storage: 1 GB for the application, plus database storage that scales with your document volume
Database: PostgreSQL 14 or later

A $10-20/month VPS from any cloud provider is sufficient for most teams.

Basic Setup

The following is a high-level walkthrough of getting TheTerms running on your own infrastructure. For detailed step-by-step instructions, environment variable reference, and advanced configuration, see the full self-hosting guide.

1. Prepare Your Environment

You need Docker and Docker Compose installed on your server, and a domain name pointed at your server’s IP address.

2. Configure Environment Variables

TheTerms uses environment variables for all configuration. The key variables you need to set:

Database connection: Your PostgreSQL connection string
Authentication: NextAuth secret and OAuth provider credentials (Google, GitHub, or others)
Application URL: The public URL where your instance will be accessible
Email: SMTP configuration for sending signing invitations

Copy the provided .env.example file and fill in your values. The example file documents every variable with descriptions and generation commands for secrets.

3. Start the Application

With Docker Compose, starting TheTerms is a single command. The provided docker-compose.yml file defines both the application and database services, handles networking between them, and configures volume mounts for persistent database storage.

4. Run Database Migrations

On first startup, you need to run the Prisma migrations to create the database schema. This is a one-time operation that also runs automatically on subsequent updates when the schema changes.

5. Verify the Deployment

Once the application is running, you should be able to access the web interface at your configured domain. Create your first organization, set up a container, and test the signing flow end-to-end to verify everything is working.

Production Considerations

Running a self-hosted signing platform in production requires the same operational discipline as any other critical service.

Backups

Your database contains legal records — acceptance timestamps, document versions, and signer identity data. Implement automated daily backups with point-in-time recovery capability. Test your restore process regularly. A backup you have never tested is not a backup.

PostgreSQL’s pg_dump handles logical backups. For larger deployments, consider continuous archiving with WAL-based backup tools like pgBackRest or Barman.

SSL/TLS

Terms acceptance pages are accessed by external users clicking signing links. These pages must be served over HTTPS. Use a reverse proxy like Nginx or Caddy in front of the application container. Caddy provides automatic HTTPS with Let’s Encrypt certificates, which is the simplest path for most deployments.

Monitoring

At minimum, monitor:

Application health: The /api/v1/health endpoint returns the application and database status
Database connections: Watch for connection pool exhaustion under load
Disk space: Database storage and Docker volume usage
Certificate expiry: If you are managing your own SSL certificates

Standard monitoring stacks (Prometheus + Grafana, Datadog, or even simple uptime checks) integrate with TheTerms without any custom configuration.

Updates

TheTerms publishes Docker images for each release. Updating is a pull-restart cycle: pull the new image, restart the container, and the application automatically runs any pending database migrations. Review the release notes before updating — breaking changes, if any, are documented with migration steps.

High Availability

For teams that need high availability, the stateless application container can be scaled horizontally behind a load balancer. PostgreSQL high availability can be achieved with streaming replication and automated failover using Patroni or your cloud provider’s managed PostgreSQL offering.

When to Self-Host vs. Use the Hosted Version

Self-hosting is the right choice when:

You have data residency or sovereignty requirements
Your compliance framework requires signing data to stay within your infrastructure boundary
You want full control over backups, retention, and data lifecycle
You have the operational capacity to manage a Docker deployment

The hosted version is the right choice when:

You want to get started immediately without infrastructure setup
You prefer managed operations (backups, updates, monitoring handled for you)
Your team does not have dedicated DevOps capacity
You are evaluating the product before committing to self-hosting

Both deployment modes offer the same features, the same API, and the same data model. You can start with hosted and migrate to self-hosted later, or vice versa.

Next Steps

Ready to deploy TheTerms on your own infrastructure? Here are your starting points:

Self-hosting guide: Detailed setup instructions, environment variable reference, and configuration options
GitHub repository: Source code, Docker Compose files, and issue tracker
API documentation: REST API reference for integrating with your applications

If you want to evaluate the platform first, create a free account on the hosted version. The workflow and API are identical — the only difference is who manages the infrastructure.