So betreibst du Docker auf einem VPS mit Portainer (Leitfaden 2026)

Hast du schon mal von Dockerception gehört?

Dann halt dich gut fest. Wir begeben uns in den Kaninchenbau.

Portainer, die Web-UI, die du gleich auf Docker installierst, ist selbst ein Docker-Container.

Es ist ein Tool, das auf genau dem läuft, was es verwaltet. Du startest es mit einer einzigen docker run-Zeile, und als Erstes greift es durch ein kleines Loch im Host (eine Socket-Datei) zurück und bittet den Docker-Daemon, ihm jeden Container auf der Maschine zu zeigen – sich selbst eingeschlossen. Aus diesem Browser-Tab heraus verwaltest du alle deine anderen Docker-Container.

Die UI, auf die du gerade schaust, taucht in ihrer eigenen Container-Liste auf.

Auf einem VPS, für den du ohnehin schon bezahlst und mit dem du per SSH vertraut bist, fügt sich Portainer sauber über Docker ein, ohne etwas daran zu ändern, wie die Dinge darunter funktionieren.

Genau das ist der Mehrwert.

Eine Maschine mit 4 GB kann ein Einstieg für Docker und Portainer sein, aber die Anwendungen, die du hinzufügst, entscheiden, ob diese Kapazität reicht. Denk an Hausautomatisierung, das Familienfotoarchiv, den KI-Assistenten und den Newsletter, den du schon so lange starten willst – alles auf einem Server, der wirklich dir gehört.

So bringst du alles zum Laufen, sicherst es ab und profitierst schnell davon.

Was genau ist Portainer?

Portainer ist eine Web-UI, die als Docker-Container läuft und deine anderen Container über den Docker-Socket verwaltet.

Im Grunde ist es ein browserbasiertes Frontend (eine Docker-GUI) für dieselben Docker-Befehle, die du sonst von Hand eintippen würdest, plus Stack-Verwaltung, rollenbasierte Zugriffe (wenn du auf die Business Edition upgradest) und eine Dashboard-Ansicht von CPU und Arbeitsspeicher.

Die Socket-Verbindung ist das, was alles zum Laufen bringt. Die Bindung sieht im Installationsbefehl so aus: -v /var/run/docker.sock:/var/run/docker.sock, und diese eine Zeile erledigt die ganze Schwerstarbeit. Ohne sie ist Portainer eine UI für einen leeren Docker-Host. Mit ihr ist Portainer die Fernbedienung des Docker-Hosts.

Eins solltest du im Hinterkopf behalten: Jeder Prozess, der /var/run/docker.sock erreichen kann, kann den Docker-Daemon steuern, und die Sicherheitsdokumentation von Docker sagt unmissverständlich, dass nur vertrauenswürdige Nutzer das dürfen sollten: Ein über den Daemon gestarteter Container kann das gesamte Dateisystem des Hosts einbinden und uneingeschränkt verändern. Das ist ein Feature, wenn Portainer anfragt, und ein Problem, wenn es irgendein Container ist, den du letzte Woche gestartet und dem du Socket-Zugriff gegeben hast, ohne noch daran zu denken.

Behandle die Socket-Bindung als privilegierte Berechtigung und prüfe jeden anderen Container, der eine haben will.

Brauchst du Portainer, wenn du schon Docker hast?

Nein. Docker funktioniert im Terminal einwandfrei, und viele Leute betreiben jahrelang ein paar Container, ohne jemals eine UI darüber zu installieren.

Portainer lohnt sich in diesen Fällen:

• Du jonglierst mehr als zwei oder drei Docker-Container für verschiedene Apps.
• Du klickst um 23 Uhr lieber auf restart, als einen Compose-Befehl neu einzutippen.
• Du teilst den Zugang mit jemandem, der sich im Terminal nicht zu Hause fühlt.
• Du willst Stack-Updates aus einem Git-Repo deployen, ohne ein Deploy-Skript zu schreiben.

Verzichte in diesen Fällen auf Portainer:

• Du betreibst ein oder zwei Container, die sich selten ändern.
• Du kommst mit Docker Compose bereits gut zurecht und willst dabei bleiben.

