Documenso mit Docker installieren: Open-Source-Alternative zu DocuSign selbst hosten

Wer rechtssichere digitale Signaturen braucht, greift meist zu DocuSign oder Adobe Acrobat Sign und sendet dabei unweigerlich sensible Verträge in US-amerikanische Rechenzentren. Documenso schließt diese Lücke: Das Projekt (AGPL-3.0, über 13.000 GitHub-Sterne, aktuelle Version v2.19.0) bietet digitale Dokumentensignaturen nach dem EU-Standard PAdES auf dem eigenen Server. Für KMU, Rechtsabteilungen, Steuerkanzleien und HR-Teams bedeutet das: keine Abhängigkeit von US-Anbietern, volle DSGVO-Kontrolle und ein Audit-Trail, der auf der eigenen Infrastruktur liegt. Diese Anleitung führt Sie Schritt für Schritt durch die Docker-Compose-Installation, von der Ordnerstruktur über das Signaturzertifikat bis zur ersten Einladung an Unterzeichner.

Voraussetzungen

1. Docker Engine 20.10+ und Docker Compose v2.0+ auf dem Host installiert; falls noch nicht geschehen, hilft die Anleitung Docker und Docker Compose auf Linux installieren.
2. Linux-Host, VM oder NAS mit mindestens 2 GB RAM, 2 CPU-Kernen und 20 GB freiem Speicher (Minimum: 1 GB RAM, 1 Kern, 10 GB).
3. Eigene Domain mit DNS-A-Record auf den Server und ein TLS-Zertifikat, am einfachsten über Traefik oder Caddy mit automatischem Let's-Encrypt-Support. Für HTTPS ohne eigenen Reverse Proxy gilt die Anleitung Caddy als Reverse Proxy einrichten.
4. OpenSSL auf dem Host (für Secret- und Zertifikatgenerierung).
5. SMTP-Zugangsdaten eines E-Mail-Providers (z. B. Resend, Mailgun, eigener Postfix); ohne funktionierenden Mail-Versand können keine Signaturanfragen verschickt werden.
6. Root- oder sudo-Zugang zum Host (für Verzeichnis- und Berechtigungsoperationen).

Schritt 1: Projektordner und Zertifikatsverzeichnis anlegen

Legen Sie zunächst die Ordnerstruktur auf dem Host an. Der Pfad /opt/documenso ist der dokumentierte Standard-Mountpunkt für das Signaturzertifikat im Container:

sudo mkdir -p /opt/documenso
cd /opt/documenso

Setzen Sie die Berechtigungen so, dass Ihr Admin-Benutzer die Dateien anlegen kann, der Container aber nur Lese-Zugriff auf das spätere Zertifikat bekommt:

sudo chown $(whoami):$(whoami) /opt/documenso

Verifizieren: ls -la /opt/ | grep documenso: Das Verzeichnis muss mit Ihrem Benutzer als Eigentümer existieren.

Schritt 2: Signaturzertifikat (.p12) erstellen

Documenso benötigt ein PKCS#12-Zertifikat für PAdES-Signaturen. Das Image enthält kein Standard-Zertifikat, Sie müssen es selbst bereitstellen. Für interne Tests oder KMU-Einsatz ohne Anforderung an qualifizierte elektronische Signaturen (QES) reicht ein selbstsigniertes Zertifikat:

# Schlüssel und selbstsigniertes Zertifikat erzeugen (10 Jahre Laufzeit)
openssl req -x509 -nodes -newkey rsa:4096 \
  -keyout /opt/documenso/key.pem \
  -out /opt/documenso/cert.pem \
  -days 3650 \
  -subj "/CN=Documenso Signing/O=Mein Unternehmen/C=DE"

# PKCS#12-Bundle MIT Passwort erstellen (Pflicht, ohne Passwort schlägt Documenso fehl)
openssl pkcs12 -export \
  -out /opt/documenso/cert.p12 \
  -inkey /opt/documenso/key.pem \
  -in /opt/documenso/cert.pem \
  -passout pass:MEIN_SICHERES_ZERTPASSWORT

# Zwischendateien entfernen, Berechtigungen setzen
rm /opt/documenso/key.pem /opt/documenso/cert.pem
sudo chown 1001:1001 /opt/documenso/cert.p12
sudo chmod 400 /opt/documenso/cert.p12

