Eigene Analytics-Daten besitzen: Self-Hosted vs. private EU-SaaS in 2026

Selbst gehostete Webanalyse ist 2026 ein Neustart, keine Nische

Den Großteil des letzten Jahrzehnts war „selbst gehostete Webanalyse” eine ideologische Position – ein Plausible- oder Matomo-Flaggen-Setzen gegen den GA4-Standard. 2026 ist es etwas anderes: Das Data Act der Europäischen Kommission (anwendbar seit dem 12. September 2025) verbietet ausdrücklich SaaS-Vendor-Lock-in über proprietäre Speicherformate, und es gibt einen öffentlichen, zitierfähigen SaaS-Exodus europäischer Unternehmen, die Workloads aus US-kontrollierten Cloud-Plattformen zurückholen – „deutsche Mittelstandshersteller, französische Behörden, niederländische Gesundheitsdienstleister”, in MassiveGRIDs Rahmung. Branchenbeobachter beschreiben Datenhoheit nun als „pragmatische Reaktion auf regulatorischen Druck, politische Realität und die wachsende Erkenntnis, dass Datenhoheit nicht optional ist.”

Statnive Live kommt in zwei Formen: ein selbst gehostetes Go-Binary, das Sie selbst betreiben, und eine private EU-SaaS in Nürnberg. Dieser Beitrag ist die ehrliche Version der Frage, die jeder datenschutzbewusste Betreiber jetzt beantworten muss: welche passt eigentlich zu mir? Wo dieser Beitrag eine regulatorische oder Produktaussage macht, finden Sie eine Quellenangabe – und wo der Trade-off real ist, wird er benannt.

Das ist Artikel 3 in einer kurzen Reihe, die Statnive Live einführt. Artikel 1 hat die Entscheidung WordPress-Plugin vs. Statnive Live durchlaufen; Artikel 2 hat die EU-Regulierungslandschaft 2026 abgedeckt. Dieser hier dreht sich um die Deployment-Form – Verantwortlicher vs. Auftragsverarbeiter, Blast-Radius und das Bedrohungsmodell auf jeder Seite.

Wovor Self-Hosting Sie tatsächlich schützt

Self-Hosting fasst fünf häufige SaaS-Analytics-Bedrohungen zu einem Server zusammen, den Sie bereits besitzen:

1. Vendor geht insolvent, schwenkt um oder ändert Preise willkürlich. SmartSaaS und Sharp Hue framen das als kanonisches SaaS-Risiko; wenn Ihr Analytics-Stack auf den Servern eines anderen lebt, lebt Ihre historische Daten auf der Roadmap eines anderen.
2. Vendor-Übernahme. Neue Eigentümer können die Datenschutzhaltung ändern, den Preis erhöhen oder eine Replattformierung erzwingen. J. Chang Law verfolgt die vertragliche Seite dieser Streitigkeiten.
3. Datenleck-Exposition beim Vendor. Wenn Besucherdaten in einer Multi-Tenant-SaaS liegen, ist jeder Vorfall beim Vendor ein Vorfall Ihrer Daten (Kiteworks-Rahmung). Self-Hosting begrenzt den Blast-Radius auf Ihren eigenen Server.
4. Risiko grenzüberschreitender Übermittlung. Hosting außerhalb des EWR löst DSGVO Kapitel V (Artikel 44–49) aus. Die sauberste Antwort ist, im EWR zu bleiben – siehe Artikel 2 dieser Reihe für die regulatorische Begründung.
5. Erzwungene Offenlegung durch Regulatoren. Der US CLOUD Act + FISA 702 reichen an jegliche Daten, die ein US-eingetragener Anbieter kontrolliert, unabhängig davon, wo sie physisch liegen. Wie Civo es formuliert: „Ihre Daten in Frankfurt oder Dublin zu speichern, bringt sie nicht außer Reichweite der US-Strafverfolgung. Wenn der Anbieter ein US-Unternehmen ist, können US-Behörden den Zugriff auf jegliche Daten erzwingen, die dieses Unternehmen kontrolliert, wo immer sie gespeichert sind.” FISA 702 wäre im April 2026 ausgelaufen, Verlängerungsdruck war zum Schreibzeitpunkt bereits unterwegs – der Post-Verlängerungs-Scope wird zeigen, ob sich das Bild ändert; die architektonische Antwort hängt nicht davon ab.

