OpenDXP Hosting: Was benötige ich und worauf kommt es an?

OpenDXP bietet Unternehmen eine leistungsfähige Grundlage für Websites, Produktdaten, digitale Medien, Schnittstellen und Commerce-Anwendungen. Damit eine darauf basierende Plattform schnell, sicher und zuverlässig arbeitet, braucht es jedoch mehr als einen einfachen Webserver. Professionelles OpenDXP Hosting umfasst eine passende Infrastruktur, eine durchdachte Systemarchitektur und klar definierte Prozesse für Überwachung, Backups, Updates, Tests und Störungsbehebung.

Gerade für kleine und mittlere Unternehmen ist es wichtig, die Hosting-Entscheidung nicht nur anhand des monatlichen Serverpreises zu treffen. Entscheidend ist, ob die Plattform dauerhaft verfügbar bleibt, Lastspitzen bewältigt, zuverlässig gesichert wird und sich ohne unnötige Risiken aktualisieren lässt.

In diesem Beitrag erklären wir, was OpenDXP ist, wie die Plattform entstanden ist, welche Möglichkeiten für das Hosting bestehen und worauf es im professionellen Produktivbetrieb ankommt.

Was ist OpenDXP?

OpenDXP ist eine quelloffene Digital Experience Platform. Die Plattform verbindet Funktionen aus den Bereichen Content-Management, Product Information Management, Digital Asset Management, Headless CMS und Composable Commerce. Durch ihren API-first-Ansatz kann OpenDXP als zentrale Daten- und Content-Plattform für Websites, Webshops, Kundenportale, Apps und weitere digitale Kanäle eingesetzt werden.

Im Unterschied zu einem klassischen Content-Management-System verwaltet eine DXP nicht nur einzelne Webseiten und Texte. Sie kann Produktinformationen, technische Daten, Bilder, Videos, Dokumente, Übersetzungen, Preise, Kategorien und weitere strukturierte Informationen zentral zusammenführen. Diese Inhalte lassen sich anschließend über Websites, Shops, Schnittstellen oder andere Systeme ausspielen.

OpenDXP ist vollständig Open Source und steht unter der GNU General Public License Version 3. Der Quellcode ist öffentlich zugänglich und kann von Unternehmen, Agenturen und Entwicklern genutzt, geprüft und weiterentwickelt werden. Die Plattform ist für einen selbstbestimmten Betrieb ausgelegt. Unternehmen behalten damit grundsätzlich die Kontrolle über Code, Daten und Infrastruktur. Weitere Informationen bietet die offizielle Beschreibung des OpenDXP Projekts.

Wie ist OpenDXP entstanden und wer steht dahinter?

OpenDXP ist aus der bisherigen Pimcore Community Edition hervorgegangen. Hintergrund war die Einstellung der Weiterentwicklung dieser Community Edition. Ziel des OpenDXP Projekts ist es, die vorhandene, unter GPLv3 lizenzierte Codebasis langfristig zu erhalten, unabhängig weiterzuentwickeln und der Open-Source-Community zur Verfügung zu stellen.

OpenDXP wurde von der Schweizer DACHCOM.DIGITAL AG initiiert und wird gemeinsam mit der Community und freiwilligen Mitwirkenden weiterentwickelt. Das Projekt arbeitet eigenständig und steht nach eigener Aussage in keiner Verbindung zur Pimcore GmbH. Am 13. März 2026 stellte DACHCOM OpenDXP offiziell als Initiative für digitale Souveränität vor. Die Hintergründe dazu finden Sie im Beitrag DACHCOM lanciert OpenDXP.

Die Weiterentwicklung erfolgt transparent und versioniert. Fehlerberichte, Dokumentation, Tests und Code-Beiträge aus der Community sind ausdrücklich erwünscht. Der öffentliche Quellcode und die einzelnen Komponenten sind über die OpenDXP Organisation auf GitHub verfügbar.