Docker selbst ist so verbreitet, dass das keine Randentscheidung ist. In der Stack Overflow Developer Survey 2025 gaben 71 % der Befragten an, Docker zu nutzen – das Spitzenergebnis unter den Technologien für Cloud-Entwicklung und Infrastruktur, nach einem Sprung um 17 Prozentpunkte gegenüber 2024. Das Portainer-Projekt hat Stand August 2026 mehr als 38.000 Sterne auf GitHub.

Es gibt auch Alternativen. Dokploy zum Beispiel geht stärker in Richtung einer vollständigen selbstgehosteten PaaS und kümmert sich für dich um Apps, Datenbanken und SSL. Portainer bleibt näher an reinem Docker: dieselben Compose-Dateien, dieselben Images, nur mit einer UI obendrauf.

Wenn du in tmux zu Hause bist und eine einzige App betreibst, kannst du diesen Tab schließen. Bei dir ist alles gut. Wenn du vier selbstgehostete Apps betreibst und diesen Monat schon zweimal „Wie war das noch mal mit Docker-Logs?“ gegoogelt hast, lies weiter.

Wie groß muss dein VPS für Docker und Portainer sein?

Portainer nennt keine RAM-Mindestanforderung. Ein VPS mit 4 GB kann für einen kleinen Stack reichen, aber dimensioniere ihn nach den kombinierten Anforderungen von Betriebssystem, Docker-Daemon und jedem Container, den du betreiben willst.

Die Anforderungsseite von Portainer sagt erstaunlich wenig über RAM: Der Server wird als schlanker Container ausgeliefert, und die in der Dokumentation genannten Performance-Hinweise betreffen den Speicherplatz (mehr dazu unten). Die echte RAM-Rechnung bestimmen deine Workloads – plane für das Betriebssystem, den Docker-Daemon und jeden Container, den du betreiben willst. Plane auch Speicherplatz für Logs ein: Der standardmäßige json-file-Logtreiber von Docker rotiert keine Logs, sodass die Logs eines gesprächigen Containers mit der Zeit erheblich viel Speicherplatz fressen können. Die Logging-Dokumentation von Docker empfiehlt stattdessen den local-Treiber. Sobald Docker installiert ist (Schritt 2 unten), erstelle das Konfigurationsverzeichnis von Docker, setze den local-Logtreiber und starte Docker dann neu: Führe sudo install -d -m 0755 /etc/docker aus, dann printf '%s\n' '{ "log-driver": "local" }' | sudo tee /etc/docker/daemon.json > /dev/null, dann sudo systemctl restart docker. Erledige das, bevor du langlaufende Apps deployst: Der local-Treiber rotiert Logs standardmäßig, und die Änderung gilt nur für Container, die danach erstellt werden.

So sieht das bei echten Workloads aus:

Das Arbeitsblatt ist einfache Addition: Schlag die dokumentierte RAM-Anforderung jeder App nach, die du betreiben willst, addiere Betriebssystem und Docker-Daemon und lass dann Reserven für Lastspitzen. Portainer selbst nennt keine RAM-Mindestanforderung, also sind es die Apps – nicht die UI –, die die Maschine füllen.

Bei DreamHost gibt es unser VPS Hosting in vier RAM-basierten Stack-Plänen (Stack 4, 8, 16 und 32). Der Einstiegsplan Stack 4 (2 vCPUs, 4 GB RAM, 75 GB NVMe SSD, voller Root-Zugriff) passt ideal zu einem kleinen Docker-Host. Bei monatlicher Abrechnung kostet er in den ersten 3 Monaten 8,99 $/Monat und verlängert sich danach automatisch zu 15,99 $/Monat (Stand August 2026; die gesamte Laufzeit plus Steuern wird beim Checkout berechnet – aktuelle Preise findest du immer auf der Seite für Docker + Portainer VPS).

Wenn du unsicher bist, ob es die Zeit wert ist, Dienste selbst zu hosten, ist Stack 4 die richtige Größe für den Einstieg: groß genug, um es herauszufinden, und klein genug, dass du nicht für Reserven bezahlst, die du nicht nutzt. Wenn dein Arbeitsblatt darüber hinauswächst, kannst du in einen größeren Plan wechseln, und deine Umgebung zieht mit – beachte aber, dass ein Wechsel zurück auf einen kleineren Stack derzeit nicht unterstützt wird. Fang also bewusst klein an.