Ein selbst gehostetes Binary auf betreiber-kontrollierter Infrastruktur, betrieben von einer Nicht-US-Rechtsperson, fasst alle fünf Bedrohungen in ein Problem zusammen, das der Betreiber bereits managt – seinen eigenen Server.

Wovor Self-Hosting nicht schützt

Die ehrliche Begleitliste. Self-Hosting verschiebt Risiko; es entfernt es nicht. Vier Dinge bleiben Ihr Problem:

Kompromittierung Ihres eigenen Servers. Host-OS, ClickHouse, das Go-Binary, das Netzwerk – all das sitzt jetzt in Ihrem Blast-Radius. Wenn Ihre Sysadmin-Haltung schwach ist, kann Self-Hosting es schlimmer machen, nicht besser. Die Slimstat- / TeamUpdraft-Rahmung von Self-Hosted als Serverlast ist derselbe Trade-off, nur als Performance-Frage formuliert.

Verlust von Verschlüsselungsschlüsseln. LUKS-verschlüsselte Festplatten und age-verschlüsselte Backups funktionieren, solange die Schlüssel existieren. Verlieren Sie sie, sind die Daten weg – wie ein SSH-Schlüssel oder eine Bitcoin-Wallet. Wir dokumentieren die LUKS-Wiederherstellungs-Geschichte in docs/luks.md; alles andere ist Sache Ihres Passwortmanagers.

Insider-Risiko in Ihrem eigenen Team. Ein böswilliger oder fahrlässiger Administrator kann rohe Events vor dem Hashing lesen, Tabellen löschen oder Audit-Logs exfiltrieren. RBAC (admin / viewer / API-only) hilft kompartmentieren; das Restrisiko liegt bei Ihnen.

Betreiberfehler. Daten löschen, Backups falsch konfigurieren, das Dashboard offen lassen. Dieselbe Restore-on-Release-Übung, die gegen einen Vorfall schützt, schützt auch gegen Betreiberfehler – aber nur, wenn Sie sie tatsächlich gefahren haben.

Wenn diese vier für Sie immer noch besser sitzen als die SaaS-Vendor-Liste oben, hosten Sie selbst. Wenn nicht, deckt der private-EU-SaaS-Pfad die meisten davon ab und behält die EU-Only-Datenresidenz-Geschichte intakt.

Die Single-Binary-Architektur

Beide Pfade fahren das identische Go-Binary gegen das identische ClickHouse-Schema. Es gibt keinen Fork, keine zweite Codebasis. Alle Assets – Tracker-JS, Dashboard-SPA, ClickHouse-Migrationen, vendierte Go-Abhängigkeiten – sind via go:embed eingebettet. Kein externes CDN, kein Runtime-npm install, kein go mod download zur Laufzeit.

Air-Gap ist ein nicht verhandelbares Projektziel, keine Ambition. Das Binary muss vollständig air-gapped unter iptables -P OUTPUT DROP mit null erforderlichen ausgehenden Verbindungen laufen. Das Release-Gate fährt den Air-Gap-Test bei jedem Release: Events ingestieren, Rollups materialisieren, Dashboard rendert – alles unter dem iptables-Drop. Ausgehender Verkehr bei Opt-in-Features (z. B. ein optionales GeoIP-Datenbank-Update) wird durch internal/httpclient/guarded.go geleitet – FQDN-Allowlist, RFC-1918/Loopback/CGNAT-Ablehnung nach DNS-Auflösung, erzwungenes HTTPS. Die Standard-Allowlist ist leer.

