Enterprise Ops Platforms

A Self-Hosted, White-Labeled E-Signature Platform With Full Infrastructure Control

How Pfactorial Technologies built and customized a containerized e-signature platform that runs entirely on a client's own infrastructure, with no third-party SaaS dependency.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_DocuSeal_ESignature_Platform image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client needed a document-signing platform where no data left their own servers - no third-party SaaS dependency, no per-seat licensing, and full infrastructure control over how signing workflows run.

Off-the-shelf e-signature tools either require a recurring SaaS subscription with upsell surfaces the client didn't need, or in their unmodified open-source form, lack multi-tenant template sharing and the API automation surface a real deployment requires.

Pfactorial delivered DocuSeal APTask: a self-hosted, containerized e-signature stack extended with a dedicated sharing and permission model, additional REST endpoints, and Pro-gated features and upstream branding removed, running entirely on infrastructure the client controls.

Why this engagement is representative This engagement shows Pfactorial's ability to take an open-source foundation and extend it into a production-grade, self-hosted platform - adding exactly the multi-tenant and automation capability a client needs while deliberately not adopting the SaaS dependencies that come bundled with the commercial alternative.

THE CHALLENGE

Neither the commercial nor the stock open-source path fit the client's requirements - three problems had to be solved to get a self-hosted platform that actually worked for their team.

1. Commercial SaaS brings dependencies the client didn't need

A hosted subscription offers convenience but comes with recurring licensing, upsell surfaces, and - critically - a third party in the data-custody chain, which conflicted with the requirement that no data leave the client's servers.

2. Unmodified open-source lacked multi-tenant sharing

Stock open-source DocuSeal had no role-based template sharing model, meaning teams couldn't collaborate on templates without either sharing full account access or duplicating work.

3. Automation needed a real API surface

The client needed to automate template creation, sending and tracking end to end, which meant every UI workflow needed an equivalent, documented API endpoint - not a partial or undocumented one.

The real brief Not “deploy an e-signature tool” but “take a self-hosted foundation and build the multi-tenant sharing and automation surface a real team actually needs, without introducing a SaaS dependency to get there.”

THE SOLUTION

Pfactorial built the platform as a small stack of containerized services on a single host, with a domain model designed around explicit, granular access control rather than broad account-wide visibility.

Pfactorial_Case_Study_DocuSeal_ESignature_Platform image 2

Figure 2 - From template creation to a delivered, audited, signed document.

Architectural principles

Explicit sharing, not broad visibility - Access to templates a user doesn't own is granted through an explicit sharing record tying a user to a specific template with a defined permission level - view or edit - rather than account-wide access.
Uniform permissions across UI and API - API tokens inherit the role of the user they belong to, so the same permission model applies identically whether the platform is driven from the web UI or automated through the API.
Isolate slow work, not the deployment footprint - Background jobs run embedded in the same application process rather than a separate worker fleet, isolating slow work from the request/response cycle without multiplying the number of services to operate.
Everything on infrastructure the client controls - Documents, signed PDFs, the database and the job queue all live on the client's own infrastructure, with TLS handled by a reverse proxy at the edge - no data custody handed to a third party.

CAPABILITIES DELIVERED

Each capability supports a self-hosted, automatable signing workflow a team can run entirely on their own infrastructure.

CAPABILITY	WHAT IT DOES
Template builder	Upload PDF or DOCX, place fillable fields - text, signature, initials, dates, checkboxes.
Multi-recipient signing	Send invitations to one or more recipients by email, each with a unique signing link.
Full audit trail	Track completion status, download signed PDFs, inspect the complete audit trail per submission.
REST API automation	Every UI workflow - template creation, sending, tracking - available through a documented, role-filtered API.
Granular template sharing	View or edit access grants scoped to individual users and templates, not account-wide.
Office format conversion	DOCX, PPTX and XLSX uploads converted to PDF automatically via headless LibreOffice.

Pfactorial_Case_Study_DocuSeal_ESignature_Platform image 3