Ein Hinweis zum Speicherplatz: Das Daten-Volume von Portainer enthält die eigene Datenbank und Konfiguration sowie einen Klon jedes Git-Repositorys, aus dem du Stacks deployst – die Dokumentation von Portainer warnt, dass große oder mehrere Repos erheblich Speicherplatz belegen können. Die Performance-Hinweise in der Dokumentation beziehen sich auf den Speicher, nicht auf den Arbeitsspeicher: SSD-Niveau (≈3,5 MB/s, 30.000 IOPS oder mehr, unter 10 ms Schreiblatenz) bezeichnet sie als ideal. Stack 4 enthält 75 GB NVMe-SSD-Speicher.

Wie installierst du Docker und Portainer auf einem VPS?

Es sind sieben Schritte. Die Dauer für Download und Installation hängt von deinem VPS und deiner Netzwerkverbindung ab. Die Befehle in den Schritten 2 bis 6 sind für Ubuntu geschrieben und lassen sich auf einem frischen Server der Reihe nach einfügen; die eine Stelle, an der ein Befehl einen Wert braucht, den nur du kennst (deine eigene IP-Adresse, in Schritt 4), ist im jeweiligen Schritt gekennzeichnet. (Du willst die ganze Liste überspringen? Die App-Bibliothek von DreamHost VPS Hosting enthält ein Docker + Portainer-Image, bei dem beides vorkonfiguriert ist.)

1. Linux-Distribution wählen

Diese Anleitung verwendet Ubuntu 24.04 LTS. Docker Engine unterstützt Ubuntu 22.04, 24.04 und 26.04 LTS (Stand August 2026). Ubuntu ist eines der vorinstallierten Betriebssysteme bei DreamHost VPS Hosting.

Debian und Distributionen der RHEL-Familie wie AlmaLinux funktionieren ebenfalls, haben in der Dokumentation von Docker aber eigene Installationswege, und die Befehle unten lassen sich nicht eins zu eins übertragen. Bei der RHEL-Familie kommt noch eine Besonderheit hinzu: Die Installationsanleitung von Portainer geht davon aus, dass SELinux deaktiviert ist, und empfiehlt, Docker beim Deployment von Portainer --privileged zu übergeben, wenn du SELinux aktiviert lassen musst. Wenn dir dieser Satz nichts gesagt hat, nimm Ubuntu.

Du weißt nicht genau, welche Ubuntu-Version du nutzt? Hier erfährst du fünf Wege, das zu prüfen.

2. Docker aus dem offiziellen Repository installieren

Führe kein apt install docker.io aus und installiere Docker auch nicht über Snap – die offizielle Installationsanleitung von Docker führt docker.io unter den inoffiziellen Paketen auf, die du vor der Installation von Docker Engine deinstallieren solltest, und die Installationsanleitung von Portainer warnt, dass das Snap-Paket Kompatibilitätsprobleme verursachen kann.

Entferne zuerst alle Pakete, die Konflikte verursachen könnten. Das ist der Entfernungsbefehl aus der aktuellen Installationsanleitung von Docker, und auf einem frischen Server findet er meist nichts zu entfernen – die Anleitung weist darauf hin, dass apt möglicherweise meldet, dass keines dieser Pakete installiert ist:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc | cut -f1)

Füge als Nächstes den GPG-Schlüssel von Docker hinzu (jede Zeile unten ist ein eigener Befehl):

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Füge dann das apt-Repository von Docker hinzu. Damit wird die Repository-Definition in /etc/apt/sources.list.d/docker.sources geschrieben – die Datei, die auch die Installationsanleitung von Docker verwendet –, wobei deine Ubuntu-Version und CPU-Architektur automatisch eingetragen werden:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update

Installiere zum Schluss Docker Engine und das Compose-Plugin in einem Rutsch:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3. Prüfen, ob Docker läuft

Führe sudo docker run hello-world aus.

Wenn du die Meldung Hello from Docker! nicht erhältst, bring zuerst den Daemon in Ordnung, bevor du Portainer darauf aufsetzt.

4. UFW mit Docker verbinden, bevor du Portainer startest

