FADP-konforme Treuhand-Automation: Warum unser n8n auf Hetzner läuft — und wann das nicht reicht

Cloud-Automation-Plattformen sind bequem. Für ein Schweizer Treuhandbüro mit Mandantendaten sind sie häufig der schnellste Weg zu einem Compliance-Problem, das spätestens beim ersten Audit aufschlägt. Hier ist, warum wir unsere eigene n8n-Instanz auf einem Hetzner-Server fahren, was das real kostet, was bei Skalierung kaputtgeht — und wo die Architektur an ihre Grenze stösst.

Was sich seit September 2023 geändert hat

Am 1. September 2023 ist das revidierte Schweizer Datenschutzgesetz (revDSG, oft als FADP nach dem englischen "Federal Act on Data Protection" zitiert) in Kraft getreten. Für Treuhandbüros heisst das: Mandantendaten — Personalien, Lohndaten, Belege, Steuerunterlagen — gelten als Personendaten und unterliegen verschärften Pflichten zu Datenschutz, Auftragsbearbeitung und Datentransfer ins Ausland.

Der entscheidende Paragraph für jede Art von Cloud-Automation ist Art. 16 revDSG: Personendaten dürfen nur in Länder transferiert werden, die ein angemessenes Datenschutzniveau garantieren — oder es braucht zusätzliche vertragliche Garantien (Standardvertragsklauseln) und eine dokumentierte Risikobeurteilung. Die EU ist als angemessen eingestuft. Die USA sind es nicht. Andere Länder müssen einzeln geprüft werden.

Warum Cloud-Automation oft am ersten Mandanten scheitert

Die populären Automation-Plattformen sind technisch ausgereift, aber ihre Hosting-Realität ist kompliziert. Zapier läuft primär auf US-Servern (AWS US-East), Make hat Server-Optionen in der EU, aber die Default-Konfiguration variiert. Selbst n8n.cloud — die Cloud-Version unseres bevorzugten Tools — wird auf Google Cloud in den USA gehostet, sofern man nicht aktiv auf den europäischen Tarif wechselt.

Was das im Treuhand-Alltag bedeutet: Sobald ein Workflow eine Mandanten-PDF zur OCR-Verarbeitung an die Cloud-Plattform schickt, eine Lohnliste zwischen bexio und einem Mailprogramm überträgt, oder einen Beleg via Webhook in einen US-Storage schreibt, ist ein Auslandstransfer geschehen. Ohne dokumentierte Standardvertragsklauseln, ohne Risikobeurteilung, oft ohne dass die Treuhänderin überhaupt weiss, dass es passiert ist.

Im Audit kommt das nicht raus, weil keine Spuren hinterlassen werden. Beim Zwischenfall — Datenleck, Mandanten-Beschwerde, Behördenfrage — ist die Kanzlei auf der falschen Seite des Beweises.

Hetzner + n8n: was der Stack tatsächlich leistet

Unser Setup besteht aus drei Schichten:

Auf der untersten Ebene ein Hetzner-Server, ein deutscher Cloud-Anbieter mit Rechenzentren in Falkenstein und Nürnberg (Deutschland) sowie Helsinki (Finnland). Alle drei Standorte liegen in der EU und sind nach revDSG datenschutzrechtlich angemessen. Hetzner stellt einen Auftragsbearbeitungsvertrag (DPA) zur Verfügung, der die für Treuhand erforderlichen Klauseln abdeckt.

Darauf läuft eine n8n-Instanz im Self-Hosted-Modus, in einem Docker-Container, mit PostgreSQL als Datenbank und einem Reverse-Proxy (Caddy) für TLS. Die n8n-Software ist Open Source, der Code-Stand auditbar, und wir kontrollieren Updates statt sie zu erleiden.

Die dritte Schicht ist eine pro-Mandanten-Trennung der Daten: jeder Workflow hat eigene Credentials, eigene Encryption-Keys, getrennte Output-Folders. Falls ein Mandant aussteigt, lassen sich seine Daten innerhalb eines Werktags vollständig löschen — was unter revDSG ein konkretes Recht des Mandanten ist.

Der Effekt für die Treuhand-Kanzlei: Mandantendaten verlassen den eigenen Verarbeitungs-Perimeter zu keinem Zeitpunkt. Externe APIs wie bexio oder Abacus sind separate, dokumentierte Verbindungen — keine versteckten Cloud-Ketten.

Was das real kostet

Der häufigste Einwand gegen Self-Hosting ist die Kosten-Annahme: "Cloud ist billiger." Stimmt nicht, sobald man ehrlich rechnet.

Die Faustregel: Bei drei oder mehr produktiven Workflows ist Self-Hosting günstiger. Bei einem einzelnen Workflow zum Ausprobieren ist die Cloud bequemer. Aber für Treuhand fällt diese Wahl ohnehin nicht über den Preis — sondern über den Datenstandort.

Was bei Skalierung kaputtgeht

Self-Hosting hat operative Realität, die in keiner Marketing-Broschüre steht. Hier ist, was wir bei Swiss Shift in den letzten Monaten konkret beobachtet haben:

1. PostgreSQL bläht sich auf

n8n speichert standardmässig jede Workflow-Execution mit allem dazugehörigen JSON-Payload in der Datenbank. Bei einem aktiven Belegverarbeitungs-Workflow mit 200 Belegen pro Monat sind das nach sechs Monaten gut 800 MB Postgres-Daten — bei einem 80-GB-SSD ein Nicht-Problem, aber bei drei aktiven Mandanten parallel wachsen die Backups schnell. Lösung: execution_data nach 14 Tagen automatisch purgen, separater Audit-Log für was länger aufbewahrt werden muss.

2. RAM-Druck bei parallelen Executions

Mit 8 GB RAM auf dem CX22 fährt eine Standard-n8n-Instanz problemlos 5–10 aktive Workflows. Bei sechs gleichzeitigen Executions — etwa wenn morgens alle Belege aus der Nacht parallel verarbeitet werden — landet RAM bei 80 % und der Worker bekommt Kontext-Switches. Lösung: Queue-Mode aktivieren (n8n unterstützt Redis-basierte Queue), Workflows zeitlich entzerren, oder bei stetigem Wachstum auf CX42 (16 GB RAM) hochziehen — Aufwand: 5 Minuten, Mehrkosten ca. CHF 8 / Monat.

3. Webhook-Domain-DNS

n8n-Webhooks brauchen eine öffentliche, TLS-gesicherte URL. Wenn die DNS-Records für die Sub-Domain falsch gesetzt sind, fallen Webhook-getriebene Workflows aus, ohne dass es im UI sichtbar ist — der Eintreffer-Service (z.B. bexio) bekommt einen Verbindungsfehler, und der Treuhand sieht das erst, wenn der Beleg fehlt. Lösung: synthetisches Monitoring auf den Webhook (alle 5 Minuten ein Heartbeat-Test), das auf E-Mail alarmiert.

4. Kein Auto-Scaling

Bei Cloud-Plattformen kommt automatische Skalierung "gratis" — wenn die Last steigt, wird mehr Kapazität bereitgestellt. Beim Self-Hosting muss man das selbst tun. In der Praxis ist das selten ein Problem, weil Treuhand-Workloads sehr vorhersagbar sind (Monatsende-Spitzen, sonst Grundrauschen). Aber es heisst, dass man bei einem unerwarteten Volumen-Sprung — etwa wenn ein Mandant 10x mehr Belege schickt als üblich — manuell reagieren muss.

Wann Hetzner nicht reicht

Es gibt drei Konstellationen, in denen Hetzner-DE nicht ausreichend ist:

Erstens, wenn ein Mandant explizit Hosting in der Schweiz verlangt. Banken, Versicherungen, einzelne Healthcare-Mandate, gewisse Bundesbehörden-Aufträge. Dann ist Hetzner-DE rechtlich angemessen, aber vertraglich oft ausgeschlossen. Alternative: Infomaniak in Genf oder Lausanne, mit den gleichen n8n-Komponenten — Kosten leicht höher (ca. CHF 12–18 / Monat für vergleichbare Spec), Performance vergleichbar.

Zweitens, wenn das Treuhand-Büro selbst eine Hosting-Pflicht hat (etwa als Treuhand-Suisse-Mitglied mit erhöhten Anforderungen). Auch hier: Infomaniak oder Cyon. Hetzner-DE wäre formal okay, aber bei Audits unnötiger Erklärungsaufwand.

Drittens, wenn ein einzelner Workflow EU-personenbezogene Daten verarbeitet, die strengeren Branchen-Regeln unterliegen (etwa GDPR-relevante Healthcare-Daten eines deutschen Mandanten, der seinerseits HIPAA-Auflagen hat). Dann braucht es eine eigene Risikobeurteilung pro Workflow — die Architektur bleibt gleich, aber die dokumentierte Begründung wird umfangreicher.

In allen anderen Fällen — also der weit überwiegenden Mehrheit der Schweizer KMU-Treuhand-Mandate — ist Hetzner-DE mit DPA und sauberer Konfiguration der pragmatischste Weg.

Wer das hier schreibt

Wir bei Swiss Shift fahren genau dieses Setup für unsere eigene Akquise und Content-Pipeline: ein Hetzner-Server, n8n self-hosted, PostgreSQL, Caddy, automatische Backups in einer separaten Storage Box. Die ganze Akquise — vom Scraping der TreuhandSuisse-Mitgliederliste bis zur strukturierten Cold-Mail-Pipeline — läuft auf demselben Stack, den wir für Treuhand-Mandate aufsetzen würden. Das ist kein Marketing-Argument. Es ist Disziplin: wenn etwas im Audit hält, muss es auch im Eigenbetrieb halten.

Sie wollen mit uns reden über Treuhand-Workflows, die diesen Anspruch erfüllen? Der 90-Minuten Quick-Audit ist unser strukturierter Einstieg — keine Verpflichtung, aber drei konkret bewertete Automatisierungs-Kandidaten am Ende.