Hosting Docker Compose. Twój compose, nasz serwer.

1. Docker als Anwendungstyp, kein zusätzliches Produkt

Viele Hosting-Anbieter reservieren Docker für teurere VPS- oder Cloud-Tarife, weil Docker mehr Isolation und Kontrolle erfordert als klassisches Shared Hosting. Bei Saplo ist Docker einfach einer der Anwendungstypen im Katalog, genauso verfügbar wie WordPress oder eine statische Website. Für das Ausführen von Containern gibt es keine separate, höhere Preisschwelle.

In der Praxis nutzen 152 von 166 Anwendungen im Saplo-Katalog Docker im Hintergrund. Die Container-Engine läuft daher auf deinem Box mit Docker, unabhängig davon, ob du ein fertiges Setup aus dem Katalog installierst oder dein eigenes Image vom Typ custom einrichtest.

Für dein eigenes Docker-Image steht der Anwendungstyp custom zur Verfügung. Damit kannst du dein eigenes Dockerfile oder docker-compose angeben, ohne auf die vorgefertigten Rezepte im Katalog beschränkt zu sein. Bei nicht standardisierten Projekten hast du so volle Freiheit.

2. Privates Docker Registry inklusive

Der Anwendungskatalog enthält außerdem Docker Registry: eine private Image-Registry mit dem offiziellen Image registry:2 und einer einfachen UI, in der Repositories, Tags und Schichten im Browser angezeigt werden können. Basic Auth mit einem bei der Installation zufällig generierten Login und Passwort schützt den Zugriff.

Für ein Team, das eigene Images in CI/CD baut, bedeutet das, private Images ohne Konto bei Docker Hub und ohne die Pull-Rate-Limits zu speichern, die für kostenlose Konten in öffentlichen Registries bei häufigen Image-Pulls während Deployments gelten.

Die UI von Docker Registry dient als Reverse-Proxy für die API desselben Registers. Unter einer einzigen Domain und ohne CORS funktionieren docker login, push und pull daher direkt unter der Anwendungsdomain, ohne dass zusätzliche Ports separat konfiguriert werden müssen.

3. Wie viel RAM benötigen Docker-Anwendungen?

Typische Docker-Anwendungen im Saplo-Katalog deklarieren 1 bis 2 GB RAM als Mindestanforderung (Baserow, Chatwoot, Flowise, n8n, Windmill und Typebot jeweils 1 bis 2 GB), da ein offizielles Container-Image meist mehr Abhängigkeiten enthält als eine schlanke PHP-Installation oder eine einfache statische Anwendung.

Mit Box M (2 GB RAM) lässt sich komfortabel eine typische Docker-Anwendung bereitstellen, mit Box L (6 GB RAM) mehrere parallel. Für einen größeren Werkzeugkatalog (CRM, Chat und Automatisierung zusammen) ist das ein reales Minimum, damit die Anwendungen nicht um Arbeitsspeicher konkurrieren. Bei einem noch größeren Set solltest du Box XL in Betracht ziehen: Mit 12 GB RAM hast du echten Spielraum für den weiteren Ausbau deines Werkzeugkatalogs, ohne ständig prüfen zu müssen, welche Anwendung auf deinem Box am meisten Arbeitsspeicher belegt.

Bei eigenen, nicht standardisierten Docker-Images (Typ custom) hängt der RAM-Bedarf davon ab, was das Image tatsächlich tut. Prüfe den RAM-Verbrauch daher lokal, bevor du die Box auswählst, genau wie bei jeder anderen Container-Bereitstellung.

4. Docker auf Saplo im Vergleich zu Docker auf einem unverwalteten VPS

Auf einem nackten VPS musst du Docker selbst installieren, die Firewall an die Container-Ports anpassen und für jeden gestarteten Dienst manuell ein Reverse Proxy für SSL einrichten. Für alle, die nicht mit der Linux-Administration vertraut sind, ist das eine echte Einstiegshürde.

Bei Saplo ist im LXC-Container der Box die Docker-Unterstützung (keyctl, nesting) bereits konfiguriert. Deshalb funktionieren docker run und docker compose up direkt nach der Anmeldung per SSH. Reverse-Proxy und SSL für öffentlich erreichbare Anwendungen richtet das Panel bei der Verknüpfung einer Domain ein.

Bei ähnlichen Ressourcen ist der Kostenunterschied zwischen einem unverwalteten VPS und einem Box mit Docker meist gering. Auf Saplo brauchst du jedoch deutlich weniger Zeit bis zur Inbetriebnahme des ersten Dienstes, weil du die Container-Engine nicht erst von Grund auf konfigurieren musst.

5. Für wen es sich eignet