In CI lehnt die air-gap-validator-Regel rohe *http.Client-Konstruktionen, Runtime-DNS/HTTP, CDN-Importe im Dashboard oder Tracker, Telemetrie-Pings und externe Font-/Skript-URLs ab. Der Vertrag wird durch Code-Review und durch Semgrep erzwungen, nicht durch eine Checkliste.

Defence in Depth – die konkreten Aussagen

Die kryptographischen und operationalen Primitive, mit Dateipfaden zur Verifizierung:

• Besucher-Identität: HMAC(master_secret, site_id || YYYY-MM-DD), BLAKE3-keyed, in-process abgeleitet, nie persistiert, täglich rotiert. Gleicher Besucher → anderer Hash jeden Tag. Gespeichert als FixedString(16) (BLAKE3-128, auf 16 Bytes gekürzt) in ClickHouse. SHA-256 / BLAKE3 sind die einzigen Hash-Familien im Binary; kein MD5, kein SHA-1.
• Dashboard-Auth: bcrypt Cost 12 Passwort-Hashing, crypto/rand 32-Byte-Session-Tokens (256 Bit, hex-kodiert), 14-Tage-TTL, SameSite=Lax HttpOnly Secure Cookies. Bcrypt Cost 12 dauert ~50 ms+ auf jeder Maschine, die es je läuft – das ist der Punkt.
• Audit-Log: JSONL über Gos slog, append-only, nur File-Sink in v1, chattr +a-Disziplin, logrotate copytruncate=off. Syslog und Remote-Sinks auf v1.1 verschoben – das bewahrt den Air-Gap-Default.
• At-Rest-Verschlüsselung: LUKS2 mit aes-xts-plain64, Schlüsselgröße 512, argon2id-PBKDF, iter-time 2000. Pflicht auf Shared-Tenant-Cloud-VPS (einschließlich Netcup VPS 2000 G12 NUE D1); optional auf dediziertem Cage-Hardware. Gemessener I/O-Hit liegt bei 40–50 % auf ext4-über-LUKS1; AES-NI + AVX2 halbiert das.
• Verschlüsselte Backups: clickhouse-backup + age + zstd, cron-geplant. Restore-Test bei jedem Release. Backups gehen für SaaS an einen EU-only-Zweitstandort; bei Self-Host wählt der Betreiber den Ort.
• systemd-Härtung: NoNewPrivileges, ProtectSystem=strict, PrivateTmp, CapabilityBoundingSet=CAP_NET_BIND_SERVICE. Service-Unit kommt zusammen mit den Air-Gap-iptables-Regeln über make airgap-bundle.
• Sec-GPC-Short-Circuit: Wenn Sec-GPC: 1 oder DNT: 1 gesetzt ist, wird die Anfrage vor der Berechnung der Besucher-Identität verworfen. Es wird kein pseudonymer Identifier für einen ablehnenden Besucher erzeugt – nichts zu löschen, weil nichts erzeugt wurde.

Wann selbst hosten vs. wann private EU-SaaS nehmen

Fünf Faktoren entscheiden das tatsächlich. Die meisten Leser sehen sich schnell in einer Spalte.

1. Ops-Personal. Self-Hosting kostet Ops-Zeit. Der Betreiber besitzt TLS-Rotation, GeoIP-Datenbank-Drops, ClickHouse-Upgrades, Kernel-Patches, die LUKS-Passphrase. Wenn Sie niemanden haben, dessen Job ohnehin einen Linux-Server umfasst, nehmen Sie die SaaS.

2. Traffic-Volumen. Statnive Lives Design-Decke liegt bei 200 M Events/Tag pro Node auf einer 8-Kern- / 32-GB-Box. Unter ca. 10 M Events/Tag funktionieren beide Pfade gleichwertig; über ca. 50 M Events/Tag fängt die operative Reife für Self-Hosting an, aus eigenem Recht vernünftig auszusehen.