Jetzt kommt der Teil, den die meisten Anleitungen ans Ende packen, wo es schon zu spät ist: Wenn Docker einen Port veröffentlicht, wird der Traffic dorthin umgeleitet, bevor er die Chains erreicht, die UFW filtert. Ein veröffentlichter Port ist also aus dem öffentlichen Internet erreichbar, selbst wenn UFW ihn als gesperrt anzeigt. (Die ausführliche Erklärung findest du weiter unten.) Sobald du Portainer startest, ist sein Port 9443 öffentlich – und zwar genau während des fünfminütigen Zeitfensters, in dem jeder, der ihn zuerst erreicht, das Admin-Konto anlegen kann. Bring also zuerst die Firewall in Ordnung.

Falls UFW noch nicht aktiv ist, erlaube SSH und aktiviere UFW. (Wenn dein SSH auf einem eigenen Port läuft, erlaube diesen statt Port 22 – sonst sperrst du dich genau bei diesem Schritt aus.)

sudo ufw allow 22/tcp
sudo ufw enable

Installiere dann chaifeng/ufw-docker, ein Drittanbieter-Tool, das die nötigen Regeln an /etc/ufw/after.rules anhängt, damit Traffic zu den veröffentlichten Ports von Docker über die DOCKER-USER-Chain gefiltert wird. Die Befehle unten legen sich auf das Release 251123 des Projekts (November 2025) fest, statt vom sich ständig ändernden master-Branch zu laden, und sie nutzen curl, das du bereits in Schritt 2 installiert hast:

sudo curl -fsSL -o /usr/local/bin/ufw-docker \
  https://github.com/chaifeng/ufw-docker/raw/251123/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
sudo ufw-docker install
sudo ufw reload

Nach dem Reload werden veröffentlichte Container-Ports über UFW gefiltert. Wenn deine Richtlinie für gerouteten Traffic eingehende Verbindungen ablehnt und keine bestehende Regel den Port erlaubt, bleiben öffentliche Verbindungen blockiert, bis du sie ausdrücklich erlaubst. (Das ufw-docker-Projekt weist darauf hin: Wenn die Regeln nach einem UFW-Neustart nicht greifen, hilft ein Neustart des Servers.)

Genehmige jetzt vorab deinen eigenen Zugriff auf die Portainer-UI. Ersetze YOUR_HOME_IP durch die öffentliche IP, von der aus du surfen wirst:

sudo ufw route allow proto tcp from YOUR_HOME_IP to any port 9443

Wenn diese Regel schon greift, bevor Portainer startet, ist IPv4-Traffic zur UI nur von deiner IP erlaubt und von keiner anderen – auch während des Zeitfensters für den ersten Admin. Die Regel in dieser Form deckt nur IPv4 ab. Laut der Doku von ufw-docker unterstützt das Tool auch IPv6-Netzwerke und aktualisiert bei Bedarf /etc/ufw/after6.rules, aber verlass dich nicht blind darauf: Wenn dein VPS auf einer öffentlichen IPv6-Adresse antwortet, führe den Test von außen aus dem Firewall-Abschnitt auch über IPv6 durch, bevor du dich darauf verlässt. Der Haken: Die meisten privaten Internetanschlüsse wechseln gelegentlich ihre IP, daher musst du die Regel eventuell später anpassen. Wenn dich das nervt, ist ein VPN vor der UI langfristig die sauberere Lösung (mehr dazu im Abschnitt zur Absicherung).

5. Persistentes Volume für die Daten von Portainer erstellen

Führe als Nächstes sudo docker volume create portainer_data aus.

Da die Datenbank von Portainer auf einem Docker-Volume liegt (nicht im Container), löscht ein Portainer-Upgrade deine Konfiguration nicht.

6. Portainer Community Edition ausführen

Das ist der Befehl aus der Linux-Installationsanleitung von Portainer, nur ohne ein Flag: Die offizielle Version veröffentlicht zusätzlich Port 8000, einen TCP-Tunnel, der nur nötig ist, wenn du später Remote-Umgebungen über Edge Agents anbindest. Eine Installation auf einem einzelnen Host braucht ihn nicht, also lassen wir ihn weg:

sudo docker run -d \
  -p 9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