Was bedeutet OpenDXP Hosting?

Unter OpenDXP Hosting verstehen wir den technischen Betrieb einer OpenDXP Installation auf einer geeigneten Infrastruktur. Dazu gehören nicht nur CPU, Arbeitsspeicher und Speicherplatz. Ein produktives Hosting-Konzept berücksichtigt unter anderem folgende Bestandteile:

Webserver und PHP-Laufzeit
Datenbank
Dateispeicher für Assets und Dokumente
Cache-System
Message Queues und Hintergrundprozesse
Domain, DNS und TLS-Zertifikate
Firewall und Zugriffsschutz
Monitoring und zentrale Protokollierung
Backups und Wiederherstellungsprozesse
Deployment-, Wartungs- und Update-Prozesse
Test-, Staging- und Produktivumgebung

Die passende Architektur hängt vom konkreten Projekt ab. Eine Unternehmenswebsite mit wenigen hundert Seiten stellt andere Anforderungen als ein internationales Produktportal mit mehreren hunderttausend Datenobjekten, zahlreichen Schnittstellen und einer großen Bilddatenbank.

Technische Grundanforderungen

Nach der aktuellen OpenDXP Dokumentation zu den Systemanforderungen wird für den Produktivbetrieb ein Unix-basiertes System empfohlen. Unterstützt werden Apache ab Version 2.4 und Nginx. Als PHP-Version wird aktuell PHP ab 8.3 und kleiner als 8.5 genannt. Benötigt werden außerdem verschiedene PHP-Erweiterungen, unter anderem PDO MySQL, DOM, GD, EXIF, mbstring, ZIP, Intl, OPcache und cURL.

Als Datenbank können je nach Version und Konfiguration MariaDB, MySQL, Percona Server oder AWS Aurora eingesetzt werden. Redis ist optional, wird aber für das Caching empfohlen. Für umfangreiche Hintergrundverarbeitung kann RabbitMQ als Queue-System sinnvoll sein.

Zusätzliche Programme wie FFmpeg, Ghostscript, LibreOffice, Gotenberg, Inkscape, ExifTool und verschiedene Bildoptimierer werden nur benötigt, wenn die entsprechenden Funktionen genutzt werden. Deshalb sollte die Infrastruktur nicht pauschal, sondern anhand des Funktionsumfangs geplant werden.

Welche Möglichkeiten gibt es für das OpenDXP Hosting?

1. Server im eigenen Netzwerk

OpenDXP kann grundsätzlich auf einem Server im eigenen Unternehmensnetzwerk betrieben werden. Dieser Server wird über die eigene Internetanbindung öffentlich erreichbar gemacht oder ausschließlich für interne Anwendungen verwendet.

Der Vorteil liegt in der vollständigen Kontrolle über Hardware, Netzwerk und Daten. Unternehmen können eigene Sicherheitsvorgaben umsetzen und sensible Informationen innerhalb ihrer Infrastruktur halten.

Der Eigenbetrieb bringt jedoch erhebliche Verantwortung mit sich. Internetanbindung, Stromversorgung, Firewall, Hardware-Austausch, Klimatisierung, Backups und Ausfallsicherheit müssen selbst organisiert werden. Für eine öffentlich erreichbare Unternehmenswebsite ist außerdem eine redundante Internetverbindung empfehlenswert. Fällt der Standort aus, ist ansonsten auch die Website nicht mehr erreichbar.

Diese Variante eignet sich vor allem für Unternehmen mit einer professionellen internen IT-Abteilung und klaren Anforderungen an die lokale Datenhaltung. Für viele KMUs ist sie wirtschaftlich nur dann sinnvoll, wenn bereits eine geeignete Infrastruktur vorhanden ist.

2. Virtueller Server bei einem Hosting-Anbieter

