Self-Hosted CRM mit Docker und PostgreSQL

Customermates ist ein selbst gehostetes CRM, das aus zwei Docker-Compose-Diensten besteht: der Anwendung und PostgreSQL 16. Es passt zu Teams, die ihre CRM-Infrastruktur selbst betreiben und einen quelloffenen Kern nutzen möchten. Es ist nicht die Self-Hosted-Ausgabe sämtlicher Customermates-Cloud-Funktionen.

Auf einen Blick

Auf Ihrer Infrastruktur

Customermates-Anwendung und PostgreSQL 16 laufen als zwei Dienste im versionierten Docker-Compose-Deployment.

Enthaltener Umfang

Kern-CRM, eigene Felder und Ansichten, REST, Webhooks und MCP im Funktionsumfang von Starter.

Ihr Betrieb

Netzwerkzugriff, TLS, Updates, Backups, Wiederherstellungstests, Monitoring und konfigurierte externe Anbieter.

Cloud-Grenze

Messaging, einheitlicher Posteingang, verbundener Kalender, gehostetes Mate und KI-Credits bleiben außerhalb des Self-Hostings.

Deployment

Docker Compose

Datenbank

PostgreSQL 16

CRM-Kern

Fünf Datensatztypen

Schnittstellen

REST, Webhooks und MCP

Funktionsumfang

Wie Starter

Was läuft auf Ihrer Infrastruktur?

Das offizielle Deployment umfasst:

• das Customermates-Anwendungs-Image;
• eine PostgreSQL-16-Datenbank;
• die Kerndatensätze für Kontakte, Unternehmen, Deals, Services und Aufgaben; sowie
• REST, Webhooks und MCP für externe KI-Clients.

Die Compose-Datei enthält weder n8n noch ein KI-Modell, einen E-Mail-Versanddienst oder einen separaten Worker. Authentifizierungs-E-Mails benötigen weiterhin den konfigurierten externen Versanddienst. Wenn Sie einen Anbieter verbinden, betreiben Sie diese Integration separat und sollten prüfen, welche Daten sie erhält.

Was ist enthalten und ausgeschlossen?

Der einheitliche CRM-Posteingang ist eine Managed-Cloud-Funktion ab Pro. Beim Self-Hosting stehen der quelloffene CRM-Kern und externe MCP-Clients im Mittelpunkt.

Open-Source- und kommerzielle Code-Grenzen

Der von Customermates selbst entwickelte Code außerhalb von ee/ steht ausschließlich unter AGPL-3.0. Innerhalb von ee/ gilt grundsätzlich die kommerzielle Lizenz; ausgenommen sind die in Abschnitt 6 von ee/LICENSE.md beschriebenen clientseitigen Bilder, Schriften, CSS- und JavaScript-Bestandteile, die ebenfalls unter AGPL-3.0 stehen. Prüfen Sie beide Lizenzen, bevor Sie die Software für Ihren Anwendungsfall ändern, weitergeben oder betreiben.

Diese Trennung ist beim Vergleich eines Open-Source-CRMs wichtig: Ein öffentliches Repository sagt allein noch nicht, welcher Code unter welchen Bedingungen genutzt werden darf. Wenn Sie andere selbst hostbare Projekte abwägen, zeigen die Vergleiche mit EspoCRM und Twenty, wie sich deren Bereitstellung und Lizenzen unterscheiden.

Welche Kontrolle bietet Self-Hosting?

Sie bestimmen, wo Anwendung und PostgreSQL laufen und wie Netzwerkzugriff, Backups, Aufbewahrung und Updates konfiguriert werden. Das gibt Ihnen Kontrolle über die Infrastruktur, garantiert jedoch weder Compliance noch Sicherheit oder einen vollständig isolierten Betrieb.

Jeder angebundene Dienst bildet weiterhin eine eigene Grenze der Datenverarbeitung. OAuth-Anbieter, SMTP, Monitoring, Workflow-Tools und externe KI-Anbieter erhalten die Daten, die Ihre Konfiguration an sie übermittelt. Eine selbst gehostete Installation sendet ohne konfigurierte Sentry-DSN keine Sentry-Daten. Diese spezifische Voreinstellung erlaubt jedoch keine pauschale Aussage zur Telemetrie.

Self-Hosted oder Managed Cloud?

Datensätze wechseln zwischen Installationen oder aus einem anderen CRM als XLSX-Arbeitsmappen (jeweils ein Datensatztyp, innerhalb der Zeilenlimits) oder über die REST-API. Anhänge und eine vollständige Kontoübertragung gehören nicht dazu. Planen Sie einen größeren Umzug daher als Migrationsprojekt, das Sie selbst prüfen.

So prüfen Sie das Deployment

1. Deployment prüfen

   Lesen Sie die Self-Hosting-Anleitung und prüfen Sie die aktuelle Compose-Datei im Repository.

2. Editionsgrenze prüfen

   Stellen Sie sicher, dass der Funktionsumfang von Starter die benötigten Datensätze, Ansichten und Schnittstellen abdecken.

3. Externe Dienste erfassen

   Listen Sie alle geplanten SMTP-, OAuth-, Monitoring-, Workflow- und KI-Anbieter sowie deren Datenzugriff auf.

4. Betrieb entwerfen

   Definieren Sie Backups, getestete Wiederherstellung, Updates, TLS, Monitoring und Zugriffskontrollen.

5. Ohne Kundendaten testen

   Prüfen Sie den vollständigen Ablauf in einer Nicht-Produktionsumgebung, bevor echte Datensätze verarbeitet werden.

Häufig gestellte Fragen