Gehen wir das Zeile für Zeile durch:

• -d startet den Container im Hintergrund (detached).
• -p 9443:9443 ist die Web-UI von Portainer über HTTPS – der Port, den du in Schritt 4 für deine IP freigegeben hast.
• --restart=always startet Portainer nach einem Neustart automatisch wieder.
• Die -v-Flags stehen für die Socket-Einbindung und das persistente Volume aus Schritt 5.
• :lts legt dich auf die Long-Term-Support-Release-Linie von Portainer fest – genau den Tag, den auch die Installationsanleitung von Portainer verwendet.

7. UI öffnen und Admin-Konto erstellen

Öffne in deinem Browser https://YOUR_VPS_IP:9443 (von der IP-Adresse aus, die du in Schritt 4 freigegeben hast).

Klick dich durch die Warnung zum selbstsignierten Zertifikat. Du landest auf dem Bildschirm create the initial administrator user. Wähle einen Benutzernamen, der nicht admin lautet, setze ein starkes Passwort und speichere es an einem sicheren Ort. Und … du bist drin!

Warum hat Portainer gerade ein Timeout?

Weil Portainer bei der Erstinstallation genau fünf Minuten wartet, bis jemand die Instanz für sich beansprucht. Passiert das nicht, macht es die Tür zu.

Wörtlich aus den FAQ von Portainer:

As a security precaution, when Portainer is first installed it will wait for 5 minutes for an administrator user to be created (part of the initial setup). If a user is not created within those 5 minutes, the Portainer Server will stop listening for requests.

Im Klartext: Wenn du Schritt 6 genutzt hast, um dir ein Sandwich zu machen, verweigert deine Installation jetzt das Gespräch – und du hast nichts falsch gemacht.

Die Lösung ist einfach. Führe sudo docker restart portainer aus.

Damit startet der Container neu, du bekommst ein weiteres Fünf-Minuten-Fenster und landest direkt auf dem Bildschirm zum Anlegen des Admins. Bei Bedarf wiederholen. Willkommen beim Selbsthosten.

Wenn du die Installation für eine ganze Flotte skriptest (Ansible, Terraform, eine Deploy-Pipeline), akzeptiert Portainer das Flag --admin-password-file, das den Admin-Benutzer beim ersten Start des Containers aus einer Datei anlegt – so musst du nicht gegen die Uhr zum Admin-Bildschirm rennen. Die Syntax findest du in der Doku zur CLI-Konfiguration von Portainer. Für eine einmalige VPS-Installation reicht der Neustart-Trick völlig.

Wie verhinderst du, dass Docker deine Firewall umgeht?

Das hast du schon erledigt, in Schritt 4. Hier erfährst du, was dabei eigentlich passiert ist, wie du Ports gezielt öffnest und wie du nachweist, dass es funktioniert.

Das Problem: Wenn du den Port eines Containers mit -p 80:80 veröffentlichst, ist dieser Port aus dem öffentlichen Internet erreichbar, selbst wenn ufw status Port 80 als gesperrt anzeigt. In der Dokumentation zur Paketfilterung von Docker heißt es: Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses.

UFW ist nicht kaputt. Es steht nur im falschen Flur.