Ein virtueller Server, häufig als VPS oder VServer bezeichnet, ist für viele OpenDXP Projekte ein sinnvoller Einstieg. Das Unternehmen mietet virtuelle Rechenleistung bei einem Hosting-Anbieter und erhält in der Regel administrativen Zugriff auf das Betriebssystem.

Die Kosten sind planbar und die Ressourcen können häufig relativ einfach erweitert werden. Gleichzeitig bleibt genügend Freiheit, um Webserver, PHP, Datenbank, Redis und Worker passend zu konfigurieren.

Allerdings handelt es sich bei einem virtuellen Server meistens nicht automatisch um ein Managed Hosting. Betriebssystem-Updates, Sicherheitsmaßnahmen, Überwachung, Backups und Störungsbehebung liegen oft beim Kunden oder bei seiner Digitalagentur. Ein günstiger Server ohne laufende Betreuung ist daher nicht mit einer professionell betriebenen Plattform gleichzusetzen.

3. Dedizierter Server im Rechenzentrum

Bei einem dedizierten Server steht die physische Hardware ausschließlich einem Kunden zur Verfügung. Diese Variante bietet planbare Leistung und kann bei großen Datenmengen, vielen Bildkonvertierungen oder hoher Dauerlast sinnvoll sein.

Ein einzelner dedizierter Server bleibt jedoch ein möglicher Ausfallpunkt. Für hohe Verfügbarkeit werden mehrere Systeme, redundante Speicherlösungen, externe Datenbanken oder zusätzliche Standby-Komponenten benötigt. Dadurch steigen Aufwand und Kosten.

4. Server und Dienste in der Cloud

OpenDXP kann auch bei Cloud-Anbietern betrieben werden. Dabei kann die Anwendung auf virtuellen Maschinen laufen oder mit verwalteten Diensten für Datenbanken, Objektspeicher, Load Balancer und Monitoring kombiniert werden.

Cloud-Infrastrukturen ermöglichen eine flexible Skalierung und eine klare Trennung einzelner Komponenten. Beispielsweise können Webserver mehrfach bereitgestellt werden, während die Datenbank als Managed Service betrieben wird. Assets können in einem Objektspeicher liegen und über ein Content Delivery Network ausgeliefert werden.

Diese Flexibilität ist besonders bei internationalen Plattformen, schwankender Last oder hohen Verfügbarkeitsanforderungen interessant. Sie bringt aber zusätzliche Komplexität mit sich. Ohne Kostenkontrolle, Ressourcenlimits und eine saubere Architektur können Cloud-Kosten unerwartet steigen.

5. OpenDXP Hosting mit Docker

Docker ist kein eigener Hosting-Ort, sondern eine Methode zur Paketierung und Ausführung von Anwendungen. OpenDXP, PHP, Nginx, Datenbank, Redis und weitere Dienste können in voneinander getrennten Containern betrieben werden.

Container schaffen reproduzierbare Umgebungen. Entwicklung, Tests, Staging und Produktion können mit vergleichbaren Softwareversionen arbeiten. Die offizielle OpenDXP Dokumentation stellt eine Docker-basierte Installation und ein Docker-Compose-Setup bereit.

Docker vereinfacht Deployments, löst aber nicht automatisch alle Betriebsfragen. Persistente Daten müssen außerhalb kurzlebiger Container gespeichert werden. Backups, Netzwerkregeln, Secrets, Updates und Monitoring bleiben weiterhin erforderlich. Für den Produktivbetrieb sollten Images versioniert, regelmäßig neu gebaut und vor der Bereitstellung getestet werden. Die Docker Best Practices empfehlen unter anderem schlanke Images, klare Versionen und automatisierte Tests.

6. Managed OpenDXP Hosting

Beim Managed OpenDXP Hosting übernimmt ein spezialisierter Dienstleister wesentliche Aufgaben des laufenden Betriebs. Dazu können Serververwaltung, Monitoring, Backups, Sicherheitsupdates, Deployments und technische Unterstützung gehören.