Notieren Sie sich das gewählte Passwort, es kommt in Schritt 3 als NEXT_PRIVATE_SIGNING_PASSPHRASE in die .env. Für rechtssichere qualifizierte Signaturen (QES) nach eIDAS benötigen Sie ein Zertifikat einer akkreditierten Vertrauensstelle (z. B. D-Trust, Bundesdruckerei).

Verifizieren: ls -la /opt/documenso/cert.p12: Die Ausgabe muss -r-------- (400) mit Eigentümer 1001 zeigen. Mit openssl pkcs12 -info -in /opt/documenso/cert.p12 -passin pass:MEIN_SICHERES_ZERTPASSWORT -nokeys 2>/dev/null | head -5 können Sie das Zertifikat inhaltlich prüfen.

Schritt 3: Secrets generieren und .env anlegen

Erzeugen Sie zunächst alle benötigten Zufalls-Secrets mit OpenSSL auf der Kommandozeile. Drei unabhängige Secrets mit je mindestens 32 Zeichen sind Pflicht:

openssl rand -base64 32  # NEXTAUTH_SECRET
openssl rand -base64 32  # NEXT_PRIVATE_ENCRYPTION_KEY
openssl rand -base64 32  # NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY
openssl rand -base64 24  # POSTGRES_PASSWORD

Legen Sie anschließend die Datei /opt/documenso/.env an und füllen Sie sie mit Ihren Werten:

# ── Datenbank ────────────────────────────────────────────────
POSTGRES_USER=documenso
POSTGRES_PASSWORD=IHR_DB_PASSWORT_HIER
POSTGRES_DB=documenso
NEXT_PRIVATE_DATABASE_URL=postgresql://documenso:IHR_DB_PASSWORT_HIER@database:5432/documenso

# ── Auth & Verschlüsselung ────────────────────────────────────
NEXTAUTH_SECRET=IHR_NEXTAUTH_SECRET_HIER
NEXT_PRIVATE_ENCRYPTION_KEY=IHR_ENCRYPTION_KEY_HIER
NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY=IHR_SECONDARY_KEY_HIER

# ── URLs (exakt wie im Browser erreichbar) ───────────────────
NEXT_PUBLIC_WEBAPP_URL=https://sign.example.com
NEXT_PRIVATE_INTERNAL_WEBAPP_URL=http://localhost:3000

# ── E-Mail ────────────────────────────────────────────────────
NEXT_PRIVATE_SMTP_TRANSPORT=smtp-auth
NEXT_PRIVATE_SMTP_HOST=smtp.example.com
NEXT_PRIVATE_SMTP_PORT=587
NEXT_PRIVATE_SMTP_USERNAME=absender@example.com
NEXT_PRIVATE_SMTP_PASSWORD=IHR_SMTP_PASSWORT
NEXT_PRIVATE_SMTP_FROM_ADDRESS=absender@example.com
NEXT_PRIVATE_SMTP_FROM_NAME=Documenso

# ── Signaturzertifikat ────────────────────────────────────────
NEXT_PRIVATE_SIGNING_PASSPHRASE=MEIN_SICHERES_ZERTPASSWORT

# ── Optional: Telemetrie deaktivieren ─────────────────────────
DOCUMENSO_DISABLE_TELEMETRY=true

# ── Optional: Registrierung nach Erst-Setup sperren ──────────
# NEXT_PUBLIC_DISABLE_SIGNUP=true

Schützen Sie die Datei vor fremdem Zugriff:

chmod 600 /opt/documenso/.env

Verifizieren: ls -la /opt/documenso/.env muss -rw------- (600) anzeigen. Prüfen Sie kritische Werte: grep NEXT_PRIVATE_DATABASE_URL /opt/documenso/.env: Der Hostname muss database lauten (Docker-Compose-Servicename), niemals localhost.

Schritt 4: compose.yaml anlegen

Erstellen Sie die Compose-Datei unter /opt/documenso/compose.yaml. Der healthcheck beim Datenbank-Service ist wichtig: Documenso wartet damit auf eine tatsächlich startbereite PostgreSQL-Instanz, bevor es mit Migrationen beginnt.

name: documenso

