Rechtssicher signieren — mandantenfähig, in der eigenen Cloud.

Überblick

Die Plattform ist ein Software-as-a-Service für elektronische Signaturen: Jede Organisation ist ein eigener Mandant mit strikt getrennten Daten. Nutzer laden ein PDF hoch, legen einen Vorgang mit einem oder mehreren Beteiligten an, platzieren die sichtbaren Signaturfelder und versenden Einladungen. Unterzeichner öffnen einen sicheren Einmal-Link, zeichnen im Browser (auch am Handy, mit Finger oder Stift) und die Plattform erzeugt die PAdES-Signatur.

• Fünf Signaturarten — vom serverseitigen Selbstsignieren bis zur qualifizierten QES.
• Workflow — sequenziell oder parallel, mit Freigeber-Rollen (genehmigen/ablehnen).
• Sichtbare Signaturen — beliebig platzierbar, mehrere Felder je Person, biometrische Erfassung (X/Y/Druck/Zeit).
• Mandantenfähig — Organisationen, Rollen, eigene Signaturzertifikate und Identitätsanbindung je Org.
• Nachvollziehbar — lückenloser Audit-Trail, Prüfbericht je signiertem Dokument.

Rollen & Zugang

Wer was sieht und darf, hängt an der Rolle. Externe Unterzeichner brauchen keinen Account.

Die Oberfläche

Das Portal hat fünf Ansichten. Auf jeder Seite erklärt der ?-Button oben (neben der Sprachauswahl) die Abschnitte der aktuellen Ansicht kontextbezogen.

Dashboard

• Vorgang anlegen — Titel, PDF hochladen, Ablauf (sequenziell/parallel), optionale Nachricht.
• Teilnehmer — E-Mail, Signaturart/-umgebung, Rolle und optional die E-Mail-Sprache je Person; über 📍 die sichtbaren Felder im PDF platzieren.
• Vorgangsliste — laufende Vorgänge mit Status, Klick öffnet die Detailseite.

Vorgangs-Details

• Fortschritt — Statusbalken und wie viele Beteiligte schon signiert/freigegeben haben.
• Dokumente — signiertes PDF ansehen, prüfen (🔎 erzeugt einen Prüfbericht), herunterladen oder per E-Mail senden.
• Teilnehmer — wer signiert, in welcher Reihenfolge, mit Status.
• Senden — erzeugt und verschickt die Magic-Links.
• Audit-Trail — lückenloses Protokoll (standardmäßig eingeklappt).

Administration & Plattform-Konsole

Diese beiden Ansichten haben eigene Abschnitte — siehe Administration und Plattform-Konsole.

Unterzeichnen

Die Seite, die ein Empfänger per Einladungslink öffnet — siehe Unterzeichnen.

Signaturarten

Jeder Teilnehmer bekommt eine Signaturart zugewiesen. Verfügbar sind im Dropdown nur die vom Admin eingerichteten Signaturumgebungen. Alle Verfahren erzeugen PAdES über die eigene PDF-Bibliothek miPDFlib — mit einer Ausnahme: Bei der A-Trust Signaturbox signiert A-Trust das ganze PDF auf der eigenen Plattform (miPDFsign Cloud ergänzt danach nur die Langzeit-Validierungsdaten).

Vorgang anlegen

1. PDF hochladen und dem Vorgang einen Titel geben.
2. Ablauf wählen — Sequenziell (nacheinander, Reihenfolge erzwungen) oder Parallel (alle gleichzeitig).
3. Teilnehmer hinzufügen — E-Mail, Signaturart/-umgebung und Rolle (Unterzeichner, Freigeber, Betrachter).
4. Signaturfelder platzieren — über 📍 pro Person ein oder mehrere Felder im PDF setzen (Seite, Position, Größe). Ohne Platzierung wird unsichtbar signiert.
5. Optional: Sprache & Nachricht — E-Mail-Sprache je Empfänger, freie Nachricht an alle.
6. Anlegen & Einladungen senden — legt den Vorgang an und verschickt die Einladungen in einem Schritt (sequenziell: zunächst nur an den Ersten); „Als Entwurf speichern" hält ihn zurück.

Unterzeichnen

Der Empfänger öffnet den Einladungslink — kein Konto nötig. Die Seite funktioniert am Desktop wie am Handy-Browser.