Für KMUs ist diese Variante oft besonders attraktiv. Das Unternehmen muss keine eigene Betriebsabteilung aufbauen und erhält einen festen Ansprechpartner, der sowohl die Infrastruktur als auch die Anwendung versteht. Wichtig ist, den genauen Leistungsumfang vertraglich festzulegen. Begriffe wie Managed Hosting oder Full Service werden von Anbietern unterschiedlich verwendet.

Worauf kommt es beim produktiven OpenDXP Hosting an?

Eine realistische Dimensionierung

Die Dimensionierung sollte sich an Nutzung, Datenvolumen und Wachstum orientieren. Relevant sind nicht nur die monatlichen Seitenaufrufe. Auch die Anzahl der Datenobjekte, Asset-Größen, Redakteure, Imports, Exporte, Schnittstellen und Hintergrundjobs beeinflusst den Ressourcenbedarf.

Bild- und Videokonvertierungen können kurzfristig viel CPU und Arbeitsspeicher benötigen. Große Produktimporte belasten Datenbank und Queue-System. Viele gleichzeitige Redakteure erzeugen eine andere Last als überwiegend anonyme Website-Besucher. Deshalb sollte die Plattform vor dem Go-Live mit realistischen Daten und Lastprofilen getestet werden.

Produktionsmodus und Caching

Eine produktive OpenDXP Installation muss im Produktionsmodus ohne Debug-Funktionen laufen. Die offizielle Dokumentation nennt dafür unter anderem die Einstellungen , und .

OPcache sollte aktiviert sein. Für das zentrale OpenDXP Caching empfiehlt die Dokumentation Redis. Nach einem Deployment oder dem Leeren des Caches kann ein gezieltes Cache-Warming verhindern, dass die ersten Besucher langsame Seiten erhalten. Weitere Hinweise finden Sie im OpenDXP Performance Guide.

Hintergrundprozesse und Message Queues

OpenDXP verarbeitet viele Aufgaben im Hintergrund. Dazu gehören Wartungsaufgaben, Asset-Metadaten, Bildoptimierungen, Suchindizes und teilweise Video- oder Dokumentenkonvertierungen.

Diese Aufgaben werden über Symfony Messenger abgewickelt. Im Produktivbetrieb müssen daher passende Worker dauerhaft oder zeitgesteuert laufen. Ein Prozessmanager wie Supervisor oder eine entsprechende Container-Orchestrierung sollte abgestürzte Worker automatisch neu starten.

Neben der reinen Verfügbarkeit ist die Länge der Warteschlangen zu überwachen. Eine Website kann oberflächlich erreichbar sein, während sich im Hintergrund tausende nicht verarbeitete Nachrichten ansammeln. Derartige Probleme zeigen sich später durch fehlende Vorschaubilder, veraltete Suchindizes oder verzögerte Datenverarbeitung.

Monitoring auf mehreren Ebenen

Professionelles Monitoring prüft nicht nur, ob der Server auf einen Ping antwortet. Für zuverlässiges OpenDXP Hosting sollten mindestens folgende Bereiche überwacht werden:

Erreichbarkeit wichtiger Frontend-Seiten
Erreichbarkeit des Administrationsbereichs
HTTP-Statuscodes und Antwortzeiten
CPU-Auslastung, Arbeitsspeicher und Festplattenplatz
Datenbankverbindungen und langsame Abfragen
Redis-Verfügbarkeit und Speichernutzung
Queue-Länge und Status der Worker
Fehlgeschlagene Hintergrundjobs
Ablaufdatum der TLS-Zertifikate
Cronjobs und Wartungsprozesse
Fehlerrate von APIs und externen Schnittstellen
Erfolg und Alter der letzten Backups

Warnungen müssen an Personen gehen, die tatsächlich reagieren können. Ein Monitoring-System ohne Eskalationsprozess erzeugt zwar Meldungen, verbessert aber nicht automatisch die Verfügbarkeit.

