OpenWA: ein selbst gehostetes WhatsApp-API-Gateway mit explizitem Risikoprofil
OpenWA ist ein selbstgehostetes WhatsApp-API-Gateway für Anwendungen, die Nachrichten senden und Sitzungen auf ihrem eigenen Server verwalten müssen.
Auf einen Blick
- Was ist das?
- Das OpenWA-Repository bietet ein plugbares, selbst gehostetes WhatsApp-Gateway, aber die README ist über die inoffizielle Verbindung und das Risiko von Kontosperrungen ebenso klar wie über den Funktionsumfang.
- Für wen ist es gedacht?
- OpenWA ist ein selbst gehostetes Gateway, das seinen inoffiziellen Status und die Risikoabwägungen für Konten explizit macht. Es bietet einen breiten Funktionsumfang, ein plugbares Konfigurationsmodell und eine Sicherheitsarchitektur, die sich auf Nicht-Root-Ausführung und Socket-Proxying konzentriert.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- 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
Ein selbst gehostetes Gateway mit plugbarem Kern
OpenWA ist ein kostenloses, quelloffenes, selbst gehostetes WhatsApp-API-Gateway, das in TypeScript geschrieben ist. Die README beschreibt es als eine Möglichkeit für Entwickler, ihre eigene Messaging-Infrastruktur ohne Vendor-Lock-in zu betreiben. Die plugbare Architektur ermöglicht es, die Datenbank-Engine (SQLite oder PostgreSQL), das Backup- und Migrations-Speicher-Backend (lokaler Datenträger oder S3) und die Cache-Schicht (deaktiviert oder Redis) über Konfiguration statt über Anwendungscode-Änderungen zu wählen. Gesendete oder empfangene Mediendateien werden inline an API- und Webhook-Konsumenten zurückgegeben; die README sagt, dass sie nicht automatisch im Speicher-Backend persistiert werden. Die Repository-Metadaten listen 12.423 Sterne, 2.817 Forks und 6 offene Issues auf.
Eine inoffizielle Verbindung mit expliziten Risiken
Die README stellt klar, dass OpenWA kein offizielles Meta-Produkt ist. Es verbindet sich über reverse-engineerte Clients, konkret whatsapp-web.js und Baileys, mit WhatsApp, nicht über die Meta-Cloud-API. Die README warnt, dass das Risiko einer Kontosperrung oder -sperrung immer ungleich null ist, und empfiehlt, eine dedizierte Nummer zu verwenden, deren Verlust man sich leisten kann. Die beiden Engines haben unterschiedliche Abwägungen: whatsapp-web.js betreibt ein Headless-Chromium und sieht wie echter WhatsApp-Web-Traffic aus, mit geringerem Sperrrisiko, aber etwa 300 bis 500 MB RAM pro Sitzung; Baileys spricht direkt das Multi-Device-Protokoll, ist leichter zu identifizieren und verbraucht etwa 30 bis 80 MB pro Sitzung. Die README listet auch sichere Sende-Richtlinien auf: neue Nummern aufwärmen, keine Kaltakquise an Fremde, Sende-Raten begrenzen, Opt-in-Empfänger verwenden, einen Nicht-WhatsApp-Fallback für kritische Abläufe bereithalten und beachten, dass Rechenzentrums-IPs aggressiver markiert werden. Sie weist darauf hin, dass erste Nachrichten an brandneue Kontakte von der serverseitigen WhatsApp-Richtlinie verworfen werden können und dass gesperrte Konten nicht von OpenWA wiederhergestellt werden können. Für regulierte Umgebungen empfiehlt die README stattdessen die offizielle Meta-Cloud-API.
Was die Funktionstabellen abdecken
Die Funktionsliste der README ist in Kern-, Messaging-, Fortgeschrittenen- und Infrastruktur-Gruppen gegliedert. Zu den Kernfunktionen gehören eine REST-API, Multi-Session-Verwaltung, Webhooks mit HMAC-Signatur und optionalen intelligenten Vorabfiltern, ein Web-Dashboard, API-Key-Authentifizierung und Swagger-Dokumentation. Messaging umfasst Text, Medien, Reaktionen, Bearbeitungen, Massensendungen und Zustell- und Lesestatus. Fortgeschrittene Funktionen umfassen Gruppenverwaltung, Profilaktualisierungen, Anrufereignisse mit automatischer Ablehnung pro Sitzung, WhatsApp-Kanäle, Labels, Proxy-Konfiguration pro Sitzung, konfigurierbares Ratenlimit, CIDR-Whitelisting und Audit-Logging für API-Key-, Sitzungs-, Integrationsinstanz- und Infrastruktur-Admin-Operationen. Zu den Infrastrukturfunktionen gehören SQLite und PostgreSQL, ein optionaler Redis-Cache, S3/MinIO-Medienverzeichnis-Backup und -Migration, Docker-Bereitstellung, Kubernetes-fähige Health-Checks und Datenmigration zwischen Backends. Die README markiert alle als erledigt; sie liefert keine Benchmark-Zahlen oder unabhängige Verifikation.
Zwei Schnellstartpfade und Produktionsprofile
Die README bietet zwei Möglichkeiten, OpenWA auszuführen. Der empfohlene Docker-Pfad ist, das Repository zu klonen und docker compose -f docker-compose.dev.yml up -d auszuführen. Das startet die API mit dem Dashboard auf demselben Port; das Dashboard ist unter http://localhost:2785, die API unter /api und Swagger unter /api/docs erreichbar. Für die lokale Entwicklung lauten die Anweisungen npm ci gefolgt von npm run dev, wobei das Dashboard von einem Vite-Entwicklungsserver auf Port 2886 und die API auf 2785 bereitgestellt wird. Produktionsbereitstellungen verwenden die Haupt-docker-compose.yml mit optionalen Profilen: postgres fügt PostgreSQL hinzu, redis fügt Redis hinzu, minio fügt S3-kompatiblen Speicher hinzu und full aktiviert alle drei. Die README weist darauf hin, dass offizielle GHCR-Images Multi-Arch für linux/amd64 und linux/arm64 sind und dass Sie für TLS oder öffentliche Exposition einen eigenen Reverse-Proxy davorstellen sollten. Rootless-Podman-Benutzer werden angewiesen, den Podman-Socket zu starten und DOCKER_HOST zu setzen.
Sicherheitsmaßnahmen im Produktionscontainer
Zwei Sicherheitsmaßnahmen stechen in der README hervor. Erstens legt der Produktions-Stack den Docker-Socket nicht direkt dem Anwendungscontainer offen. Ein docker-proxy Sidecar basierend auf tecnativa/docker-socket-proxy ist das einzige Gateway zum Docker-Daemon, und nur die für die Container-Orchestrierung benötigten Operationen sind aktiviert. Die README warnt, dass dies ein operationelles Gateway ist, keine feingranulare Privilegiengrenze: Mit aktiviertem POST kann der Proxy Container-Erstellung-Payloads nicht eingrenzen, sodass ein kompromittierter API-Container host-root-äquivalent sein könnte. Zweitens führt das Produktionsimage den Node.js-Prozess als Nicht-Root-Benutzer aus. Die Startkette verwendet dumb-init als PID 1, ein docker-entrypoint.sh, das nur als Root läuft, um benannte Volumes zu chownen, und gosu, um zum Benutzer openwa zu wechseln. Die README sagt, dass der Besitz benannter Volumes bei jedem Start automatisch korrigiert wird.
API-Beispiele, Webhooks und der optionale MCP-Server
Die README enthält curl-Beispiele zum Erstellen einer Sitzung, zum Starten und Abrufen des QR-Codes, zum Senden einer Textnachricht und zum Registrieren eines Webhooks. Die Webhook-Registrierung akzeptiert eine URL, eine Ereignisliste und ein optionales Secret für die HMAC-Verifikation. Smart-Filter können als conditions-Objekt mit UND-Logik hinzugefügt werden, wobei Felder wie sender, recipient, body, type, mentions, fromMe, hasMedia und isGroup verwendet werden. Ein Webhook ohne Filter verhält sich wie zuvor. Der MCP-Server ist separat und standardmäßig deaktiviert. Das Setzen von MCP_ENABLED=true mountet einen zustandslosen Streamable-HTTP-Transport unter POST /mcp auf dem vorhandenen Server und stellt etwa 39 kuratierte Tools für Sitzungen, Messaging, Kontakte, grundlegende Gruppenoperationen und Webhook-Lesevorgänge bereit. Die README sagt, dass jeder Tool-Aufruf dieselbe API-Key-Authentifizierung, Rolle und Sitzungsbereichsbegrenzung wie REST durchläuft. Sie empfiehlt einen dedizierten Schlüssel mit minimalen Rechten und Sitzungsbereich, warnt, dass Schlüssel mit IP-Allow-Liste abgelehnt werden, da es über MCP keine echte Client-IP gibt, und sagt, dass die öffentliche Exposition von /mcp hinter einem Auth-Proxy erfolgen sollte; OAuth 2.1 ist noch nicht gebaut.
Technologiestack, Dokumentation und Lizenz
Die Technologiestack-Tabelle listet Node.js 22 LTS, NestJS 11.x, TypeScript 6.x, TypeORM und Docker auf. Die WhatsApp-Engine wird über die Variable ENGINE_TYPE ausgewählt, standardmäßig whatsapp-web.js, alternativ Baileys. Die Repository-Struktur zeigt ein src-Verzeichnis mit Modulen für session, message, webhook, group, contact, auth, infra und health sowie ein React-Dashboard und einen docs-Ordner. Der docs-Ordner enthält eine Projektübersicht, Anforderungsspezifikation, Systemarchitektur, Sicherheitsdesign, Datenbankdesign, API-Spezifikation, Entwicklungsrichtlinien und einen Migrationsleitfaden. Das Projekt ist unter MIT lizenziert. Der Lizenztext erlaubt die Nutzung, Vervielfältigung, Änderung, Zusammenführung, Veröffentlichung, Verteilung, Unterlizenzierung und den Verkauf von Kopien und erklärt, dass die Software ohne jegliche Gewährleistung bereitgestellt wird. Die README erhebt keinen Anspruch auf Support-Verpflichtung oder Sicherheitsgarantie über das hinaus, was Lizenz und Architekturbeschreibung sagen.
Redaktionelles Fazit
OpenWA ist ein selbst gehostetes Gateway, das seinen inoffiziellen Status und die Risikoabwägungen für Konten explizit macht. Es bietet einen breiten Funktionsumfang, ein plugbares Konfigurationsmodell und eine Sicherheitsarchitektur, die sich auf Nicht-Root-Ausführung und Socket-Proxying konzentriert. Die README macht auch klar, was nicht geboten wird: keine offizielle WhatsApp-API, keine Compliance-Freigabe für regulierte Zwecke und keine Garantie, dass Nummern nicht gesperrt werden.
Community-Notizen