• Dokument — das PDF durchscrollen; die eigenen Signaturfelder sind markiert.
• Signieren — Feld antippen, mit Finger oder Stift zeichnen, „Fertig". Bei mehreren Feldern führt „Zur nächsten Signatur" zum nächsten offenen Feld.
• Biometrie — bei den serverseitig erzeugten Signaturen werden X/Y/Druck/Zeit erfasst, verschlüsselt und als CMS-Attribut eingebettet.
• A-Trust Signaturbox — statt zu zeichnen füllst du gegebenenfalls die Formularfelder aus und klickst „Bei A-Trust signieren“. Du wirst auf die Signaturseite von A-Trust weitergeleitet, signierst dort qualifiziert mit ID Austria / Handy-Signatur und kommst danach automatisch zurück. Die Signatur bei A-Trust muss innerhalb von 15 Minuten abgeschlossen werden; bei Abbruch oder Ablauf einfach erneut starten. Hast du mehrere Dokumente zu signieren, signierst du mit „Alle N Dokumente bei A-Trust signieren“ alle offenen Dokumente in einem Durchgang (bis zu 10) und bestätigst bei A-Trust nur einmal — jedes Dokument erhält trotzdem seine eigene Signatur. Fülle vorher die Felder in allen Dokumenten aus; sind noch Felder leer, fragt miPDFsign nach. Mit „Nur dieses Dokument signieren“ signierst du wie bisher einzeln.
• A-Trust Short Term Certificate (EUDI-Wallet) (im A-Trust-Testsystem verifiziert, noch nicht produktiv) — zuerst „Mit EUDI-Wallet ausweisen“: den QR-Code mit deiner EUDI-Wallet scannen (am Handy direkt „Wallet auf diesem Gerät öffnen“) und die angefragten Daten (Name, Geburtsdatum) freigeben. Die Seite zeigt danach „Ausgewiesen: Name, geb. …“. Dann „Zertifikat ausstellen und signieren“: Du wirst zu A-Trust weitergeleitet, bestätigst dort zuerst die Ausstellung deines einmaligen Zertifikats und anschließend die Signatur und kommst danach automatisch zurück. Die Identifikation gilt 15 Minuten — in dieser Zeit kannst du mehrere Dokumente des Vorgangs signieren, ohne dich erneut auszuweisen.
• Freigeben/Ablehnen — Freigeber genehmigen oder lehnen mit Begründung ab; Ablehnung beendet den Vorgang.

Zugangscode (zweiter Faktor)

Beim Anlegen eines Vorgangs lässt sich je Empfänger ein optionaler Zugangscode vergeben (🎲 erzeugt einen 6-stelligen Code, 📋 kopiert ihn — z. B. für WhatsApp). Der Unterzeichner muss den Code eingeben, bevor er das Dokument sieht. Den Code über einen anderen Kanal mitteilen (Anruf, Nachricht, persönlich) — die Trennung der Kanäle ist der Beweiswert. Nach 10 Fehlversuchen sperrt der Link (Erholung: Link neu ausstellen); Eingabe und Sperre stehen im Audit-Trail.

Konto-Sicherheit: 2FA, Face ID & Push

Zwei-Faktor-Authentifizierung (2FA)

Jeder Benutzer mit Passwort-Login kann auf der 🔒 Sicherheit-Seite (Navigationsleiste) TOTP-2FA aktivieren: QR-Code mit einer Authenticator-App scannen, ersten Code bestätigen und die 8 einmaligen Wiederherstellungscodes sicher verwahren. Ab dann fragt der Login nach dem Passwort zusätzlich einen 6-stelligen Code ab. SSO/LDAP/Google-Konten bringen die MFA ihres Identity-Providers mit.

Biometrische Anmeldung (Face ID / Fingerabdruck)

Ist 2FA aktiv, kannst du unter „Biometrische Anmeldung (Face ID / Fingerabdruck)“ zusätzlich bis zu 10 Geräte registrieren — mit Face ID, Touch ID, Android-Fingerabdruck/Gesichtsentsperrung oder Windows Hello. Beim Login erscheint nach dem Passwort dann „Mit Face ID / Fingerabdruck bestätigen“, statt den Code abzutippen. Das Codefeld (Authenticator- oder Wiederherstellungscode) bleibt immer als Rückfallebene verfügbar.

• Voraussetzung — TOTP-2FA muss aktiv sein (Notfallzugang bei Geräteverlust). Wird 2FA deaktiviert, werden auch alle biometrischen Geräte gelöscht.
• Technik — W3C-WebAuthn mit dem im Gerät eingebauten Authenticator, Benutzerverifikation Pflicht.
• Nicht für SSO-/LDAP-/Google-Konten — wie TOTP.