Zentrale Logs und nachvollziehbare Fehler

Webserver-, PHP-, OpenDXP-, Datenbank- und Worker-Logs sollten zentral gesammelt und durchsucht werden können. Dadurch lassen sich Fehler über mehrere Komponenten hinweg analysieren.

Gleichzeitig dürfen Logs keine ungeschützten Passwörter, Zugangsdaten oder unnötigen personenbezogenen Informationen enthalten. Die OWASP Logging Cheat Sheet empfiehlt unter anderem einen geschützten Zugriff, eine sichere Übertragung und aktive Alarmierung bei kritischen Ereignissen.

Backups mit klaren Wiederherstellungszielen

Ein vollständiges OpenDXP Backup muss mindestens die Datenbank und die relevanten Dateien des Projekts enthalten. Dazu gehören insbesondere Assets, Konfigurationen, individueller Programmcode und weitere nicht reproduzierbare Daten. Temporäre Dateien, Cache-Verzeichnisse und Logs können je nach Backup-Konzept ausgeschlossen werden. Die notwendigen Bestandteile beschreibt die offizielle Seite Backup of OpenDXP.

Wichtig ist die Konsistenz zwischen Datenbank und Dateispeicher. Werden beide Komponenten zu unterschiedlichen Zeitpunkten gesichert, können nach einer Wiederherstellung Verweise auf nicht vorhandene Assets entstehen.

Für das Backup-Konzept sollten zwei Kennzahlen festgelegt werden:

RPO: Wie viele Daten dürfen im schlimmsten Fall verloren gehen?
RTO: Wie schnell muss die Plattform nach einem Ausfall wieder verfügbar sein?

Backups sollten verschlüsselt, räumlich getrennt und gegen unbemerkte Löschung geschützt werden. Mindestens ebenso wichtig sind regelmäßige Wiederherstellungstests. Ein Backup ist erst dann verlässlich, wenn die Wiederherstellung praktisch geprüft wurde.

Wartung und Updates

OpenDXP, Symfony, PHP, Betriebssystem, Datenbank, Webserver und sämtliche Composer-Pakete müssen regelmäßig aktualisiert werden. Updates sollten niemals unkontrolliert direkt auf der Produktivumgebung erfolgen.

Ein sicherer Ablauf umfasst in der Regel folgende Schritte:

Prüfung der Release Notes und Abhängigkeiten
Erstellung eines aktuellen Backups
Update in einer Entwicklungs- oder Testumgebung
Automatisierte und manuelle Tests
Abnahme auf einer Staging-Umgebung
Geplantes Deployment
Datenbankmigrationen und Aktualisierung der Klassendefinitionen
Cache-Bereinigung und Cache-Warming
Smoke-Tests und verstärktes Monitoring
Dokumentierte Möglichkeit für einen Rollback

OpenDXP stellt verschiedene Deployment-Kommandos bereit. Nach Code-Updates kann beispielsweise ein Neuaufbau der Klassendefinitionen notwendig sein. Die verfügbaren Werkzeuge beschreibt die Dokumentation unter OpenDXP Deployment Tools.

Tests vor und nach dem Deployment

Für professionelle Plattformen empfehlen wir mindestens drei getrennte Umgebungen: Entwicklung, Staging und Produktion. Die Staging-Umgebung sollte die produktive Architektur möglichst realistisch abbilden.

Automatisierte Unit-, Integrations- und Anwendungstests helfen dabei, Fehler frühzeitig zu erkennen. OpenDXP basiert auf Symfony, weshalb sich die etablierten Symfony- und PHPUnit-Werkzeuge nutzen lassen. Die Symfony Dokumentation zu automatisierten Tests unterscheidet unter anderem Unit-Tests, Integrationstests und vollständige Anwendungstests.