Wenn du dein eigenes Docker-Image bereitstellen möchtest, ohne einen VPS komplett selbst aufzusetzen, bietet der Anwendungstyp custom auf Box M oder Box L eine fertige Umgebung mit Docker und automatisch konfiguriertem SSL für die angebundene Domain.

Für ein Team, das eigene Images in CI/CD baut, macht das private Docker Registry aus dem Anwendungskatalog ein Konto bei einem öffentlichen Registry und dessen Pull-Rate-Limits überflüssig.

Wenn du mehrere Docker-Anwendungen aus dem Katalog gleichzeitig testest (z. B. CRM, Chat und Automatisierung), bietet Box L mit 6 GB RAM genug Platz für mehrere parallel laufende Anwendungen, ohne dass sie um Arbeitsspeicher konkurrieren.

6. Erste Bereitstellung deines eigenen Docker-Images auf Saplo

Nach der Auswahl des Anwendungstyps custom meldest du dich über SSH an (ab Box M) und bereitest für dein Projekt eine docker-compose.yml oder ein Dockerfile vor, ähnlich wie in jeder anderen Umgebung mit installiertem Docker.

Reverse-Proxy und SSL für einen öffentlich erreichbaren Dienst konfigurierst du nach dem Verbinden einer Domain im Saplo-Panel. Gib dort den Port an, auf dem dein Container lauscht. Eine manuelle Konfiguration von nginx oder Zertifikaten auf der Client-Seite ist nicht nötig.

Daten-Volumes (volumes) solltest du so konfigurieren, dass die Anwendungsdaten einen Neustart des Containers überstehen und in das Back-up deines Box einfließen, sofern dein Tarif ein Back-up im Preis enthält.

Bei Multi-Container-Anwendungen (z. B. Datenbank plus Anwendung plus Worker in einer docker-compose-Datei) prüfe vor dem Start des gesamten Stacks, ob die Summe des RAM-Verbrauchs aller Container in das RAM-Limit deines Box passt.

Das private Docker Registry aus dem Anwendungskatalog ermöglicht die Speicherung eigener, selbst gebauter Images, die du später per docker pull auf deinen Box unter derselben Domain herunterlädst, ohne ein Konto bei einem öffentlichen Registry zu benötigen.

7. CI/CD und automatisches Bauen von Docker-Images

Ein typischer CI/CD-Workflow besteht darin, ein Image in einem externen System (GitHub Actions, GitLab CI) zu bauen, es in das private Docker Registry auf Saplo zu pushen und anschließend auf dem produktiven Box per docker pull zu aktualisieren und den Container neu zu starten.

Die Automatisierung des letzten Schritts (Pull und Neustart nach einem neuen Image) lässt sich über ein einfaches, per SSH gestartetes Skript oder einen Webhook realisieren, der einen Workflow in n8n auslöst. n8n läuft dabei auf demselben Box.

Ein privates Registry beseitigt die Pull-Rate-Limits für kostenlose Konten in öffentlichen Registries. Bei häufigen Deployments (mehrmals täglich) kann das ohne kostenpflichtigen Tarif beim externen Anbieter ein reales Problem werden.

Für Teams, die in mehreren Umgebungen (Staging, Produktion) arbeiten, lassen sich im selben privaten Registry separate Image-Tags pflegen. Das erleichtert die Kontrolle darüber, welche App-Version in welcher Umgebung läuft.

8. Best Practices für eigene Docker-Images in der Produktion

Das Festlegen einer konkreten Version des Basis-Images (z. B. node:20.11-alpine statt node:latest) verhindert, dass ein Update des Basis-Images durch den Anbieter beim nächsten Neubau des Containers unerwartet das Verhalten deiner App verändert, oft ohne klaren Hinweis auf die Änderung.

Ein Multi-Stage-Build sorgt dafür, dass das finale Produktions-Image klein bleibt und weder Build-Werkzeuge noch Entwicklungsabhängigkeiten enthält. Das beschleunigt den Transfer vom Image ins Registry und vom Registry auf den Produktionsserver und reduziert zugleich die Angriffsfläche des Containers.

Umgebungsvariablen und Secrets (Passwörter, API-Schlüssel) sollten niemals als im Dockerfile fest eingetragene Werte in ein Docker-Image gelangen, sondern beim Start des Containers übergeben werden. Ein Image, das mit einem eingebetteten Secret gebaut wurde, kann sonst in die Docker Registry gelangen, wo jemand mit Zugriff darauf den Container wiederherstellen kann.

Ein im Image oder in docker-compose konfigurierter Healthcheck erkennt automatisch, wenn der Container läuft, die darin enthaltene App aber nicht mehr reagiert (z. B. bei einem hängenden Prozess). Ohne Healthcheck könnte das unbemerkt bleiben, weil der Container formal weiterläuft.