Push-Benachrichtigungen

Unter Sicherheit → „Push-Benachrichtigungen“ schaltet „Auf diesem Gerät aktivieren“ Benachrichtigungen für das aktuelle Gerät ein (der Browser fragt nach der Erlaubnis); „Testbenachrichtigung senden“ prüft die Zustellung. Bis zu 10 Geräte pro Konto.

• Auslöser — immer dann, wenn du als Unterzeichner auch eine E-Mail bekommst: Einladung (wenn du an der Reihe bist), „Du bist dran“, Erinnerung, „Frist läuft ab“. Ein Tipp öffnet direkt die Signaturseite; neuere Meldungen zum selben Vorgang ersetzen ältere. Angezeigt werden Vorgangstitel und Absender — nie der Link.
• Empfänger — Portal-Benutzer der versendenden Organisation (interne Teilnehmer bzw. Konten dieser Organisation mit der Teilnehmer-E-Mail). Externe ohne Konto dort erhalten wie bisher nur die E-Mail.
• Browser — Chrome, Edge, Firefox auf Desktop und Android.
• Abmelden trennt das Gerät von den Push-Meldungen; beim nächsten Login wird es automatisch wieder verbunden, solange die Browser-Erlaubnis besteht.

Organisieren: Kontakte, Ordner & Tags

Kontakte (Adressbuch)

Jeder Empfänger, an den ein Vorgang versendet wird, landet automatisch unter Kontakte (Navigationsleiste) — sortiert nach „zuletzt verwendet". Name, Firma und bevorzugte E-Mail-Sprache lassen sich pflegen; CSV-Import/-Export (email,name,firma,sprache, Komma oder Semikolon, max. 5000 Zeilen) inklusive. Beim Anlegen eines Vorgangs werden Kontakte im Empfängerfeld automatisch vorgeschlagen.

Ordner & Tags

Jeder Vorgang lässt sich in einen Ordner (flaches Label) einsortieren und mit Tags versehen — auf der Vorgangsseite unter Ablage oder direkt beim Anlegen über die API. Ordner und Tags erscheinen neben dem Titel in der Vorgangsliste; darüber filtern Suche (Titel oder Empfänger-E-Mail), Ordner- und Tag-Dropdown die Liste (die Dropdowns erscheinen, sobald es Ordner bzw. Tags gibt).

Aufbewahrung (DSGVO)

Unter Administration → Aufbewahrung legt der Admin fest, wie viele Tage abgeschlossene Vorgänge aufbewahrt werden (7–3650; leer = unbegrenzt). Nach Ablauf löscht der tägliche Sweep den Vorgang endgültig — inklusive signierter PDFs und Audit-Trail; das ursprünglich hochgeladene Dokument bleibt erhalten.

Administration

Die Einstellungen der eigenen Organisation. Alle Abschnitte sind ein-/ausklappbar; ungenutzte starten eingeklappt.

Benutzer

Benutzer anlegen, Rolle (Mitglied/Org-Admin) ändern, deaktivieren. Bei lokalen Konten lässt sich das Passwort zurücksetzen (🔑) — bei SSO/LDAP-Konten nicht, da diese am Identitätsanbieter authentifizieren.

Signaturumgebungen

Eine Signaturumgebung ist eine benannte, gespeicherte Konfiguration für genau eine Signaturart (Zertifikate und Zugangsdaten, verschlüsselt). Der zentrale Punkt: Eine Methode erscheint im Teilnehmer-Dropdown erst, wenn du dafür eine Umgebung angelegt hast. Du kannst mehrere anlegen — z.B. zwei Organisationszertifikate — und unterscheidest sie über den Namen.

A-Trust Signaturbox: sichtbare Signatur mit Vorlage

So bekommt eine qualifizierte Signatur über die Signaturbox ein sichtbares Signaturbild mit deinem Logo:

1. Umgebung anlegen — Administration → Signaturumgebungen → hinzufügen, Methode A-Trust Signaturbox, API-Key und Signatur-Server-URL eintragen (oder „Testumgebung verwenden“) und speichern. Erst die gespeicherte Umgebung zeigt den Abschnitt „Vorlagen für die sichtbare Signatur“.
2. Vorlage gestalten — Unter „Neue Vorlage anlegen“ → Gestalten einen Namen vergeben, die Überschrift anpassen (z.B. „Qualifiziert elektronisch signiert“), optional ein Logo wählen (PNG oder JPEG, max. 512 KB) und festlegen, ob Ort und Grund gedruckt werden. Mit „Name aus der Einladung anzeigen“ kommt eine zusätzliche Zeile dazu (Standard „Teilnehmer: {name}“, frei änderbar) — {name} wird bei jeder Signatur durch den Namen des Teilnehmers aus der Einladung ersetzt (Name aus Adressbuch bzw. Benutzerkonto, sonst die E-Mail-Adresse). Die Vorschau zeigt das ungefähre Aussehen; Unterzeichner und Zeitpunkt setzt A-Trust beim Signieren ein.
3. Oder hochladen — Wer schon eine fertige A-Trust-Vorlage hat, wählt „XML hochladen“ (max. 2 MB). A-Trust prüft das Format beim Hochladen; eine Positionsangabe in Prozent rechnet miPDFsign dabei in Punkte um. Steht in einem Textfeld {name}, wird es wie oben durch den Namen aus der Einladung ersetzt.
4. Anlegen und verwenden — „Vorlage anlegen und verwenden“ speichert die Vorlage auf deiner Signaturbox und wählt sie sofort aus. In der Liste kannst du jederzeit eine andere Vorlage oder „Keine Vorlage“ (unsichtbare Signatur) wählen und nicht mehr benötigte Vorlagen löschen.
5. Im Vorgang platzieren — Beim Anlegen des Vorgangs das Signaturfeld des Unterzeichners dort platzieren, wo der Stempel erscheinen soll — A-Trust setzt die Vorlage genau in dieses Feld (Seitenverhältnis der Vorlage etwa 8 : 3, z.B. 220 × 82 pt).

Single Sign-on mit OIDC — „Mitarbeiter mit dem Firmenkonto anmelden lassen“

Noch nie damit zu tun gehabt? SSO bedeutet, dass sich dein Team mit dem bereits vorhandenen Konto anmeldet — Microsoft 365, Google Workspace, Okta, Keycloak — statt mit einem eigenen miPDFsign-Passwort. Im Hintergrund spricht miPDFsign mit diesem System (dem Identitätsanbieter, kurz IdP) über das Standardprotokoll OpenID Connect. Einmal pro Organisation einrichten: miPDFsign als „Anwendung“ im IdP registrieren, ein paar Werte übernehmen und dem IdP eine Rücksprung-Adresse nennen.

1. Was du vom IdP (bzw. der IT-/Identity-Abteilung) brauchst:

2. Der eine Wert, den du dem IdP gibst — die Redirect-URI (Callback / Reply-URL). Exakt angeben (echte Domain, https, kein Schrägstrich am Ende):

https://DEINE-DOMAIN/api/auth/oidc/callback

3. App registrieren (Beispiel: Microsoft Entra ID / Azure AD):

1. Entra Admin Center → App-Registrierungen → Neue Registrierung.
2. Redirect-URI: Plattform Web, Wert = obige Callback-URL.
3. Anwendungs-(Client-)ID kopieren → deine Client-ID.
4. Zertifikate & Geheimnisse → Neues Clientgeheimnis → den Wert sofort kopieren → dein Client-Secret.
5. Tokenkonfiguration → Gruppenanspruch hinzufügen; Name/Objekt-ID der Admin-Gruppe notieren.
6. Authority = https://login.microsoftonline.com/<tenant-id>/v2.0.

Okta, Google und Keycloak folgen demselben Muster.

4. In miPDFsign eintragen (Administration → Single Sign-on): Aktiviert einschalten; Authority, Client-ID, Client-Secret einfügen; Scopes = openid profile email belassen; Groups-Claim = groups belassen; Admin-Gruppe setzen; Speichern.

5. Wie sich dein Team anmeldet: Mit SSO anmelden für deine Organisation wählen. Der erste Login legt das Konto automatisch an (Just-in-time) — kein lokales Passwort. Die Rolle wird bei jedem Login aus dem Groups-Claim gesetzt.

LDAP / Active Directory — „Mitarbeiter mit dem Windows-/AD-Konto anmelden lassen“

Noch nie damit zu tun gehabt? Betreibt deine Organisation ein lokales Verzeichnis — Microsoft Active Directory oder einen anderen LDAP-Server — kann miPDFsign Benutzernamen und Passwörter direkt dagegen prüfen. Sinnvoll ohne Cloud-IdP. In einem Satz: miPDFsign verbindet sich mit einem schreibgeschützten Dienstkonto, sucht die Person anhand des eingegebenen Benutzernamens und meldet sich dann als diese Person mit ihrem Passwort an; klappt das, ist sie drin.

