3CX in Docker betreiben — was wirklich geht

Kurz vorweg, weil danach am häufigsten gesucht wird: 3CX stellt kein offizielles Docker-Image bereit. Diese Seite erklärt den tatsächlichen Stand, was Community-Ansätze leisten und nicht leisten, und welche Wege 3CX selbst empfiehlt.

Wofür sucht man das — und was ist die reale Antwort?

Wer „3CX Docker" sucht, will meist eines von zwei Dingen: eine reproduzierbare, versionierte Deployment-Methode (typisch bei DevOps-affinen Admins), oder eine leichtgewichtige Testumgebung für ein Lab/eine Demo. Für beide Fälle gibt es funktionierende Wege — nur eben nicht über ein offizielles 3CX-Image.

Warum es kein offizielles Docker-Image gibt

3CX ist keine zustandslose Web-Anwendung, sondern ein Telefonie-Stack mit mehreren Diensten (SIP-Proxy, Media-Server, Datenbank, Web-Server, Provisioning-Dienst), die eng mit dem Betriebssystem-Networking verzahnt sind:

• Breiter RTP-Portbereich: Für Sprachdaten öffnet 3CX 9000–10999/UDP — pro gleichzeitigem Gespräch zwei Ports. Klassisches Docker-Port-Mapping (-p) ist dafür ungeeignet; nötig wäre --network host, was einen zentralen Vorteil von Containern (Netzwerk-Isolation) wieder aufhebt.
• Lizenzbindung an die Installationsmethode: 3CX-Lizenzaktivierung und Updates sind auf die von 3CX geprüften Installationswege ausgelegt (Debian-ISO/Repo). Bei einem selbstgebauten Image ist nicht sichergestellt, dass Updates sauber durchlaufen.
• Support-Ausschluss: Bei Problemen auf einem nicht offiziell unterstützten Setup kann der 3CX-Support die Bearbeitung einschränken oder ablehnen, bis das Problem auf einer supporteten Installation reproduziert wurde.

Was Community-Ansätze tatsächlich bieten

Es kursieren einzelne, von Dritten gepflegte Docker-Images für 3CX (z. B. auf Docker Hub). Wichtig für die Einordnung:

• Sie sind nicht von 3CX geprüft, signiert oder aktuell gehalten — Versionsstand kann veraltet sein, Sicherheitsupdates verzögert.
• Sie eignen sich bestenfalls für Labs, Schulungen oder kurzlebige Testumgebungen ohne Produktionsdaten.
• Für Produktivbetrieb mit echten Kunden-Rufnummern und SLA-Anspruch sind sie nicht zu empfehlen — weder aus Support- noch aus Sicherheitssicht.

Voraussetzungen, falls Sie es trotzdem testen wollen

• Docker Engine, aktuelle Version
• --network host (Bridge-Networking mit Port-Mapping funktioniert wegen des RTP-Portbereichs praktisch nicht zuverlässig)
• Persistentes Volume für Konfiguration, Datenbank und Aufzeichnungen — sonst sind Daten nach jedem Container-Neustart weg
• Klar getrenntes, isoliertes Testnetz — niemals direkt am Produktions-Internet-Uplink

Die von 3CX unterstützten Alternativen

1. Debian-ISO (empfohlen für Eigenbetrieb)

Die offizielle 3CX-Debian-ISO bringt ein gehärtetes Basissystem mit, auf dem ausschliesslich 3CX läuft. Updates laufen über die 3CX-eigene Update-Pipeline. Details siehe Installation-Guide.

2. 3CX-Debian-Repository auf bestehendem Debian 12

Wer bereits einen gepflegten Debian-12-Server (physisch, VM oder Cloud-Instanz) betreibt, kann 3CX über das offizielle Repository per apt installieren — ebenfalls offiziell supportet, siehe Installation-Guide.

3. Vollverwaltetes Hosting

Wer den Betrieb komplett auslagern will: Bei BitBlade läuft 3CX auf sauber gewartetem, offiziell supportetem Debian — DSGVO-Hosting in Frankfurt, Wien oder Zürich, inklusive Backups und Monitoring.

Häufige Fehler und Missverständnisse

„docker pull 3cx:latest" — Image nicht gefunden

Es gibt kein offizielles Image unter diesem oder ähnlichem Namen im Docker Hub der 3CX Ltd. Wer ein Image mit „3cx" im Namen findet, sollte Herausgeber, letzte Aktualisierung und Downloadzahlen genau prüfen, bevor er es produktiv einsetzt.

Keine Sprachverbindung trotz laufendem Container

Meist Ursache: Bridge-Networking statt Host-Networking, wodurch die RTP-Ports 9000–10999 nicht korrekt durchgereicht werden. Ohne --network host bauen SIP-Signalisierung und Audio-Pfad nicht zuverlässig zusammen.

Lizenz lässt sich nicht aktivieren

Container-Umgebungen mit wechselnden Hostnamen/IP-Adressen (typisch bei Orchestrierung mit häufigen Neustarts) können mit der Lizenzbindung von 3CX kollidieren. Bei Debian-ISO oder Repo-Installation tritt dieses Problem nicht auf.

Update über docker pull bringt PBX zum Stillstand

3CX-Updates sind für die interne Update-Pipeline des offiziellen Images konzipiert, nicht für das Austauschen eines Container-Images. Ein Image-Wechsel kann zu inkonsistenten Datenbankständen führen — vorher immer ein vollständiges Backup ziehen.

Was, wenn Sie bereits eine containerisierte Infrastruktur betreiben?

Viele Admins fragen nach Docker, weil ihre übrige Infrastruktur bereits vollständig containerisiert ist (Kubernetes, Docker Swarm) und sie 3CX in dasselbe Betriebsmodell einpassen wollen. Realistische Optionen in diesem Fall:

• 3CX auf einer dedizierten VM neben dem Cluster betreiben — technisch der unkomplizierteste Weg, bricht aber das „alles ist ein Container"-Prinzip.
• 3CX-Hosting extern beziehen und den eigenen Cluster ausschliesslich für andere Workloads nutzen — die Telefonanlage wird dann als verwalteter Dienst konsumiert statt selbst betrieben.
• Vom Community-Image explizit abraten: Ein selbst orchestriertes 3CX in Kubernetes bringt die oben beschriebenen RTP-Portprobleme in noch komplexerer Form mit (Pod-Networking, Service-Mesh) und ist in der Praxis kaum wartbar.

Best Practices, falls ein Container-Setup unvermeidlich ist

• Nur für Lab/Demo, nie mit echten Kundendaten oder Rufnummern produktiv
• --network host statt Port-Mapping verwenden
• Persistente Volumes für /var/lib/3cx und /etc/3cx zwingend einrichten
• Vor jedem Image-Wechsel ein vollständiges Backup ziehen
• Sich bewusst sein, dass 3CX-Support bei containerisierten Setups eingeschränkt reagieren kann