3. Audit- und Compliance-Haltung. Regulierte Branchen brauchen oft beides – einen unterzeichneten AVV nach Art. 28 Abs. 3 DSGVO und Infrastruktur, die sie selbst steuern. Der Private-SaaS-Pfad deckt die AVV-Hälfte; Self-Hosting deckt beide Hälften, verlagert aber die operative Last auf Ihr Team.

4. Geographie. SaaS wird in Nürnberg, Deutschland (Netcup VPS 2000 G12 NUE) verarbeitet – nur EU/EWR, keine Kapitel-V-Übermittlung. Self-Host stellt die Daten dort hin, wo Ihr Server steht. Länderspezifische Datenresidenz-Regeln (Schweizer FADP, deutsche Public-Sector-Beschaffung) verlangen manchmal eine bestimmte Stadt – nur Self-Host gibt diese Kontrolltiefe.

5. Kosten im Maßstab. SaaS ist traffic-bepreist (Starter / Growth / Business von 9–339 $/Mo. über die veröffentlichten Tarife; Enterprise darüber). Self-Host tauscht die SaaS-Rechnung gegen einen Hetzner CX43 (~14 €/Mo.) oder Netcup VPS 2000 G12 (25,48 €/Mo. monatlich) plus Betreiberzeit. Bei niedrigem Traffic gewinnt SaaS bei der TCO; bei sehr hohem Traffic gewinnt Self-Host.

Wenn drei oder mehr davon in dieselbe Richtung kippen, ist das Ihre Antwort. Wenn sie sich teilen, nehmen Sie die SaaS für die ersten 6 Monate als Default – Sie können später ohne Datenverlust zu Self-Host wechseln, weil Binary und Schema gleich sind.

Die „private SaaS”-Mittellage

Eine präzise Note dazu, was „privat” hier bedeutet. Die Statnive-Live-SaaS ist logisch tenant-isoliert – jede Event-Zeile trägt eine site_id, jede Dashboard-Abfrage läuft durch whereTimeAndTenant() mit WHERE site_id = ? als erstem Prädikat, und eine CI-Tenancy-Choke-Point-Regel lehnt jede neue Abfrage ab, die das umgeht. Es ist nicht physische Single-Tenancy: ein ClickHouse-Cluster bedient alle Kunden. Kunden, die physische Single-Tenancy wollen, nehmen den Self-Host-Pfad.

Was die SaaS ab Werk liefert:

• AVV nach Art. 28 Abs. 3 DSGVO auf jedem Plan (inkl. Free), unterzeichnet datiert 2026-04-24. Der AVV deckt alle acht Unterabsätze von Art. 28 Abs. 3 – nur Weisungen, Vertraulichkeit, Art. 32-Sicherheit, Subunternehmer-Genehmigung, Unterstützung bei Betroffenenrechten, Unterstützung bei den Verantwortlichen-Pflichten Art. 32–36, Löschung oder Rückgabe bei Beendigung, Auditrechte.
• Subunternehmer-Liste innerhalb von 7 Tagen nach jeder Upstream-Änderung aktualisiert, mit 14 Tagen Vorankündigung für Kunden über die Datenschutz-Seite; Kunde darf in diesem Fenster schriftlich widersprechen.
• 30-Tage-Kunden-Export-Fenster bei Beendigung – vollständiger CSV/JSON-Export über den Standard-Export-Endpunkt. Nach 30 Tagen werden Rohtabellen, Rollup-Tabellen, Backups (nächster Backup-Zyklus ≤ 24 h) und Audit-Logs gelöscht, außer wo Unions- oder Mitgliedstaatsrecht Aufbewahrung verlangt.
• 48-Stunden-SLA für Vorfall-Benachrichtigung ab Kenntnis, spiegelt DSGVO Art. 33.
• Verarbeitung nur in der EU/im EWR. Keine Kapitel-V-Übermittlung gespeicherter personenbezogener Daten außerhalb des EWR. Die zwei US-ansässigen Subunternehmer in der Kette – Cloudflare DNS-only, Let’s Encrypt für DV-Zertifikate – sind im AVV § 6 unter DPF-Adäquanz offengelegt. Sie erhalten nur DNS-Metadaten und Zertifikats-Metadaten, nie Anwendungsnutzlast.