Container-Logs solltest du an die Standardausgabe (stdout/stderr) senden, nicht in Dateien im Container. Dateien verschwinden beim Löschen des Containers, während Logs aus der Standardausgabe sich leichter mit den Standardwerkzeugen von Docker sammeln und ansehen lassen.

Regelmäßig zu prüfen, welche Images und Tags im privaten Registry noch verwendet werden, hilft, die Übersicht zu behalten und Speicherplatz für alte, nicht mehr benötigte Image-Versionen freizugeben, die sich nach zahlreichen CI/CD-Deployments angesammelt haben.

9. Das Docker-Hub-Ökosystem und Community-Images als Ausgangspunkt

Dank der riesigen Zahl öffentlich verfügbarer offizieller Docker-Images (Datenbanken, Anwendungsserver, Hilfstools) kannst du die meisten typischen Dienste auf Saplo bereitstellen, ohne ein eigenes Dockerfile von Grund auf zu schreiben. Dafür stehen dir bereits bewährte, aktiv gepflegte Images zur Verfügung.

Der Anwendungskatalog von Saplo enthält fertige Rezepte auf Basis vieler offizieller Images, z. B. prestashop/prestashop, n8nio/n8n und flowiseai/flowise. Du musst nicht einmal wissen, dass die jeweilige Anwendung in Docker läuft, denn die gesamte Konfiguration ist bereits vorbereitet.

Für eigene, nicht standardisierte Anforderungen (Anwendungstyp custom) kannst du das gesamte Docker Hub-Ökosystem und andere öffentliche Image-Registries nutzen. Fertige Images dienen als Ausgangspunkt und lassen sich mit einem eigenen Dockerfile auf Basis des Ausgangs-Images an deine Anforderungen anpassen.

Das private Docker Registry im App-Katalog von Saplo ergänzt dieses Ökosystem und bietet Platz für eigene, gebaute Images, ohne dass diese öffentlich auf Docker Hub veröffentlicht werden müssen. Bei kommerziellen, geschlossenen Projekten ist das oft eine wichtige Sicherheitsanforderung.

Für technische Teams, die die Entwicklung des Container-Ökosystems verfolgen (neue Orchestrierungswerkzeuge, neue Best Practices für den Image-Build), bietet der volle SSH-Zugriff auf den LXC-Container mit Docker-Unterstützung auf Saplo dieselben Möglichkeiten wie ein klassischer, selbst verwalteter Server mit Docker.

10. Docker-Images vor dem Produktionseinsatz testen

Ein neues Docker-Image solltest du lokal oder in einem temporären Container auf demselben Box testen, bevor es den laufenden Produktionscontainer ersetzt. Ein Fehler im neuen Image (z. B. eine inkompatible Abhängigkeitsversion) kann sonst zu einem Ausfall des Service führen, bis die Änderung zurückgerollt wird.

Wenn du Images im privaten Registry mit einer Version statt nur mit latest tagst, kannst du problemlos zur vorherigen funktionierenden Image-Version zurückkehren, falls die neue Version nach dem Deployment im Produktionscontainer Probleme verursacht.

Bei Multi-Container-Apps (docker-compose mit Datenbank, App und Worker) solltest du die gesamte Änderung als Komplettpaket testen, nicht nur den einzelnen geänderten Container. Versionsunterschiede zwischen den verbundenen Containern sind häufig eine Ursache für Probleme, die beim Testen eines einzelnen Elements in Isolation nicht sichtbar werden.

Ein im Image konfigurierter Healthcheck erkennt automatisch, ob der neue Container nach dem Deployment ordnungsgemäß funktioniert. In Kombination mit einem einfachen Rollback-Skript auf den vorherigen Image-Tag lässt sich eine problematische Änderung schnell zurücknehmen, ohne dass der Service lange ausfällt. Ein so einfacher Test- und Rollback-Mechanismus ist zwar kein vollständiges CI/CD-System, reduziert aber bereits das Risiko eines längeren Ausfalls durch ein einzelnes, schlecht getestetes Deployment.

11. Zusammenfassung: Docker als Standard, keine Premiumfunktion

Dass Docker auf jedem Box als Standardkomponente und nicht als exklusive Funktion der teuersten Pläne gilt, spiegelt wider, wie verbreitet diese Art der App-Bereitstellung in den vergangenen Jahren geworden ist. Unabhängig davon, ob du ein fertiges Rezept aus dem Katalog auswählst oder dein eigenes, nicht standardmäßiges Image über den App-Typ custom bereitstellst: Die Container-Engine ist auf deinem Box bereits vom ersten Tag an konfiguriert und einsatzbereit. Für technische Teams, die Docker auf eigenen Entwicklungsmaschinen gewohnt sind, bedeutet der Wechsel zu Saplo daher keine Umstellung, sondern lediglich die Übertragung desselben bekannten Arbeitsablaufs in eine Produktionsumgebung mit integrierter Domain- und SSL-Unterstützung.