Die Lösung, auf die Docker selbst verweist, ist die DOCKER-USER-iptables-Chain – eine Chain, die Docker speziell für benutzerdefinierte Regeln anlegt und die vor den Regeln in den Docker-eigenen Chains verarbeitet wird. Das Skript ufw-docker, das du in Schritt 4 installiert hast, bindet UFW in diese Chain ein, indem es einen Regelblock (zwischen den Markierungen # BEGIN UFW AND DOCKER und # END UFW AND DOCKER) an /etc/ufw/after.rules anhängt, sodass er zusammen mit dem Rest deiner UFW-Konfiguration geladen wird.

Um einen Container-Port gezielt öffentlich zu machen – etwa für eine Web-App auf Container-Port 80 –, nutzt du eine Route-Regel:

sudo ufw route allow proto tcp from any to any port 80

Eine Falle, auf die die Doku von ufw-docker hinweist: Die Regel erwartet den Container-Port, nicht den Host-Port. Wenn du mit -p 8080:80 veröffentlicht hast, ist die Regel oben (Port 80) die richtige, nicht Port 8080.

Zum Prüfen von außen testest du aus einem Netzwerk, das nicht auf deiner Allowlist steht – ein Handy-Hotspot funktioniert. Das sollte in einen Timeout laufen, statt die Login-Seite von Portainer zurückzugeben:

curl -k --max-time 5 https://YOUR_VPS_IP:9443

# For IPv6, enclose the address in square brackets:
curl -k --max-time 5 'https://[YOUR_VPS_IPV6]:9443'

Führe denselben Befehl von der IP aus, die du in Schritt 4 freigegeben hast, dann solltest du HTML zurückbekommen. Wenn UFW denied meldet, ist das eine Behauptung; ein Timeout aus einem fremden Netzwerk ist ein Beweis.

Um alles rückgängig zu machen, führe sudo ufw-docker uninstall aus – laut Projektdoku stellt das deine UFW-Konfiguration wieder her und löscht die installierten Dateien – und danach sudo ufw reload. Du kannst auch den Block zwischen den Markierungen # BEGIN UFW AND DOCKER und # END UFW AND DOCKER in /etc/ufw/after.rules von Hand entfernen und UFW neu laden.

Das erwischt erfahrene Engineers auf privaten Servern genauso wie auf Produktionsservern: UFW sagt das eine, das öffentliche Internet das andere, und die Wahrheit steckt in iptables. Wenn Portainer gar keinen öffentlichen Port haben soll, schalte einen VPN-Tunnel davor, etwa WireGuard.

Was solltest du direkt nach dem ersten Login absichern?

Du bist drin. Fünf Dinge, die du erledigen solltest, bevor du den Browser-Tab schließt – die ersten vier stammen direkt aus dem Sicherheitsleitfaden von Portainer:

• Aktiviere Force HTTPS only. Die Installation in dieser Anleitung veröffentlicht nur Port 9443, es ist also von vornherein kein HTTP-Port offen. Mit dem Schalter Force HTTPS only unter Settings → SSL Certificate machst du das dauerhaft: Laut der Doku zu den Einstellungen von Portainer deaktiviert er das Lauschen auf dem alten HTTP-Port (9000) komplett, sodass ein späteres Redeployment mit -p 9000:9000 keinen unverschlüsselten Zugang wieder öffnen kann.
• Ersetze das selbstsignierte Zertifikat. Lade ein selbst erstelltes Zertifikat hoch oder schalte Portainer einen NGINX-Reverse-Proxy mit einem Zertifikat von Let’s Encrypt vor. Nach dem ersten Tag jedes Mal die Browserwarnung wegzuklicken, ist eine Gewohnheit, die du bereuen wirst.
• Verwende einen echten Admin-Benutzernamen. Mit dem Standard-Benutzernamen admin muss ein Angreifer eine Zugangsangabe weniger herausfinden. Wähle etwas, das zu dir passt.
• Beschränke die UI auf ein VPN. Portainer hinter einem WireGuard-VPN zu betreiben, ist das Muster, das der Sicherheitsleitfaden von Portainer empfiehlt. Port 9443, beschränkt auf deine Quell-IP (Schritt 4), ist gut. Port 9443, der nur in einem privaten Netzwerk erreichbar ist, ist besser.
• Prüfe die Einbindung des Docker-Sockets. Alles, was Zugriff auf /var/run/docker.sock hat, steuert den Docker-Daemon und darüber den Host. Binde den Socket nicht leichtfertig in andere Container ein. Jede zusätzliche Einbindung ist ein neuer Weg zum Host. Wenn ein Container angeblich den Socket braucht, frag nach dem Warum – und zieh einen Socket-Proxy in Betracht, wenn die Antwort lautet: zum Monitoring.

Wie nutzt du Portainer im Alltag?

Der Gewinn durch Portainer zeigt sich an dem Tag, an dem du dich nicht mehr per SSH einloggst, um einen streikenden Container neu zu starten, sondern einfach auf einen Button klickst. Der noch größere Gewinn ist die Verwaltung von Stacks.

Ein Portainer-Stack ist eine Multi-Container-App, die durch eine Docker-Compose-Datei definiert wird. Portainer kann unterstützte Docker-Compose-Konfigurationen auf vier Wegen als Stacks deployen, die in der offiziellen Stacks-Doku aufgeführt sind:

• Compose in den Web-Editor einfügen
• Compose-Datei hochladen
• Portainer auf ein Git-Repository verweisen
• Aus einer eigenen Vorlage deployen

Entscheidend ist der Git-Weg. Du verweist Portainer auf ein öffentliches oder authentifiziertes Repo und einen Pfad zu docker-compose.yml und aktivierst dann GitOps-Updates. Portainer fragt das Repo entweder in einem von dir festgelegten Intervall ab oder gibt dir eine Webhook-URL, die du bei deinem Git-Host hinterlegst (und die zum Beispiel von einer GitHub Action ausgelöst wird). Ändert sich die Compose-Datei im Repo, holt Portainer die Änderungen und deployt automatisch neu. Und ja, das funktioniert auch in der Community Edition – auf der Seite der Stacks-Doku trägt nur die Option für Volumes mit relativen Pfaden die Kennzeichnung Business Edition.

Das ist die selbstgehostete Version von Deploy on Push, ohne dass du einen PaaS-Anbieter dafür bezahlst.

Auch die kleinen täglichen Vorteile summieren sich. Denk an Logs in einer übersichtlichen Ansicht, statt ihnen über die Kommandozeile zu folgen, an Neustarts mit einem Klick, an das Neuaufbauen eines Stacks per Button und an Ressourcengrafiken, die du in drei Sekunden überblickst, statt Docker stats auszuführen.

Wenn du später Remote-Hosts über Edge Agents hinzufügst, wird Port 8000 wieder relevant – die FAQ unten erklären das Redeployment und die Firewall-Regel.

Wie sicherst du Portainer und deine Container?

Ein Volume sorgt für Persistenz, ist aber kein Backup. Das Volume portainer_data aus Schritt 5 übersteht Container-Upgrades, liegt aber auf derselben Festplatte wie alles andere – ein echter Backup-Plan besteht deshalb aus drei Teilen, und alle drei verlassen den VPS.

1. Die Konfiguration von Portainer. Gehe in der UI zu Settings → Back up Portainer, behalte die Standardoption Download backup file bei und klicke auf Download backup. Laut der Doku zu den Einstellungen von Portainer lädt das ein tar.gz-Archiv mit allem herunter, was Portainer auf seinem /data-Volume speichert, optional mit Passwort verschlüsselt – und mehr brauchst du nicht, um Portainer wiederherzustellen. Ebenso klar ist die Doku beim Umfang: Gesichert wird nur die Konfiguration von Portainer, nicht die Container, Stacks oder Volumes, die du deployt hast. (Geplante Backups nach S3 gibt es, aber nur in der Business Edition – in der CE trägst du dir besser eine wiederkehrende Erinnerung in den Kalender ein.)

2. Deine Anwendungsdaten. Die Volume-Dokumentation von Docker nennt benannte Volumes den bevorzugten Weg, Container-Daten persistent zu speichern – und sie lassen sich leichter sichern oder migrieren als Bind Mounts. Ein schreibgeschützter Mount hindert nur den Backup-Container am Schreiben – die App selbst kann während der Archivierung weiter ins Volume schreiben und dir eine inkonsistente Kopie liefern. Stoppe daher zuerst den Container der App (sudo docker stop myapp) oder nutze den unterstützten Backup-Mechanismus der App. Binde das Volume dann schreibgeschützt in einen Wegwerf-Container ein, pack es mit tar zusammen und starte die App danach wieder (setze deine eigenen Namen ein):

sudo docker run --rm \
  -v myapp_data:/source:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/myapp_data.tgz -C /source .

Bei Datenbanken solltest du statt laufender Datendateien lieber das Dump-Tool der Datenbank verwenden (pg_dump, mysqldump), damit du keine Datei archivierst, in die gerade geschrieben wird. Bring die Archive dann regelmäßig vom Server weg – per rsync oder scp auf einen anderen Rechner oder in einen Object Storage. Ein Backup auf derselben Festplatte, die es sichert, verschwindet zusammen mit dieser Festplatte.

3. Deine Compose-Dateien und Secrets. Wenn du Stacks aus Git deployst, liegen die Compose-Dateien bereits außerhalb des Hosts. Was Git nicht enthält, ist alles, was du nie committet hast: .env-Dateien, API-Schlüssel und Passwörter, die du beim Deployment angegeben hast. Auch per Bind Mount eingebundene Verzeichnisse liegen außerhalb des oben beschriebenen Volume-Backups. Erfasse diese separat und sichere sie verschlüsselt.

Teste dann die Wiederherstellung, bevor du sie brauchst. Laut der Doku von Portainer funktioniert eine Wiederherstellung der Konfiguration nur auf einer frischen Instanz: Deploye einen neuen Portainer-Container mit leerem Daten-Volume (ein Wegwerf-VPS oder dein Laptop reicht), wähle bei der Ersteinrichtung Restore Portainer from backup und prüfe, ob du dich mit deinen alten Zugangsdaten anmelden kannst und deine Stack-Definitionen siehst. Diese Übung deckt nur Teil 1 ab – die Konfiguration von Portainer. Teil 2 und 3 brauchen einen eigenen Test pro App: Stelle ein Archiv in einem frischen Volume wieder her, starte die App damit und prüfe, ob die Daten wirklich da sind. Ein ungetestetes Backup ist nur eine Hoffnung mit Dateinamen.

Was kostet Portainer? (Und wann ist kostenlos nicht mehr kostenlos?)

Portainer ist gleich doppelt kostenlos. Die Community Edition ist kostenlos und Open Source (zlib-Lizenz), ganz ohne Lizenzschlüssel. Und die Portainer Business Edition ist für bis zu 3 Nodes dauerhaft kostenlos: alle Business-Funktionen, ohne Zeitlimit, ohne Kreditkarte. Statt zu bezahlen, registrierst du dich für einen kostenlosen Lizenzschlüssel.

Preise laut der Preisseite von Portainer, Stand August 2026; Starter und Scale erfordern eine jährliche Bindung.

Welche Edition solltest du also wählen? Für ein einzelnes VPS mit nur einem Admin: Community Edition. Sie ist Open Source, braucht keine Registrierung und kann alles, was in diesem Guide vorkommt, Git-Deployments inklusive. Wenn du rollenbasierte Zugriffskontrolle (RBAC) für einen zweiten Nutzer brauchst oder schon zwei oder drei Server betreibst, nimm stattdessen die kostenlose Business-Stufe für 3 Nodes. Das ist dieselbe Software mit freigeschalteten Business-Funktionen und bleibt kostenlos, solange du bei höchstens drei Nodes bleibst. Die kostenpflichtigen Pläne lohnen sich erst, wenn du im Team eine nennenswerte Zahl an Nodes verwaltest. Prüf außerdem den Support-Umfang, bevor du davon ausgehst, dass bezahlt automatisch betreut heißt: Laut der Preisseite von Portainer (Stand August 2026) gibt es beim Starter-Plan Community-Support, ab dem Scale-Plan Support zu Geschäftszeiten (9×5) mit Antwort am nächsten Werktag und bei Enterprise priorisierten Support.

Solltest du Portainer hinzufügen oder darauf verzichten?

Hier die ehrliche Antwort in zwei Sätzen:

✅ Wenn du diesen Server teilen, aus Git deployen oder in einem Jahr mehr als drei Container betreiben willst, installiere Portainer jetzt, solange der Host noch frisch ist und sich deine Gewohnheiten erst darum herum bilden.

❌ Wenn du eine einzige ruhige App betreibst und im Terminal glücklich bist, wirst du die UI, die du nie installiert hast, auch nicht vermissen.

Die eigentliche Frage lautet nicht „Portainer oder kein Portainer“. Sondern ob Selbsthosting überhaupt die richtige Wahl für dich ist – und die hast du beantwortet, als du diesen Tab geöffnet hast.

Ein VPS mit 4 GB, Docker und Portainer CE reichen aus, um ernsthaft mit dem Selbsthosten loszulegen: Wähl deine Apps aus, addiere ihre dokumentierten Anforderungen und lass die Rechnung – nicht die Wunschliste – entscheiden, wann der Server wachsen muss.

Kein schlechter Deal.

Häufig gestellte Fragen zu Docker und Portainer