Figure 3 - Every service runs on infrastructure the client controls.

Design note Two alternatives were seriously evaluated and deliberately not adopted: the commercial Pro subscription (unnecessary recurring cost and upsell surfaces for a self-hosted deployment) and unmodified open-source DocuSeal (missing the sharing model and API surface the client actually needed). Building on the open-source foundation but extending it was the right middle path.

ENGINEERING FOR SCALE AND RELIABILITY

Running entirely on client-controlled infrastructure means every operational edge case has to be handled without a vendor's ops team behind it. Six decisions carry the platform through them.

Isolated document-conversion workload

A dedicated Node.js service handles DOCX/PPTX/XLSX-to-PDF conversion via headless LibreOffice in its own container, keeping that CPU-intensive workload from affecting the main application's responsiveness.

Version-gated compatibility fallback

A version-gated code path automatically falls back to a compatible PNG encoding method for template preview rendering on older base-OS images, so previews render correctly regardless of the underlying OS version.

Pinned, persistent file storage path

Uploaded documents and signed PDFs live under a fixed, absolute path explicitly pinned in deployment configuration, so files persist across container rebuilds rather than being written to an ephemeral layer.

Migration-only schema management

The database has no static schema snapshot - every environment builds its schema by replaying the full migration history, and re-running migrations against an already-current database is always a safe no-op.

Automatic legacy-signing compatibility

The application container automatically enables OpenSSL's legacy provider at startup, so signing certificates using older algorithms work without additional manual configuration.

Session-stable security policy

The Content-Security-Policy nonce is derived from the session ID rather than randomized per request, keeping the policy consistent across page navigations in the Turbo-based UI without weakening it.

DELIVERY APPROACH

The engagement moved from evaluating alternatives to a fully containerized, client-hosted deployment.

1. Alternative evaluation - assessing the commercial Pro subscription and unmodified open-source DocuSeal against the client's requirements.

2. Domain model & access control - designing the account/template/submission/submitter/envelope entity model with explicit template-sharing permissions.

3. Feature extension - removing Pro-gated UI and upstream branding, adding the sharing model and additional REST endpoints.

4. Core signing workflow - template creation, multi-recipient sending, signing, and automated result assembly.

5. Deployment packaging - the Docker Compose stack - application, database, cache/queue, converter - behind an Nginx reverse proxy with Let's Encrypt TLS.

6. Operational hardening - compatibility fallbacks, persistent storage configuration, and legacy signing-certificate support.

RESULTS AND IMPACT

Pfactorial_Case_Study_DocuSeal_ESignature_Platform image 4

Figure 4 - Key outcomes from this engagement.

The client runs a fully self-hosted e-signature platform with no third-party SaaS dependency, no per-seat licensing, and complete control over where document data lives.

Every signing workflow is automatable through the documented REST API, letting the client integrate signing into their own systems rather than working around a closed platform.

What it enabled commercially

The client eliminated recurring per-seat SaaS costs and third-party data custody entirely, while gaining a template-sharing and automation surface that the unmodified open-source alternative didn't provide.

WHY PFACTORIAL

This engagement reflects Pfactorial's ability to take an open-source foundation and extend it into a genuinely production-ready, self-hosted platform - evaluating build-vs-buy honestly rather than defaulting to either a SaaS subscription or an unmodified free tool.

Pfactorial_Case_Study_DocuSeal_ESignature_Platform image 5

Figure 5 - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with organizations that need document workflows running entirely on their own infrastructure. If you're evaluating a self-hosted e-signature or document-workflow platform, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Pfactorial_Case_Study_DocuSeal_ESignature_Platform image 6

© 2026 Pfactorial Technologies. Client identity and product-specific implementation detail are withheld or generalized; no client data, credentials, source code, or infrastructure detail is included in this document.

Result and Analysis

ENGAGEMENT SNAPSHOT

How Pfactorial Technologies built and customized a containerized e-signature platform that runs entirely on a client's own infrastructure, with no third-party SaaS dependency.