Nach jedem Deployment sollten zusätzlich zentrale Funktionen geprüft werden, zum Beispiel Startseite, Suche, Formulare, Login, Asset-Auslieferung, wichtige APIs, Bestellprozesse und Datenimporte.

Sicherheit und Zugriffsrechte

Der Administrationsbereich sollte ausschließlich verschlüsselt erreichbar sein. Für Benutzer sind individuelle Konten und rollenbasierte Berechtigungen zu verwenden. Administratorrechte sollten nur Personen erhalten, die sie tatsächlich benötigen.

OpenDXP unterstützt eine integrierte Zwei-Faktor-Authentifizierung. Diese kann für Benutzer verpflichtend aktiviert werden. Weitere Informationen bietet die OpenDXP Dokumentation zur Zwei-Faktor-Authentifizierung.

Zusätzlich sollten Datenbank, Redis und interne Dienste nicht direkt aus dem öffentlichen Internet erreichbar sein. Zugangsdaten gehören in eine sichere Secret-Verwaltung und nicht in öffentlich zugängliche Repositories.

Häufige Fragen und Antworten zu Fehlern beim OpenDXP Hosting

Warum zeigt OpenDXP nur einen HTTP-500-Fehler?

Ein HTTP-500-Fehler kann durch PHP-Fehler, fehlende Erweiterungen, falsche Umgebungsvariablen, Datenbankprobleme oder unzureichende Dateirechte entstehen. Prüfen Sie zuerst die OpenDXP-, PHP-FPM- und Webserver-Logs. Stellen Sie sicher, dass die Anwendung im richtigen Environment läuft und alle Abhängigkeiten installiert sind.

Warum können Bilder oder Dateien nicht hochgeladen werden?

Häufig sind upload_max_filesize, oder post_max_size Webserver-Limits zu niedrig. Auch fehlende Schreibrechte in /var oder /public/var können die Ursache sein. Bei einem Proxy oder Load Balancer muss zusätzlich dessen Upload-Limit berücksichtigt werden.

Warum werden keine Vorschaubilder erzeugt?

Mögliche Ursachen sind fehlende Bildbibliotheken, nicht laufende Queue-Worker oder Fehler bei den Dateirechten. Prüfen Sie außerdem, ob optionale Werkzeuge wie ImageMagick und Bildoptimierer korrekt installiert und über den Systempfad erreichbar sind.

Warum ist das OpenDXP Backend langsam?

Typische Gründe sind fehlendes Redis-Caching, deaktiviertes OPcache, eine überlastete Datenbank, zu wenig Arbeitsspeicher oder eine große Anzahl unbearbeiteter Queue-Nachrichten. Eine fundierte Analyse sollte Messwerte aus Anwendung, Datenbank und Infrastruktur zusammenführen.

Warum werden Hintergrundjobs nicht verarbeitet?

Meist laufen die Symfony-Messenger-Worker nicht oder greifen auf einen falschen Transport zu. Prüfen Sie den Prozessmanager, die Queue-Konfiguration und fehlgeschlagene Nachrichten. Worker sollten automatisch neu gestartet und ihre Laufzeit überwacht werden.

Warum funktioniert OpenDXP nach einem Deployment nicht mehr?

Nach Updates können Datenbankmigrationen, ein Neuaufbau der Klassendefinitionen, eine Cache-Bereinigung oder ein aktualisierter Composer-Autoloader notwendig sein. Deshalb benötigt jedes Deployment eine feste Checkliste und eine getestete Rollback-Strategie.

Kann OpenDXP auf einem normalen Shared-Hosting-Paket betrieben werden?

Für sehr einfache Testinstallationen ist das möglicherweise technisch machbar. Für den professionellen Produktivbetrieb ist klassisches Shared Hosting jedoch meist ungeeignet. Häufig fehlen Shell-Zugriff, Worker-Prozesse, Redis, individuelle PHP-Einstellungen und zuverlässige Deployment-Möglichkeiten.