Was du von der IT-/Verzeichnis-Abteilung brauchst:

Konfigurieren (Administration → LDAP / Active Directory): Aktiviert; Host + Port; LDAPS oder StartTLS ankreuzen; Basis-DN; Bind-DN + Passwort; Nutzer-Filter belassen ((sAMAccountName={0}) für AD); Attribut-Standards belassen; Admin-Gruppe setzen; Speichern.

Vor dem Ausrollen testen: „Verzeichnis-Login testen“ mit Benutzername und Passwort eines echten Nutzers führt die komplette Suche-dann-Anmeldung aus und zeigt E-Mail, Name und ob der Nutzer Admin wäre — ohne ein Konto anzulegen. Konfiguration anpassen, bis der Test grün ist.

Wie sich dein Team anmeldet: Verzeichnis-Nutzer geben Benutzername, Passwort und die Organisation (deren Slug) ein — nötig, weil Benutzernamen über Mandanten nicht eindeutig sind. Der erste Login legt das Konto an (Just-in-time); die Rolle wird jedes Mal aus dem Gruppen-Attribut abgeleitet.

Biometrie-Zertifikat

Erfasste biometrische Signaturdaten (X/Y/Druck/Zeit) werden hybrid mit einem öffentlichen Zertifikat verschlüsselt; nur wer den passenden privaten Schlüssel hat, kann sie später entschlüsseln — genau das ermöglicht die Analyse durch einen Schriftsachverständigen im Beweisverfahren. Du musst dafür nichts einrichten:

• Standardmäßig automatisch erzeugt — legst du kein eigenes an, erstellt miPDFsign Cloud automatisch ein Schlüsselpaar (CN {Orgname}_miPDFsign_cloud_biometrics). Biometrie funktioniert ab dem ersten Tag.
• Privaten Schlüssel herunterladen — beim erzeugten Zertifikat lädst du den privaten Schlüssel herunter und verwahrst ihn sicher offline; du brauchst ihn, um Biometriedaten später zu lesen. Optional vergibst du ein Passwort, das die Datei schützt (verschlüsseltes PKCS#8).
• Eigenes verwenden — lade dein eigenes Zertifikat hoch. Das ersetzt das erzeugte und löscht den privaten Schlüssel vom Server — ab dann hast nur du ihn.
• Neu erzeugen — ein frisches Schlüsselpaar anlegen; bereits mit dem alten Zertifikat verschlüsselte Daten brauchen dann den alten privaten Schlüssel.

Branding (Enterprise)

Unter Administration → Branding hinterlegen Enterprise-Organisationen (und Testphasen, zum Ausprobieren) Anzeigename, Akzentfarbe und Logo (PNG/JPEG bis 512 KB): Externe Unterzeichner sehen sie auf der Signierseite, der Anzeigename erscheint zusätzlich in den E-Mails zum Vorgang. Standard-Tarife behalten gespeicherte Werte, gerendert oder editierbar sind sie dort nicht.

Zeitstempel · Plugins · Audit-Trail

• Zeitstempel (TSA) — optionaler eigener RFC-3161-Dienst, den alle Signaturen nutzen. Ohne Eintrag wird der qualifizierte Zeitstempeldienst des belgischen Föderalen Öffentlichen Dienstes BOSA verwendet, ersatzweise jener der spanischen ACCV — beide in der EU-Vertrauensliste geführt. Nur ein Zeitstempel mit Anker in einer EU-Liste beweist einem Prüfdienst, wann signiert wurde; ohne ihn gilt eine Signatur als unbestimmt, sobald ihr Zertifikat abgelaufen ist. Ein eigener Dienst kann eine HTTP-Basic-Anmeldung verlangen (verschlüsselt gespeichert).
• Plugins — ausgehende Zustellung bei Abschluss: Webhook (PDF-Binary oder JSON-Ereignis), Microsoft Teams (Adaptive Card in einen Kanal — Workflows-/Incoming-Webhook-URL genügt) und SharePoint (Upload in eine Dokumentbibliothek per Microsoft Graph mit eigener Entra-App, Sites.ReadWrite.All). Details & Rezepte: API-Referenz → Teams & SharePoint.
• Audit-Trail — org-weites Ereignisprotokoll.

Plattform-Konsole

Die mandantenübergreifende Betreiber-Konsole (/platform, nur für Plattform-Admins). Alles in einer Hand — kein separates Tooling nötig. Vier Registerkarten:

Anmeldung & API

Zwei Wege, nach der Anmeldeform automatisch erkannt:

• JWT (Portal) — POST /api/auth/login mit E-Mail/Benutzername + Passwort und optional dem Organisations-Slug (nötig für Verzeichnis-Login). Lokale Passwörter sind PBKDF2-HMAC-SHA256.
• API-Key (Maschine) — der mpk_…-Schlüssel aus der Registrierung, gesendet als X-Api-Key oder Authorization: Bearer mpk_…. Schlüssel werden nur gehasht gespeichert.

Die vollständige OpenAPI-Referenz für Integratoren liegt unter /api/docs (JSON unter /api/openapi/v1.json) mit beiden Sicherheits-Schemata.

# Trial anlegen → liefert einen API-Key
curl -X POST https://DEINE-DOMAIN/api/trial/signup \
  -H "Content-Type: application/json" \
  -d '{"organizationName":"Acme","adminEmail":"a@acme.com","password":"…"}'

# Dokument hochladen (mit API-Key)
curl -X POST https://DEINE-DOMAIN/api/documents \
  -H "X-Api-Key: mpk_…" -F "file=@vertrag.pdf;type=application/pdf"

API-Referenz & Integrationen: Die öffentliche API-Referenz dokumentiert die Integrations-Fläche inklusive Schritt-für-Schritt-Rezepten für Zapier & Make (Webhook-Trigger + HTTP-Aktionen).

Sicherheit & Datenschutz

• Mandantentrennung — jede Datenzeile trägt eine Org-ID; EF-Core-Query-Filter erzwingen die Isolation datenbankseitig (kein mandantenübergreifender Lesezugriff by design).
• Magic-Links — 256-bit-CSPRNG-Token; gespeichert wird nur der SHA-256-Hash. Ein Link ist nicht aus dem Hash rekonstruierbar.
• Secrets verschlüsselt — Zertifikatspasswörter, Client-Secrets und Biometriedaten liegen Data-Protection-verschlüsselt; der Schlüsselring liegt persistent in Redis (überlebt Neustarts).
• Zwei-Faktor-Authentifizierung — jedes Passwort-Konto kann auf der 🔒 Sicherheit-Seite TOTP-2FA aktivieren (QR-Enrolment, 8 einmalige Wiederherstellungscodes). Der Login verlangt dann nach dem Passwort einen 6-stelligen Code — optional per Face ID / Fingerabdruck bestätigt (WebAuthn; nur der öffentliche Schlüssel wird gespeichert, die Biometrie bleibt auf dem Gerät); SSO/LDAP/Google-Konten bringen die MFA ihres Identity-Providers mit (siehe Konto-Sicherheit).
• Push-Benachrichtigungen — Web Push (RFC 8030/8291/8292, VAPID), Inhalt Ende-zu-Ende verschlüsselt; nur bekannte Push-Dienste als Ziel erlaubt; Empfänger nur Konten der versendenden Organisation.
• Rate-Limiting — Login und Trial-Registrierung sind pro IP begrenzt (429 mit Retry-After).
• Härtung — nur der Reverse-Proxy ist von außen erreichbar; HSTS + Security-Header; E-Mail mit SPF/DKIM/DMARC (p=quarantine).

Deployment

Drei Wege — vom lokalen Start bis zum Anbieter-Deployment. Zustand liegt extern in PostgreSQL / Redis / S3-kompatiblem Objektspeicher; die API- und Worker-Tiers sind zustandslos.

Lokal (Entwicklung)

docker compose up -d --build
# API :8090 · Web :3100 · MinIO :9001 · Mailpit :8025 · Jaeger :16686

Portabel (eigener Server / VPS)

Ein selbstständiger Stack, der die Images aus der Registry zieht und einen eigenen Caddy mit automatischem Let's-Encrypt-Zertifikat mitbringt — env-gesteuert über die Domain:

docker compose --env-file .env.production \
  -f docker-compose.deploy.yml pull
docker compose --env-file .env.production \
  -f docker-compose.deploy.yml up -d

Das Web-Image ruft dieselbe Origin auf, von der es ausgeliefert wird — ein Image passt für jede Domain, Staging und Prod unterscheiden sich nur in der Env-Datei.

Kubernetes

Ein Helm-Chart (deploy/helm/mipdfsign) mit Deployments für API/Worker/Web, Services, Ingress und HPA (horizontale Autoskalierung). PostgreSQL/Redis/S3 als externe Dienste.