Portainer Container updaten: Images per GUI aktualisieren – ohne CLI und ohne Datenverlust

Das ist der häufigste Stolperstein. Portainer lädt mit „Pull the latest image“ das neue Image herunter — aber der laufende Container bleibt unverändert. Er wurde aus dem alten Image gestartet und läuft weiter, bis du ihn explizit neu erstellst.

Nach dem Pull zwingend Recreate klicken, nicht Restart. Restart startet denselben Container neu — mit demselben alten Image. Recreate wirft den alten Container weg und erstellt einen neuen aus dem frisch gepullten Image.

Kurz-Check: Unter Containers → Image siehst du die Image-ID. Vergleiche sie mit der ID unter Images — stimmen sie überein, läuft der Container auf dem neuen Stand.

Restart entspricht einem Prozess-Neustart — das zugrundeliegende Image bleibt identisch. Nützlich, wenn ein Dienst hängt, aber kein Update nötig ist.

Recreate löscht den Container und erstellt ihn neu — mit dem zuletzt gepullten Image. Alle Konfigurationsdetails (Ports, Umgebungsvariablen, Volume-Mounts) werden dabei aus der gespeicherten Container-Konfiguration übernommen, sofern du „Re-use volumes“ aktivierst.

Faustregel: Für Updates immer Recreate. Für „Dienst reagiert nicht mehr“ reicht Restart.

Nein — sofern deine Volumes korrekt gemountet sind. Volumes leben außerhalb des Containers und bleiben beim Recreate erhalten, solange du „Re-use volumes“ im Recreate-Dialog aktiviert lässt (Standard: aktiviert).

Was verloren gehen kann: Daten, die direkt im Container-Dateisystem gespeichert wurden — also ohne Volume-Mount. Das ist ein Konfigurationsfehler, kein Update-Problem. Vor jedem Update lohnt ein kurzer Blick in die Volume-Liste des Containers.

Passiert fast immer beim latest-Tag. Portainer vergleicht nur den lokalen Image-Hash mit dem zuletzt gepullten Stand. Hast du das Image vor Wochen gepullt, gilt es lokal als „aktuell“ — auch wenn inzwischen eine neuere Version veröffentlicht wurde.

Lösung: Unter Images das betroffene Image manuell löschen, dann erneut pullen. Oder direkt im Container-Detail auf „Pull the latest image“ klicken und anschließend den lokalen Image-Cache unter Images → Unused bereinigen.

Langfristige Lösung: Explizite Versions-Tags statt latest verwenden, z. B. nginx:1.27.0.

1. Container-Detail öffnen → Volume-Mounts prüfen (müssen vorhanden sein)
2. „Pull the latest image“ klicken
3. Recreate klicken, „Re-use volumes“ aktiviert lassen
4. Nach dem Start: Logs prüfen, Version verifizieren

Sind keine Volumes eingetragen, erst Bind Mounts oder named Volumes konfigurieren — dann erst recreaten.

In Portainer CE gibt es keine eingebaute Auto-Update-Funktion für einzelne Container. Wer automatische Updates möchte, deployt Watchtower als eigenen Container — es prüft regelmäßig auf neue Images und führt Recreates selbstständig durch. Alternativ bietet die Portainer Business Edition erweiterte Webhook-Funktionen für CI/CD-Pipelines sowie automatische Image-Update-Benachrichtigungen.

Für einen typischen Heimserver reicht der manuelle Workflow alle paar Wochen vollkommen aus.

Einzelne Container lassen sich in Portainer CE nur nacheinander aktualisieren — ein Massen-Update per Checkbox gibt es nicht. Der effizientere Weg: Zusammengehörige Dienste in einem Stack zusammenfassen. Stacks lassen sich mit einem einzigen Klick auf „Pull and redeploy“ komplett aktualisieren — alle enthaltenen Images werden neu gepullt, alle Container neu erstellt.

Der Button ist ausgegraut, wenn der Stack in einem Fehlerzustand ist oder außerhalb von Portainer verändert wurde. Vorgehen:

1. Stack-Status in der Stack-Ansicht prüfen
2. Falls Stack fehlerhaft: Compose-File neu importieren und Stack neu deployen
3. Falls Stack außerhalb von Portainer verändert wurde: Stack löschen und neu anlegen — Portainer muss die Kontrolle zurückbekommen

Der Update-Workflow ist identisch zu x86-Systemen. Zu beachten: Nicht alle Images auf Docker Hub bieten ARM64-Builds an. Vor dem Pull prüfen, ob das Image auf Docker Hub unter „Tags“ eine linux/arm64-Variante listet. Multi-Arch-Images (erkennbar am manifest-Eintrag) funktionieren automatisch korrekt. Images ohne ARM64-Support schlagen beim Pull auf dem Raspberry Pi Angebot fehl — kein Fehler im Workflow, sondern ein fehlendes Build des Anbieters.

Der Portainer Update-Workflow (Pull → Recreate bzw. Stack → Pull and redeploy) ist plattformunabhängig identisch. Plattformspezifische Stolperfallen:

• Synology DSM 7: Portainer läuft als Container im Container Manager. Portainer selbst updaten erfordert einen separaten Schritt über den Container Manager.
• QNAP Container Station: Container Station hat eine eigene Update-UI — Portainer läuft dort als Container und hat keinen Zugriff auf Container-Station-native Features.
• Unraid: Portainer läuft als Community-App. Updates über Portainer selbst, nicht über das Unraid-App-System.
• TrueNAS Scale: Portainer läuft als App oder manuell installierter Container. Kubernetes-basierte Apps in TrueNAS Scale werden nicht über Portainer verwaltet.
• Proxmox LXC: Docker läuft im LXC-Container, Portainer verwaltet diese Docker-Instanz normal. Kein Unterschied im Update-Workflow.

Umgebungsvariablen, die direkt im Portainer-GUI eingetragen wurden, können beim Recreate verloren gehen, wenn der Container ursprünglich per CLI erstellt wurde. Fix: Umgebungsvariablen immer in einem Stack (Compose-File) definieren — dann bleiben sie beim „Pull and redeploy“ automatisch erhalten. Für bestehende Einzel-Container: Variablen vor dem Recreate in der Container-Konfiguration in Portainer eintragen und speichern.

1. Images → betroffenes Image suchen
2. Image löschen (nur möglich, wenn kein Container damit läuft — Container vorher stoppen)
3. Container-Detail → „Pull the latest image“ → Portainer muss jetzt von Docker Hub laden
4. Recreate ausführen

Alternativ: Expliziten Versions-Tag im Container-Image-Feld eintragen (z. B. von nginx:latest auf nginx:1.27.0 wechseln) — Portainer erkennt den Unterschied und lädt das neue Image.