services:
  database:
    image: postgres:15
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - database:/var/lib/postgresql/data

  documenso:
    image: documenso/documenso:v2.19.0
    restart: unless-stopped
    depends_on:
      database:
        condition: service_healthy
    ports:
      - "${PORT:-3000}:${PORT:-3000}"
    environment:
      PORT: ${PORT:-3000}
      # Datenbank
      NEXT_PRIVATE_DATABASE_URL: ${NEXT_PRIVATE_DATABASE_URL}
      # Pflicht für die Migrationen beim Start (ohne PgBouncer identisch mit der URL oben)
      NEXT_PRIVATE_DIRECT_DATABASE_URL: ${NEXT_PRIVATE_DIRECT_DATABASE_URL:-${NEXT_PRIVATE_DATABASE_URL}}
      # Auth & Verschlüsselung
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
      NEXT_PRIVATE_ENCRYPTION_KEY: ${NEXT_PRIVATE_ENCRYPTION_KEY}
      NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY: ${NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY}
      # URLs
      NEXT_PUBLIC_WEBAPP_URL: ${NEXT_PUBLIC_WEBAPP_URL}
      NEXT_PRIVATE_INTERNAL_WEBAPP_URL: ${NEXT_PRIVATE_INTERNAL_WEBAPP_URL:-http://localhost:3000}
      # E-Mail
      NEXT_PRIVATE_SMTP_TRANSPORT: ${NEXT_PRIVATE_SMTP_TRANSPORT:-smtp-auth}
      NEXT_PRIVATE_SMTP_HOST: ${NEXT_PRIVATE_SMTP_HOST}
      NEXT_PRIVATE_SMTP_PORT: ${NEXT_PRIVATE_SMTP_PORT:-587}
      NEXT_PRIVATE_SMTP_USERNAME: ${NEXT_PRIVATE_SMTP_USERNAME}
      NEXT_PRIVATE_SMTP_PASSWORD: ${NEXT_PRIVATE_SMTP_PASSWORD}
      NEXT_PRIVATE_SMTP_FROM_ADDRESS: ${NEXT_PRIVATE_SMTP_FROM_ADDRESS}
      NEXT_PRIVATE_SMTP_FROM_NAME: ${NEXT_PRIVATE_SMTP_FROM_NAME:-Documenso}
      # Signaturzertifikat
      NEXT_PRIVATE_SIGNING_PASSPHRASE: ${NEXT_PRIVATE_SIGNING_PASSPHRASE}
      NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH: /opt/documenso/cert.p12
      # Telemetrie
      DOCUMENSO_DISABLE_TELEMETRY: "true"
    volumes:
      - /opt/documenso/cert.p12:/opt/documenso/cert.p12:ro

volumes:
  database:

Zwei Zeilen sind gegenüber älteren Vorlagen entscheidend: NEXT_PRIVATE_DIRECT_DATABASE_URL verlangt das Prisma-Schema für die Migrationen; fehlt sie, bricht die Migration beim Start ab und Documenso läuft danach in einer Neustartschleife mit „The table public.User does not exist“. Die offizielle Compose-Datei setzt sie deshalb standardmäßig auf NEXT_PRIVATE_DATABASE_URL. NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH teilt der Anwendung den Pfad des Zertifikats mit. Das Startskript findet die Datei zwar auch ohne diese Variable unter dem Standardpfad, die Signierfunktion selbst liest sie aber nur über die Variable; ohne sie meldet /api/certificate-status im Test "isAvailable":false.

Verifizieren: docker compose -f /opt/documenso/compose.yaml config: Compose analysiert die Datei und zeigt die aufgelöste Konfiguration ohne Fehler an. Fehlende Pflicht-Variablen werden direkt als Fehler gemeldet.

Schritt 5: Stack starten und Migrationen abwarten

Starten Sie den Stack aus dem Projektordner heraus:

cd /opt/documenso
docker compose up -d

Beim ersten Start führt Documenso automatisch alle Datenbankmigrationen aus, das kann zwei bis drei Minuten dauern. Beobachten Sie den Fortschritt live:

docker compose logs -f documenso

Sie warten auf die Zeile All migrations have been successfully applied., danach startet der Server und meldet unter anderem [JOBS]: Started cron poller. Ab dann ist die App bereit.

Verifizieren:

docker compose ps

Erwartete Ausgabe (beide Container müssen laufen):

NAME                   IMAGE                           STATUS
documenso-database-1   postgres:15                     Up X minutes (healthy)
documenso-documenso-1  documenso/documenso:v2.19.0     Up X minutes

Anschließend Health-Check-Endpunkt prüfen:

curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/api/health

Erwartete Antwort: 200. Der Endpunkt liefert seit den aktuellen Versionen zusätzlich ein JSON mit den Einzelprüfungen; "status":"ok" bedeutet, dass Datenbank und Zertifikat in Ordnung sind, "warning" deutet meist auf ein nicht geladenes Zertifikat hin. Den Zertifikat-Status prüfen Sie mit:

curl -s http://localhost:3000/api/certificate-status

Erwartete Antwort: {"isAvailable":true,...}.

Schritt 6: Reverse Proxy und HTTPS einrichten

Für den Produktivbetrieb ist HTTPS Pflicht: NEXT_PUBLIC_WEBAPP_URL muss die https://-URL enthalten, sonst funktionieren Token-Links in E-Mails und OAuth-Callbacks nicht. Richten Sie einen Reverse Proxy vor Documenso (Port 3000) ein. Empfohlen:

1. Traefik: Labels am Documenso-Service ergänzen, Traefik übernimmt Let's-Encrypt-Zertifikate automatisch. Anleitung: Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten.
2. Caddy: Eintrag in der Caddyfile: sign.example.com { reverse_proxy documenso:3000 }. Anleitung: Caddy als Reverse Proxy einrichten.
3. Nginx Proxy Manager: Proxy-Host für Port 3000 anlegen, SSL via Let's Encrypt aktivieren.

Wichtig: Setzen Sie in der .env nach dem DNS-Eintrag und dem Reverse-Proxy-Setup die korrekte öffentliche URL und die interne URL für Hintergrund-Jobs:

NEXT_PUBLIC_WEBAPP_URL=https://sign.example.com
NEXT_PRIVATE_INTERNAL_WEBAPP_URL=http://localhost:3000

Die interne URL muss auf localhost:3000 zeigen (nicht auf die öffentliche Domain), damit Hintergrund-Jobs den Reverse Proxy umgehen. Starten Sie den Stack nach der Änderung neu:

docker compose up -d --force-recreate documenso

Verifizieren: Rufen Sie https://sign.example.com im Browser auf; Sie sollten die Documenso-Startseite mit gültigem TLS-Zertifikat sehen. curl -I https://sign.example.com/api/health gibt HTTP 200 zurück.

Schritt 7: Erst-Einrichtung im Browser und Registrierung sperren

Öffnen Sie https://sign.example.com und erstellen Sie den ersten Admin-Account über das Registrierungsformular. Sichern Sie Passwort und E-Mail-Adresse sorgfältig, über diesen Account verwalten Sie später alle Teams und Einstellungen.

Nach dem ersten Login empfiehlt es sich, weitere Registrierungen zu sperren, wenn Sie Documenso nur für Ihr Team nutzen wollen. Ergänzen Sie in der .env:

NEXT_PUBLIC_DISABLE_SIGNUP=true

Alternativ schränken Sie die Registrierung auf bestimmte E-Mail-Domains ein:

NEXT_PRIVATE_ALLOWED_SIGNUP_DOMAINS=ihrunternehmen.de,partner.de

Container neu starten, damit die Änderung wirksam wird:

docker compose up -d --force-recreate documenso

Verifizieren: Melden Sie sich als Admin an und rufen Sie https://sign.example.com/api/certificate-status im Browser auf. Die Antwort zeigt, ob das Signaturzertifikat korrekt geladen ist. Laden Sie ein Test-PDF hoch, fügen Sie sich als Unterzeichner hinzu und prüfen Sie, ob die Einladungsmail eintrifft.

Schritt 8: Updates und Datenbank-Backup

Documenso erscheint regelmäßig mit neuen Versionen. Prüfen Sie vor jedem Update die Release-Notes auf Breaking Changes. Erstellen Sie immer zuerst ein Datenbank-Backup:

# Backup erstellen
docker compose exec database pg_dump -U documenso documenso > /opt/documenso/backup_$(date +%Y%m%d).sql

# Image-Tag in compose.yaml auf neue Version anpassen, dann:
docker compose pull
docker compose up -d

Hinweise für das Update von v2.11 auf v2.19: Die Release Notes der Versionen 2.12 bis 2.19 nennen keine Breaking Changes für Selbsthoster; die Datenbankmigrationen laufen beim Start automatisch (prisma migrate deploy). Im Test spielte der Wechsel von v2.11.0 auf v2.19.0 sieben zusätzliche Migrationen ein. Prüfen Sie vor dem Update Ihre compose.yaml auf die beiden Variablen aus Schritt 4: Ohne NEXT_PRIVATE_DIRECT_DATABASE_URL scheitern die Migrationen, ohne NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH meldet der Zertifikatsstatus im Test mit v2.19.0 „nicht verfügbar“. Seit v2.18 basiert das Image auf Node 24 LTS. Neu sind unter anderem AES/QES-Signaturen über externe Vertrauensdiensteanbieter per CSC (v2.13), ein Betrieb unter einem Unterpfad per NEXT_PUBLIC_BASE_PATH (v2.17), einzeln abschaltbare Anmeldewege und eine automatische OIDC-Weiterleitung (v2.15) sowie Massen-Download und Inbox-Filter. Ein Zurückspielen der älteren Version ist nach den Migrationen nicht vorgesehen; halten Sie daher den Dump bereit.

Datenbankmigrationen laufen automatisch beim Neustart. Überwachen Sie den Fortschritt mit docker compose logs -f documenso. Für eine strukturierte Backup-Strategie empfiehlt sich die Anleitung zu PostgreSQL pg_dump und pg_restore: Backup und Migration. Für automatische Update-Benachrichtigungen ohne blindes :latest-Pulling hilft die Anleitung zu Docker-Container automatisch aktualisieren.

Verifizieren: Nach dem Update docker compose ps: Beide Container müssen mit dem neuen Image-Tag und Status Up laufen. curl -s http://localhost:3000/api/health gibt weiterhin HTTP 200 zurück. Im Browser zeigt die neue Versionsnummer in den Einstellungen den Erfolg.

Troubleshooting / Typische Fehler

1. „Failed to get private key bags“: Das .p12-Zertifikat wurde ohne Passwort erstellt. Lösung: Zertifikat neu erstellen und dabei -passout pass:PASSWORT übergeben; NEXT_PRIVATE_SIGNING_PASSPHRASE in der .env setzen.
2. EACCES permission denied beim Signieren: Der Container läuft als UID 1001 (non-root), hat aber keinen Lesezugriff auf cert.p12. Lösung: sudo chown 1001:1001 /opt/documenso/cert.p12 && sudo chmod 400 /opt/documenso/cert.p12 auf dem Host ausführen.
3. Signatur läuft durch, erzeugt aber keine gültige Unterschrift: Kein Zertifikat konfiguriert, falsch gemountet oder NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH fehlt; Documenso startet problemlos auch ohne Zertifikat, und das Startskript meldet die Datei trotzdem als gefunden. Diagnose: /api/certificate-status aufrufen, erwartet ist "isAvailable":true.
4. Neustartschleife mit „The table public.User does not exist“: Im Log steht zuvor Environment variable not found: NEXT_PRIVATE_DIRECT_DATABASE_URL, die Migrationen sind nie gelaufen. Lösung: Variable wie in Schritt 4 ergänzen und den Container neu erstellen.
5. Datenbankverbindung schlägt fehl, „connection refused“: NEXT_PRIVATE_DATABASE_URL verwendet localhost statt dem Compose-Servicenamen. Lösung: URL-Hostname muss database lauten, also postgresql://documenso:PASS@database:5432/documenso.
6. Token-Links in E-Mails sind falsch oder OAuth-Callback schlägt fehl: NEXT_PUBLIC_WEBAPP_URL ist falsch gesetzt (z. B. http:// statt https:// oder fehlender Port). Lösung: URL exakt so setzen, wie sie im Browser erreichbar ist.
7. Erster Start hängt oder läuft in Timeout: Datenbankmigrationen beim Erststart benötigen Zeit. Lösung: depends_on mit condition: service_healthy in der Compose-Datei sicherstellen und docker compose logs -f documenso abwarten.
8. Hintergrund-Jobs (E-Mail-Versand) schlagen fehl: NEXT_PRIVATE_INTERNAL_WEBAPP_URL zeigt auf die öffentliche Domain statt auf http://localhost:3000. Lösung: Variable auf die interne Container-URL setzen.
9. Breaking Changes nach Update: Verwendung von :latest-Tag. Lösung: In der compose.yaml immer konkrete Versionstags wie :v2.19.0 einsetzen und vor jedem Update die Release-Notes lesen.

Häufige Fragen

Benötige ich zwingend ein SSL-Zertifikat für den Betrieb?

Ja, für den Produktivbetrieb ist HTTPS Pflicht. HTTP reicht ausschließlich für lokale Tests. NEXT_PUBLIC_WEBAPP_URL muss die https://-URL enthalten, sonst funktionieren Token-Links in E-Mails, OAuth-Callbacks und viele sicherheitsrelevante Browser-Features nicht korrekt. Am einfachsten übernimmt ein vorgelagerter Reverse Proxy (Traefik, Caddy, Nginx) die TLS-Terminierung mit Let's-Encrypt-Zertifikaten.

Wie erstelle ich ein Signaturzertifikat (.p12) für rechtssichere Signaturen?

Für interne Zwecke oder fortgeschrittene elektronische Signaturen reicht ein selbstsigniertes OpenSSL-Zertifikat wie in Schritt 2 beschrieben. Für qualifizierte elektronische Signaturen (QES) nach eIDAS (die höchste Rechtsstufe, gleichwertig mit handschriftlicher Unterschrift) benötigen Sie ein Zertifikat von einer akkreditierten Vertrauensstelle (z. B. D-Trust, Bundesdruckerei). Diese Zertifikate sind kostenpflichtig und erfordern eine Identitätsprüfung.

Werden Dokumente in der Datenbank oder im Dateisystem gespeichert?

Standardmäßig in PostgreSQL (NEXT_PUBLIC_UPLOAD_TRANSPORT=database). Das ist für KMU mit moderatem Dokumentenaufkommen praktisch, da kein zusätzlicher Speicher-Service benötigt wird. Bei großen Dokumentenmengen empfiehlt sich S3-kompatible Speicherung (AWS S3, MinIO, Cloudflare R2) über die entsprechenden S3-Umgebungsvariablen.

Kann ich die Benutzerregistrierung deaktivieren?

Ja: NEXT_PUBLIC_DISABLE_SIGNUP=true sperrt alle Neuregistrierungen vollständig. Mit NEXT_PRIVATE_ALLOWED_SIGNUP_DOMAINS=ihrunternehmen.de erlauben Sie nur Registrierungen von bestimmten E-Mail-Domains. Bestehende Benutzerkonten sind von beiden Einstellungen nicht betroffen.

Benötigt Documenso Redis?

Nein. Redis ist optional. Der Standard-Jobs-Provider local nutzt PostgreSQL für die interne Jobqueue, ohne externe Abhängigkeiten. Redis (BullMQ-Provider) oder Inngest empfehlen sich erst bei sehr hohem Durchsatz oder wenn Sie eine verwaltete Job-Infrastruktur bevorzugen.

Kann ich Nicht-PDF-Dokumente (DOCX, ODT) hochladen?

Ja, wenn Sie einen Gotenberg-Container als zusätzlichen Service in den Stack einbinden und NEXT_PRIVATE_DOCUMENT_CONVERSION_URL=http://gotenberg:3000 setzen. Gotenberg konvertiert DOCX, ODT und weitere Formate serverseitig zu PDF, bevor Documenso sie verarbeitet.

Fazit

Documenso ist eine ausgereifte, aktiv gepflegte Alternative zu DocuSign, die sich mit überschaubarem Aufwand auf eigener Infrastruktur betreiben lässt. Der größte konzeptionelle Unterschied zu SaaS-Angeboten: Sie tragen die Verantwortung für Betrieb, Backups und Updates selbst. Das zahlt sich aus, wenn DSGVO-Compliance ohne US-Datenverarbeitung für Sie oder Ihre Kunden nicht verhandelbar ist. Die Pflicht-Komplexität liegt vor allem beim Signaturzertifikat (PKCS#12 mit Passwort) und der korrekten URL-Konfiguration, zwei Punkte, bei denen erfahrungsgemäß die meisten Fehler entstehen. Wer diese Stolpersteine kennt, hat eine zuverlässige, rechtssichere Signaturlösung auf dem eigenen Server, die mit dem Team wächst.

Weiterführende Anleitungen und Quellen

1. Docker und Docker Compose auf Linux installieren: die Self-Hosting-Grundlage
2. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten
3. Caddy als Reverse Proxy einrichten: Anfänger-Anleitung mit automatischem HTTPS
4. Docker-Container automatisch aktualisieren: Diun, WUD und Renovate im Vergleich
5. Paperless-ngx mit Docker einrichten: papierlose Dokumentenverwaltung mit OCR
6. Stirling-PDF mit Docker: der lokale PDF-Werkzeugkasten
7. PostgreSQL pg_dump und pg_restore: Backup und Migration per Kommandozeile

Offizielle Quellen: Documenso Docs: Docker Compose Deployment · Environment Variables Reference · Tips und Common Pitfalls · GitHub Repository

Passende Anleitungen auf S-EDV

1. OpenSSL: Neun Schwachstellen im Sicherheitsrelease vom 9. Juni 2026, darunter Hi
2. PostgreSQL schließt elf Sicherheitslücken in den Versionen 14 bis 18
3. netcup Local Block Storage bestellen, einrichten und unter Linux einbinden