Documenso: die selbst gehostete Alternative für digitale Signaturen
Die Open-Source-Alternative zu DocuSign.
Auf einen Blick
- Was ist das?
- Documenso ist eine Open-Source-Signaturplattform in TypeScript, die sich als DocuSign-Alternative versteht und den Vertrauensbeweis über die Selbstverwaltung des Codes sucht. Der Text ordnet Tech-Stack, lokale Entwicklung mit npm run dx, Docker-Betrieb, Beitragsmodell und die AGPL-3.0-Lizenz ein.
- Für wen ist es gedacht?
- Documenso passt für Organisationen, die elektronische Unterschriften unter eigener Datenkontrolle abwickeln wollen und bereit sind, Node.js v22, eine PostgreSQL-Datenbank und den nötigen Betrieb zu stemmen. Ungünstig ist es für Team-Entwickler, die auf offene Pull-Requests hoffen, denn das Projekt nimmt externe PRs seit der Ankündigung zum Beitragsstopp nicht mehr an.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Vertrauensargument von Documenso
Documenso tritt mit einer selbstbewussten These an: Digitales Unterschreiben sei heute technisch einfach, füge aber jeder Signatur eine neue Partei hinzu, den Anbieter des Signaturwerkzeugs. Das Projekt formuliert im README, es wolle das vertrauenswürdigste Dokumentensignatur-Werkzeug der Welt sein, und leitet dieses Ziel direkt aus der Offenheit ab: Wer Documenso selbst hostet, kann nachprüfen, wie das Werkzeug im Kern arbeitet. Der Slogan lautet entsprechend The Open Source DocuSign Alternative.
Der Gedanke ist mehr als Marketing, denn bei einer Signaturplattform sitzt der Vertrauensgeber tatsächlich in der Mitte des Vorgangs. Mit 14.791 Sternen, TypeScript als Hauptsprache und einer AGPL-3.0-Lizenz ist das Projekt quantifizierbar verankert; die offiziellen Docker-Images stehen auf DockerHub und GitHub Container Registry bereit. Ob die Plattform die eigenen Compliance-Anforderungen erfüllt, etwa qualifizierte elektronische Signaturen nach eIDAS, sagt das README nicht aus, und genau diese Lücke sollte vor jedem produktiven Einsatz geklärt werden.
Der Tech-Stack: React Router v7, Hono, Prisma und PDF-Werkzeuge
Der Stapel im README liest sich wie eine Bestandsaufnahme der TypeScript-Welt von 2026: React Router v7 als Framework, Hono als Server, Prisma als ORM, Tailwind CSS mit shadcn/ui und Radix UI für die Oberfläche, react-email für Vorlagen, Lingui für Internationalisierung und tRPC für die API. Die PDF-Seite ist dreigeteilt: @libpdf/core übernimmt die PDF-Signaturen, pdf.js die Ansicht, @cantoo/pdf-lib die Manipulation der Dokumente.
Dieses Zusammenspiel ist der technische Kern des Produkts: Ein Dokument muss gerendert, platzierbar und am Ende kryptografisch signiert werden, und jede dieser Aufgaben hat ihre eigene Bibliothek. Aus Betriebssicht auffällig ist der Vertrag mit Stripe für Zahlungen, was auf die kommerzielle Seite der Plattform verweist, und Biome für Linting sowie Playwright für End-to-End-Tests, was die Entwicklerseite betrifft. Wer den Code erweitern will, sollte mit allen drei PDF-Bibliotheken umgehen können, denn die Signaturlogik verteilt sich darauf.
Lokale Entwicklung mit npm run dx und npm run d
Für die lokale Entwicklung verlangt das README Node.js ab Version 22, eine PostgreSQL-Datenbank und optional Docker. Der schnellste Weg läuft über fünf Schritte: Repository forken und klonen mit git clone https://github.com/<your-username>/documenso, die .env-Datei aus .env.example erzeugen, im Projektstamm npm run dx starten, das eine PostgreSQL-Datenbank und einen Inbucket-Mailserver in Containern hochzieht, und dann npm run dev ausführen. Wer es noch schneller möchte, nutzt npm run d, das beide Schritte zusammenfasst.
Die Zugänge nach dem Start sind im README nummeriert: Die App läuft auf http://localhost:3000, der eingehende Mailzugriff auf http://localhost:9000, die Datenbankverbindung auf Port 54320, und das S3-Speicher-Dashboard auf http://localhost:9001. Diese vier Endpunkte decken genau die externen Abhängigkeiten der Plattform ab, Datenhaltung, Mailversand und Objektspeicher. Für Umgebungen ohne Docker gibt es eine eigene manuelle Setup-Anleitung in der Dokumentation, dazu DevContainer-Unterstützung für VSCode und einen Gitpod-Startknopf.
Selbst hosten mit den offiziellen Docker-Images
Neben der Entwicklungsumgebung positioniert sich Documenso als self-hosted Produkt. Die offiziellen Images liegen unter documenso/documenso auf DockerHub und unter demselben Namen auf GitHub Container Registry, das README verweist für die Einrichtung auf den Abschnitt zur Docker-Konfiguration und die Dokumentation unter docs.documenso.com. Damit ist der Weg für eine eigene Instanz dokumentiert, auch wenn das aus dem Material sichtbare Setup noch keine Details zu Backups, TLS oder Skalierung preisgibt.
Wer die Kontrolle über eine Signaturplattform übernimmt, trägt allerdings auch die Verantwortung, die bei einem SaaS-Anbieter im Servicepreis steckt: Schlüsselverwaltung, Protokollierung und Verfügbarkeit der signierten Dokumente. Das Argument des Projekts, Vertrauen durch Einsicht in den Code aufzubauen, funktioniert nur, wenn der Betreiber diese Betriebsverantwortung tatsächlich übernehmen kann oder will. Für Organisationen mit zusätzlichen Anforderungen an Flexibilität und Kontrolle gibt es einen Enterprise-Plan, zu dem das README einen Kontaktweg über cal.com nennt.
Beitragsmodell: Issues statt externer Pull-Requests
Ein ungewöhnlicher Abschnitt im README betrifft die Zusammenarbeit: Documenso nimmt keine externen Pull-Requests mehr an, abgesehen von einer kleinen Gruppe vertrauenswürdiger Beitragender, die das Projekt direkt anspricht. Als Begründung verweist der Blogbeitrag Why We're Pausing External Pull Requests. Die empfohlene Beitragsform sind ausführliche Issues, dazu gibt es einen Contribution Guide und einen Verhaltenskodex.
Für die Bewertung des Projekts ist diese Entscheidung doppelt relevant. Sie verlangsamt Fremdbeiträge, signalisiert aber auch, dass die Kernentwicklung unter klarer Kontrolle eines Teams bleibt, was bei Signaturcode plausibel ist, weil jede Änderung an der Signaturlast Verantwortung trägt. Das README hält ausdrücklich fest, dass Documenso open source bleibt: lesen, prüfen, ausführen und forken. Wer auf Fork-Strategie oder Community-Fork-Betreuung setzt, findet hier die Grenze der offiziellen Kooperation markiert.
AGPL-3.0 und die Folgen für den Betrieb
Documenso steht unter AGPL-3.0, einer der anspruchsvollsten Freien-Lizenzen, wenn es um Netzwerkdienste geht. Der Abschnitt 13 dieser Lizenz verlangt, dass Nutzern eines über ein Netz angebotenen modifizierten Standes der Quelltext zur Verfügung gestellt wird. Wer Documenso unverändert hostet, liefert ohnehin denselben öffentlichen Code aus; wer eigene Erweiterungen einbaut und Dritten den Dienst anbietet, sollte den Modifikationsumfang dokumentieren und veröffentlichen können.
Das unterscheidet die Einführung deutlich von MIT- oder Apache-Projekten und gehört für Organisationen mit eigene Richtlinien zur Softwaregewinnung in die Prüfung, bevor der erste Container startet. Im Zusammenspiel mit der geschlossenen Beitragspraxis zeichnet sich ein Modell ab, das Lesbarkeit und Forkbarkeit garantiert, die Mitbestimmung an der Codebasis aber bewusst beim Kernteam belässt. Wer damit leben kann, erhält eine vollständige Signaturplattform mit dokumentiertem lokalen Setup, produktionsnahen Images und einer klaren Lizenzlinie.
Redaktionelles Fazit
Documenso passt für Organisationen, die elektronische Unterschriften unter eigener Datenkontrolle abwickeln wollen und bereit sind, Node.js v22, eine PostgreSQL-Datenbank und den nötigen Betrieb zu stemmen. Ungünstig ist es für Team-Entwickler, die auf offene Pull-Requests hoffen, denn das Projekt nimmt externe PRs seit der Ankündigung zum Beitragsstopp nicht mehr an. Wer die Plattform einführt, sollte zuerst die Dokumentation unter docs.documenso.com und die .env.example gegen die eigenen Mail- und Speicheranforderungen abgleichen, denn ein Signaturwerkzeug ohne erreichbaren Mailversand ist im Alltag wertlos.
Community-Notizen