Ist Docker für OpenDXP Hosting zwingend erforderlich?

Nein. OpenDXP kann klassisch auf einem Linux-Server oder in einer virtuellen Maschine installiert werden. Docker ist eine sinnvolle Option für reproduzierbare Umgebungen, aber keine Pflicht. Entscheidend ist, dass das Betriebsteam die gewählte Architektur sicher beherrscht.

Wie oft sollte ein OpenDXP Backup erstellt werden?

Das hängt vom maximal tolerierbaren Datenverlust ab. Bei häufigen redaktionellen Änderungen, Bestellungen oder Produktimporten können tägliche Backups unzureichend sein. Die Frequenz sollte aus dem gewünschten RPO abgeleitet werden. Zusätzlich sind regelmäßige Restore-Tests erforderlich.

Wie erkennt man, ob das OpenDXP Hosting richtig dimensioniert ist?

Dafür werden Lasttests und reale Betriebsdaten benötigt. CPU, Arbeitsspeicher, Datenbankabfragen, Antwortzeiten, Queue-Längen und Cache-Trefferraten sollten über einen längeren Zeitraum ausgewertet werden. Eine hohe durchschnittliche Auslastung oder regelmäßig anwachsende Warteschlangen sind Hinweise auf Engpässe.

OpenDXP Hosting mit Viucom

Als Digitalagentur mit über 25 Jahren Erfahrung im Web-Bereich kennen wir bei Viucom die Anforderungen an geschäftskritische Websites, Portale und individuelle Plattformen. Beim OpenDXP Hosting betrachten wir nicht nur den Server, sondern das gesamte System aus Anwendung, Infrastruktur, Datenbank, Caching, Hintergrundprozessen, Sicherheit und Wartung.

Wir unterstützen Sie bei der Planung einer neuen Hosting-Architektur, bei der Migration bestehender Systeme und bei der Optimierung laufender OpenDXP Installationen. Je nach Projekt können wir gemeinsam mit Ihnen passende Hostingmöglichkeiten entwickeln und den technischen Betrieb begleiten.

Dazu gehören beispielsweise die Analyse des Ressourcenbedarfs, der Aufbau von Entwicklungs-, Staging- und Produktivumgebungen, automatisierte Deployments, Monitoring, Backup-Konzepte, Performance-Optimierung und regelmäßige Wartung.

Sie planen eine OpenDXP Website, möchten eine bestehende Installation stabilisieren oder benötigen eine fundierte Einschätzung Ihrer aktuellen Infrastruktur? Wir freuen uns über Ihre Kontaktanfrage und beraten Sie persönlich, transparent und auf Augenhöhe.

Fazit: Gutes OpenDXP Hosting ist ein laufender Prozess

OpenDXP kann auf einem eigenen Server, einem virtuellen Server, einer Cloud-Infrastruktur oder in Docker-Containern betrieben werden. Die richtige Lösung hängt von Datenvolumen, Funktionsumfang, Budget, Verfügbarkeitszielen und internen Kompetenzen ab.

Für einen stabilen Produktivbetrieb sind Monitoring, Backups, Updates, Tests und dokumentierte Notfallprozesse unverzichtbar. Auch Queue-Worker, Cache-Systeme, Datenbankleistung und Asset-Verarbeitung müssen aktiv überwacht werden. Ein Server, der lediglich eingeschaltet ist, stellt noch kein professionelles OpenDXP Hosting dar.

Als Digitalagentur Viucom stehen wir Ihnen mit langjähriger Erfahrung und hoher technischer Expertise bei Fragen rund um OpenDXP Hosting, Architektur, Performance, Wartung und sicheren Produktivbetrieb gerne zur Verfügung. Sprechen Sie uns an, wenn Sie Unterstützung benötigen oder gemeinsam mit uns eine passende Hostinglösung entwickeln möchten.