Dieser letzte Punkt ist die tragende Antwort auf die CLOUD-Act- / FISA-702-Frage. „Keine US-eingetragene Partei in der Verarbeitungskette” ist die strikte Version, und das ist es, was Civo und SoftwareSeni in den obigen Quellen fordern. „Frankfurt oder Dublin macht einen US-Anbieter nicht souverän” ist das, was die Architektur tatsächlich beantworten muss; „betrieben von einem in Deutschland ansässigen Kunden eines deutschen Rechtssubjekts auf Infrastruktur in Nürnberg” ist die Antwort.

Migrationspfad zwischen den beiden

Dieser Teil ist kurz, weil er bewusst ereignislos ist.

Gleiches Binary, gleiches Schema. Die Migrationen liegen in clickhouse/migrations/ und nutzen von Tag eins an {{if .Cluster}} Go-Templates – der Übergang Single-Node → Distributed ist ein Config-Flip, keine Replattformierung.

Kein Daten-Lock-in. ClickHouse nutzt Standard-Binärformate (Parquet / Native / RowBinary) plus das clickhouse-backup-Archivformat. Migration von Statnive Live in ClickHouse Cloud oder ein selbst verwaltetes Cluster ist ein clickhouse-backup-Restore, kein Re-Import.

Besucher-gebundener Export und Löschung. GET /api/privacy/access liefert die cookie-gebundenen Zeilen auf der aufgelösten Seite (Art. 15); POST /api/privacy/erase ist der passende Lösch-Endpunkt (Art. 17). Der Lösch-Pfad enumeriert system.columns dynamisch, sodass jede neue Tabelle, die eine cookie_id trägt, automatisch im Scope ist – und die WHERE-Klausel ist cookie_id = ? AND site_id = ?, sodass eine Lösch-Anfrage auf einer Seite niemals die Zeilen eines anderen Mandanten erreichen kann. DSGVO-Auskunft / Löschung von Tag eins, nicht nachgerüstet.

Wenn Sie auf der privaten SaaS starten und später selbst hosten wollen, bitten Sie um das Binary plus ein clickhouse-backup-Archiv Ihrer Daten. Die Release-Pipeline produziert ein reproduzierbares statnive-live-<VERSION>-linux-amd64-airgap.tar.gz plus SHA256SUMS (und eine optionale Ed25519-Signatur) – Sie kopieren das Tarball, clickhouse-backup restore Ihrer Daten, und Sie betreiben dasselbe Dashboard gegen dasselbe Schema, nur auf Ihrer Hardware.

Häufige Fragen

Was passiert, wenn Statnive Live abgeschaltet wird?

Gleiches Binary, Sie fahren es weiter. Self-Host-Kunden haben es bereits. SaaS-Kunden können das Binary plus ein clickhouse-backup-Archiv ihrer Daten auf dem Weg hinaus anfordern. Die Release-Pipeline produziert ein reproduzierbares Airgap-Bundle mit SHA256-Sums; nichts davon hängt davon ab, dass Statnive ein laufendes Unternehmen ist.

Kann ich meine Daten zu ClickHouse Cloud verschieben?

Ja. Die Daten sind im Standard-ClickHouse-Format; clickhouse-backup restore gegen ein ClickHouse-Cloud-Ziel ist der unterstützte Pfad. Wenn Sie die Daten mit einem ganz anderen Tool nutzen wollen, produziert der Export-Endpunkt CSV/JSON.

Kann meine CI gegen eine Statnive-Instanz laufen?

Ja. make ci-local bringt ClickHouse hoch, bringt das Go-Binary hoch, fährt Integrationstests und reißt alles ab. Jeder PR-CI-Runner macht das ohnehin – es ist dieselbe Übung, die Sie auch lokal nutzen würden.

Wo bewahre ich verschlüsselte Backups auf?

Wahl des Betreibers bei Self-Host: jeder S3-kompatible Store, jede Remote-Festplatte, jedes Band. Für SaaS ist ein EU-only-Zweitstandort die vertragliche Antwort. Restore wird bei jedem Release getestet, unabhängig davon, wo die Backups landen.

CLOUD Act / FISA 702 – hilft Nürnberg?

Ja, wenn der Anbieter ebenfalls nicht US-kontrolliert ist. Statnive-Live-SaaS wird von einem in Deutschland ansässigen Kunden von Netcup (einem deutschen Rechtssubjekt) auf Netcup-Infrastruktur in Nürnberg betrieben. Keine US-eingetragene Partei in der Verarbeitungskette → keine CLOUD-Act- / FISA-702-Reichweite über Anwendungsnutzlast. Zwei US-ansässige Subunternehmer erscheinen unter DPF-Adäquanz – Cloudflare DNS-only und Let’s Encrypt – mit DNS-Metadaten und Zertifikats-Metadaten only. Das ist eine andere Oberfläche als „die Datenbank liegt auf AWS-Frankfurt”.

Was ist mit Disaster Recovery?

Der gleiche Restore-Test läuft bei jedem Release gegen das gleiche Encrypted-Backup-Format – age-verschlüsselt, zstd-komprimiert, clickhouse-backup-Archiv. Wir haben außerdem den LUKS-Wiederherstellungspfad in docs/luks.md dokumentiert für die At-Rest-Verschlüsselungs-Schicht. Es gibt keine Magie; es gibt eine Übung, die tatsächlich gefahren wurde.

Das Fazit

Self-Hosting ist 2026 kein Flag-Setzen – es ist die sauberste Antwort auf einen messbaren Trend in EU-Regulierung und Beschaffung. Statnive Live liefert dasselbe Go-Binary plus dasselbe ClickHouse-Schema in zwei Formen: selbst gehostet, wo Sie die gesamte operative Verantwortung übernehmen und die SaaS-Vendor-Risiken verlieren; und private EU-SaaS in Nürnberg, wo Sie einen AVV nach Art. 28 Abs. 3 DSGVO, EU-only-Datenresidenz und ein 7-Tage-Subunternehmer-SLA übernehmen – aber auch den Multi-Tenant-Blast-Radius, den die Architektur gebunden zu halten gestaltet wurde.

Wählen Sie den Pfad, der zu Ihrem Ops-Personal, Ihrem Traffic und Ihrer Audit-Haltung passt. Wenn Sie unentschieden sind, starten Sie auf der SaaS – die Migration zu Self-Host ist ein clickhouse-backup-Restore entfernt.

Statnive Live kommt bald unter statnive.de/live. Bis dahin ist das WordPress-Plugin auf WordPress.org verfügbar, der Vergleichsbeitrag durchläuft den WP-vs.-Live-Entscheidungsbaum, der DSGVO-Guide deckt die regulatorische Seite ab, und die Preisseite stellt beide Produkte gemeinsam dar. Wenn Sie speziell Alternativen zu GA vergleichen, deckt die gerankte Übersicht sieben datenschutzfreundliche Ersatzlösungen mit WordPress-Integrations-Notizen ab. Wenn ein Fakt in diesem Beitrag falsch ist, schreiben Sie mir – jede Aussage hat eine Quellenangabe, und wir korrigieren lieber eine, als eine polierte Halbwahrheit auszuliefern.