Portainer vs Dockge: Welche Docker-Oberfläche passt zu dir? Im Test (2026)

Portainer vs Dockge ist die Frage, die fast jeder stellt, der seinen ersten Server mit ein paar Docker-Containern betreibt und keine Lust mehr hat, jedes Mal per SSH docker compose up -d zu tippen. Beide Werkzeuge sind Weboberflächen für Docker, beide sind kostenlos, beide laufen selbst als Container. Aber sie verfolgen zwei sehr unterschiedliche Ideen. Portainer will eine komplette Verwaltungszentrale für Container, Images, Volumes, Netzwerke, Benutzer und sogar Kubernetes sein. Dockge macht genau eine Sache: Docker-Compose-Stacks bearbeiten, starten, stoppen und aktualisieren.

Wir haben beide am 14. November 2026 auf unserem eigenen Server als Wegwerf-Container aufgesetzt und nebeneinander gemessen: Portainer CE 2.45.3 (Tag lts) und Dockge 1.5.0 (Tag 1), beide auf Docker 29.9.3 unter Ubuntu 24.04. Wir haben die Ersteinrichtung durchgespielt, mit beiden denselben nginx-Stack angelegt, nachgesehen, wo die Compose-Datei landet, den Speicher gemessen und beide Oberflächen danach wieder restlos entfernt. Vier Befunde vorweg:

1. Das Dockge-Image ist 1,17 GB groß, das Portainer-Image 201 MB. Im Leerlauf brauchte Dockge 152 MiB Arbeitsspeicher, Portainer 22 MiB. Das „leichtgewichtige“ Werkzeug ist auf der Platte und im RAM das schwerere.

2. Dockge legt jeden Stack als ganz normale compose.yaml in einem Ordner auf deinem Server ab. Portainer speichert sie in seinem eigenen Volume unter /data/compose/1/. Den Pfad, den Docker sich dazu merkt, gibt es auf dem Host gar nicht.

3. Portainer 2.45 lässt sich nicht mehr von jedem einrichten, der die Seite zuerst öffnet: Es verlangt ein Setup-Token aus den Container-Logs und sperrt sich nach fünf Minuten ohne Admin-Konto. Dockge hat beides nicht. Wer zuerst kommt, wird Admin.

4. Dockges letzte Version ist 1.5.0 vom 30. März 2025. Im Repository gab es seitdem nur noch wenige Commits. Portainer veröffentlichte allein zwischen September und Oktober 2026 vier Versionen.

Portainer vs Dockge: Was ist was?

Bevor wir messen, kurz die beiden Kandidaten. Beide sprechen mit Docker über dieselbe Schnittstelle, den Docker-Socket /var/run/docker.sock. Über diese Datei steuert jedes Werkzeug den Docker-Daemon, genau wie der docker-Befehl auf der Kommandozeile. Was beide daraus machen, ist aber grundverschieden.

Portainer gibt es seit 2016 und ist mit rund 38.800 GitHub-Sternen die bekannteste Docker-Oberfläche überhaupt. Es gibt eine kostenlose Community Edition (CE) unter Zlib-Lizenz und eine kostenpflichtige Business Edition mit Funktionen wie feinerer Rechteverwaltung und Support. Portainer zeigt dir alles, was Docker kennt: Container, Images, Volumes, Netzwerke, Secrets, Logs, Statistiken, eine Konsole in den Container hinein. Dazu kommen Benutzer und Teams, Vorlagen für fertige Anwendungen, Git-Anbindung für Stacks und die Verwaltung mehrerer Server über einen sogenannten Agent. Auch Docker Swarm und Kubernetes kann Portainer verwalten. Es ist ein Werkzeug für alles.

Dockge stammt von Louis Lam, dem Entwickler von Uptime Kuma, und erschien Ende 2023. Es hat rund 24.800 Sterne und steht unter MIT-Lizenz. Dockge ist bewusst klein: Es kennt im Kern nur Stacks, also Docker-Compose-Projekte. Du siehst eine Liste deiner Stacks, klickst einen an und bekommst links einen YAML-Editor und rechts die Live-Ausgabe von docker compose. Knöpfe für Start, Stop, Neustart und Update, ein Terminal in die Container, fertig. Images, Volumes und Netzwerke einzeln verwalten kannst du in Dockge nicht. Ab Version 1.4 kann eine Dockge-Instanz andere Dockge-Instanzen als „Agents“ einbinden, sodass du mehrere Server von einer Oberfläche aus bedienst.

Wenn du noch nicht sicher bist, was ein Compose-Stack überhaupt ist: In unserem Docker-Compose-Beispiel erklären wir das an einem echten Projekt mit sechs Fallen, die wir selbst nachgemessen haben. Und wer ganz am Anfang steht, liest zuerst Was ist Docker?.

Unser Testaufbau

Wir wollten keine Bildschirmfotos aus Dokumentationen abschreiben, sondern beide Werkzeuge so benutzen, wie ein Einsteiger es tun würde, und dabei messen. Wichtig war uns, dass die Tests keinen echten Dienst auf dem Server berühren. Deshalb liefen beide Oberflächen nur auf 127.0.0.1 mit Ports, die sonst niemand nutzt, und alle Testcontainer bekamen das Präfix pvd-.

Portainer haben wir so gestartet, wie es die offizielle Anleitung zeigt, nur mit eigenem Volume-Namen und lokalem Port:

docker run -d --name pvd-portainer \
  -p 127.0.0.1:19443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v pvd_portainer_data:/data \
  portainer/portainer-ce:lts

Dockge braucht zusätzlich einen Ordner für die Stacks. Eine Besonderheit, die man leicht übersieht: Der Pfad muss innerhalb und außerhalb des Containers identisch sein, weil Dockge docker compose über den Socket aufruft und Docker die Pfade dann auf dem Host auflöst.

docker run -d --name pvd-dockge \
  -p 127.0.0.1:15001:5001 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/pvd/data:/app/data \
  -v /tmp/pvd/stacks:/tmp/pvd/stacks \
  -e DOCKGE_STACKS_DIR=/tmp/pvd/stacks \
  louislam/dockge:1

In der Praxis nimmst du dafür einen festen Ordner wie /opt/stacks. Die Ersteinrichtung und das Anlegen der Stacks haben wir nicht durch Klicken, sondern über die Schnittstellen der beiden Programme erledigt: bei Portainer die REST-API, bei Dockge die Socket.IO-Verbindung, die auch die Weboberfläche benutzt. So konnten wir Zeiten genau messen und jede Antwort wörtlich festhalten.

Installation: Imagegröße und Startzeit

Schon beim Herunterladen zeigt sich der erste Unterschied, und er geht in die Richtung, die viele nicht erwarten.

Portainer ist ein einzelnes Go-Programm. Dockge bringt eine komplette Node.js-Laufzeit, das Docker-CLI, das Compose-Plugin und ein Frontend mit. Deshalb ist das Image fast sechsmal so groß. Für einen Server mit 20 oder 40 GB Platte ist das kein Drama, auf einem kleinen Raspberry Pi mit knapper SD-Karte merkt man es aber.

Die Startzeit ist bei beiden kein Thema. Nach 0,4 beziehungsweise 1,2 Sekunden lieferte die Oberfläche bereits HTTP 200 aus.

Ersteinrichtung: Setup-Token gegen „wer zuerst kommt“

Hier kam der überraschendste Befund des Tests. Beide Werkzeuge fragen beim ersten Aufruf nach einem Admin-Konto. Die spannende Frage ist: Wer darf dieses Konto anlegen?

Portainer hat das in den aktuellen Versionen verschärft. Unser erster Versuch, per API ein Admin-Konto anzulegen, scheiterte mit:

403 Invalid or missing setup token. Provide the X-Setup-Token header
with the token printed in the server logs at startup.

Das Token steht beim Start in den Container-Logs:

docker logs pvd-portainer 2>&1 | grep setup_token

setup_token=2823124d2d60…
Paste it into the setup screen, or send it in the X-Setup-Token header.
Start with --no-setup-token to disable.

Nur wer Zugriff auf die Logs hat, also auf den Server selbst, kann Portainer einrichten. Mit dem Token wurde zuerst unser Testpasswort kurz abgelehnt („Password does not meet the requirements“, HTTP 400), ein langes Passwort ging durch. Danach mussten wir noch die lokale Docker-Umgebung als „Environment“ anlegen. Erst dann zeigte Portainer alle zwölf Container auf dem Server.

Zusätzlich hat Portainer eine Zeitsperre. Wir haben einen zweiten Portainer-Container gestartet und nicht eingerichtet. Start um 08:02 Uhr, um 08:07 Uhr stand im Log:

the Portainer instance timed out for security purposes, to re-enable
your Portainer instance, you will need to restart Portainer

Nach fünf Minuten ohne Admin-Konto macht Portainer also dicht. Das ist ärgerlich, wenn du zwischendurch Kaffee holst, aber genau richtig: Ein frisch installierter, offener Portainer im Internet ist ein Geschenk für Angreifer.

Dockge kennt weder Token noch Frist. Unser Testpasswort kurz wurde ebenfalls abgelehnt („Password is too weak“), ein Passwort mit Buchstaben und Ziffern ging durch. Ein zweiter Versuch, mit einem anderen Benutzernamen erneut einzurichten, scheiterte korrekt („Dockge has been initialized“). Aber bis zu diesem Moment gilt: Wer die Seite zuerst erreicht, legt das Admin-Konto an. Im Quellcode der Einrichtung fanden wir nur zwei Prüfungen, nämlich Passwortstärke und „gibt es schon einen Benutzer?“. Eine Zeitsperre gibt es dort nicht.

Praktisch heißt das: Starte Dockge nie mit offenem Port ins Internet und richte es später ein. Entweder du bindest den Port an 127.0.0.1 und gehst per SSH-Tunnel drauf, oder du richtest das Konto in derselben Minute ein, in der der Container läuft.

Stacks anlegen: Wo landet deine Compose-Datei?

Das ist für uns der wichtigste Unterschied im Vergleich Portainer vs Dockge, weil er entscheidet, wie abhängig du von der Oberfläche wirst. Wir haben mit beiden denselben kleinen Stack angelegt:

services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:18080:80"

Bei Dockge lag die Datei danach genau dort, wo man sie erwartet:

/tmp/pvd/stacks/pvd-demo/compose.yaml

Ein ganz normaler Ordner mit einer ganz normalen compose.yaml. Docker hat sich als Arbeitsverzeichnis des Projekts genau diesen Ordner gemerkt. Du kannst jederzeit per SSH reingehen und mit den gewohnten Befehlen arbeiten:

cd /tmp/pvd/stacks/pvd-demo
docker compose ps
# pvd-demo-web-1 running

Dockge und die Kommandozeile sehen dieselbe Datei. Du kannst sie mit Git versionieren, mit rsync oder einem Backup-Tool sichern und Dockge jederzeit wieder loswerden, ohne dass sich an deinen Stacks etwas ändert.

Bei Portainer landet die Datei in seinem eigenen Daten-Volume:

/data/compose/1/docker-compose.yml   (im Volume pvd_portainer_data)

Docker merkt sich am Container das Label com.docker.compose.project.config_files=/data/compose/1/docker-compose.yml. Diesen Pfad gibt es aber nur innerhalb des Portainer-Containers. Auf dem Host antwortete ls /data/compose/1 mit „No such file or directory“. Wer den Stack per Kommandozeile bearbeiten will, muss die Datei erst aus dem Volume herausholen. Und wer ihn trotzdem auf dem Host ändert, hat zwei Wahrheiten: Portainer zeigt weiter seine eigene Version an.

Dazu passt eine Beobachtung, die in Foren immer wieder auftaucht: Stacks, die du außerhalb von Portainer per docker compose gestartet hast, zeigt Portainer zwar an, nennt sie aber „Limited“ und lässt dich die Datei nicht bearbeiten. Dockge geht damit freundlicher um. Bei uns tauchten alle bereits laufenden Compose-Projekte des Servers sofort in der Stack-Liste auf, sauber markiert als „nicht von Dockge verwaltet“. Liegt die Datei im Stack-Ordner, übernimmt Dockge sie komplett.

Ein Gegenpunkt für Portainer: Es kann Stacks direkt aus einem Git-Repository ziehen und auf Wunsch automatisch neu bauen, wenn sich das Repo ändert (GitOps). Dann ist es egal, wo Portainer seine Kopie ablegt, weil die Wahrheit im Repo liegt. Dockge kann das nicht.

Bedienung im Alltag: Deploy, Neustart, Update

Für den täglichen Betrieb haben wir die typischen Handgriffe gemessen.

Die reinen Zeiten sind nicht der Punkt. Beide rufen am Ende Docker auf, und Docker bestimmt, wie lange ein Pull dauert. Spannender ist, was du dabei siehst. Portainer arbeitet im Hintergrund und meldet Erfolg oder Fehler. Bei uns kam die API-Antwort nach 66 Millisekunden zurück, der Container war aber erst rund drei Sekunden später erreichbar. Dockge zeigt dir dagegen die komplette Ausgabe von docker compose up live im Browser, inklusive Pull-Fortschritt und Fehlermeldungen. Wenn ein Stack nicht hochkommt, ist das Gold wert.

Eine kleine Komfortfunktion von Dockge, die Einsteiger lieben: docker run in Compose umwandeln. Du fügst einen docker run-Befehl aus einer Anleitung ein und bekommst eine Compose-Datei. Wir haben es mit einem typischen Befehl getestet:

docker run -d --name uptime -p 3001:3001 \
  -v uptime:/app/data --restart unless-stopped louislam/uptime-kuma:1

Ergebnis:

services:
    uptime-kuma:
        container_name: uptime
        ports:
            - 3001:3001
        volumes:
            - uptime:/app/data
        restart: unless-stopped
        image: louislam/uptime-kuma:1
volumes:
    uptime:
        third-party: true
        name: uptime

Achtung bei einem Detail: Das Volume wird als third-party: true angelegt. Das heißt, Compose erwartet, dass es das Volume uptime schon gibt. Auf einem frischen Server bricht der Start dann ab. Die Zeilen third-party: true und name: uptime einfach löschen, dann legt Compose das Volume selbst an. Außerdem steht der Port ohne 127.0.0.1: davor, also offen auf allen Schnittstellen. Warum das gefährlicher ist, als es aussieht, haben wir in UFW-Firewall einrichten gezeigt: Docker-Ports umgehen UFW.

Portainer hat dafür andere Stärken im Alltag. Du kannst einzelne Container ohne Compose starten, Images aufräumen, ungenutzte Volumes löschen, Netzwerke anlegen und dir Statistiken pro Container ansehen. Wer häufig einzelne Container anfasst oder mehrere Benutzer mit unterschiedlichen Rechten hat, kommt mit Dockge nicht weit.

Speicherverbrauch: Wer ist wirklich leichtgewichtig?

Dockge wird fast überall als „leichtgewichtige Portainer-Alternative“ beschrieben. Gemessen haben wir etwas anderes. Nach Einrichtung und je einem Deploy, gut eine halbe Minute im Leerlauf, zeigte docker stats:

Ein Blick in die Prozessliste erklärt den Unterschied. In Portainer läuft genau ein Prozess, das Go-Programm. In Dockge liefen zwei Node.js-Prozesse, zwei esbuild-Prozesse und noch ein docker-compose-Prozess vom letzten Deploy. Node.js braucht für sich allein schon einige Dutzend Megabyte.

„Leichtgewichtig“ stimmt bei Dockge also für die Bedienung, nicht für die Ressourcen. Auf einem Server mit 2 GB RAM sind 150 MiB schon spürbar. Auf einem Homeserver mit 16 GB ist es egal. Wie viel Puffer ein Server sonst noch braucht, rechnen wir in Wie viel RAM braucht ein Server? vor.

Was passiert, wenn die Oberfläche ausfällt?

Eine Sorge, die Einsteiger oft haben: Wenn ich Portainer oder Dockge stoppe, sind dann meine Anwendungen weg? Wir haben beide Verwaltungscontainer gestoppt, während die Test-Stacks liefen.

dockge-stack    HTTP 200
portainer-stack HTTP 200

Beide Stacks liefen ungerührt weiter. Das liegt daran, dass weder Portainer noch Dockge die Container selbst ausführen. Sie sagen Docker nur, was zu tun ist. Ist die Oberfläche weg, fehlt dir nur das Bedienfeld, nicht die Anwendung. Der Unterschied liegt wieder bei den Dateien: Ohne Dockge arbeitest du im Stack-Ordner einfach per Kommandozeile weiter. Ohne Portainer musst du erst an das Volume heran, um deine Compose-Datei wiederzufinden.

Sicherheit: Beide halten den Generalschlüssel

Egal, wie du dich entscheidest: Wer Portainer oder Dockge bedienen kann, hat Root-Rechte auf deinem Server. Beide brauchen den Docker-Socket, und mit Zugriff auf den Socket kann man einen Container starten, der das gesamte Dateisystem des Hosts einbindet. Das ist kein Fehler der beiden Programme, sondern liegt in der Natur von Docker.

Daraus ergeben sich ein paar einfache Regeln, die für beide gelten:

• Nicht offen ins Internet stellen. Am besten bindest du die Oberfläche an 127.0.0.1 und erreichst sie per SSH-Tunnel oder über ein VPN wie Tailscale oder WireGuard.
• Wenn doch öffentlich, dann mit HTTPS hinter einem Reverse Proxy und einem starken Passwort. Portainer bringt auf Port 9443 ein selbstsigniertes Zertifikat mit. Dockge spricht nur HTTP, sein Port 5001 sollte also nie direkt erreichbar sein.
• Portainer-Port 9000 abschalten. In unserem Test antwortete Portainer zusätzlich auf Port 9000 unverschlüsselt mit HTTP 200, weil wir ihn mit veröffentlicht hatten. Lass -p 9000:9000 einfach weg.
• Ports in Compose-Dateien an 127.0.0.1 binden, wenn der Dienst nur über den Reverse Proxy erreichbar sein soll.

Ein paar Unterschiede gibt es trotzdem. Portainer hat ein Rechtesystem mit Benutzern und Teams (die feineren Rollen nur in der Business Edition), Dockge kennt genau einen Benutzer. Portainer hat Setup-Token und Zeitsperre, Dockge nicht. Bei Dockge wurde im April 2026 eine Warnung zu einer möglichen XSS-Lücke im Frontend behoben, eine neue Version mit diesem Fix gibt es aber nicht. Wer das Image louislam/dockge:1 zieht, bekommt immer noch den Stand vom März 2025.

Pflege und Zukunft: Wer wird noch weiterentwickelt?

Das ist der Punkt, den wir vorher unterschätzt hatten. Wir haben die Veröffentlichungen beider Projekte am 14. November 2026 nachgesehen:

Dockge ist nicht tot, aber es ruht. Das Prinzip ist inzwischen so einfach und stabil, dass es auch ohne neue Versionen funktioniert. Weil Dockge am Ende nur docker compose aufruft, profitierst du trotzdem von neuen Compose-Funktionen, sobald das Compose-Plugin im Image aktualisiert wird. Genau das passiert aber nur mit einer neuen Version. Im Image vom März 2025 steckt der Compose-Stand vom März 2025.

Portainer dagegen wird aktiv gepflegt, hat eine Firma im Rücken und bekommt Sicherheitsupdates. Der Preis dafür: Portainer bewirbt die Business Edition recht deutlich in der Oberfläche, und einzelne Funktionen sind dort hinter der Bezahlschranke.

Wer Dockge mag, aber bei der Pflege unsicher ist, sollte sich die neueren Werkzeuge ansehen, die in dieselbe Richtung gehen. Häufig genannt werden Komodo, Arcane und Dockhand. Wir haben sie in diesem Test nicht gemessen, daher nur der Hinweis, dass es sie gibt. Das Gute an Dockges Ansatz: Weil deine Stacks ganz normale Dateien sind, kannst du später ohne Aufwand wechseln.

Portainer vs Dockge: Alle Unterschiede auf einen Blick

Unsere Empfehlung: Portainer oder Dockge?

Es gibt keinen Sieger für alle. Die Entscheidung hängt an einer Frage: Willst du eine Oberfläche, die Docker verwaltet, oder eine, die deine Compose-Dateien bearbeitet?

Nimm Dockge, wenn:

• du einen oder wenige Server mit Compose-Stacks betreibst, typisch Homeserver oder kleiner VPS,
• du die Dateien weiterhin selbst besitzen und per SSH, Git oder Backup erreichen willst,
• du beim Deploy sehen willst, was passiert,
• du allein bist und keine Benutzerverwaltung brauchst,
• dich 150 MiB RAM nicht stören.

Nimm Portainer, wenn:

• du einzelne Container, Images, Volumes und Netzwerke grafisch verwalten willst,
• mehrere Leute mit unterschiedlichen Rechten auf den Server sollen,
• du Stacks aus Git automatisch ausrollen willst,
• du Swarm oder Kubernetes nutzt,
• dir regelmäßige Sicherheitsupdates wichtig sind,
• der Server wenig RAM hat.

Beides gleichzeitig geht übrigens problemlos, und viele machen genau das. Dockge für die Stacks, Portainer als Röntgengerät für alles andere. Beide sprechen über denselben Socket mit Docker und kommen sich nicht in die Quere. Nur einen Stack solltest du nie aus beiden heraus bearbeiten, sonst gibt es wieder zwei Wahrheiten.

Und ganz ehrlich: Für viele kleine Server ist die beste Oberfläche gar keine. Ein Ordner /opt/stacks mit einem Unterordner pro Anwendung, darin je eine compose.yaml, versioniert mit Git, dazu docker compose up -d per SSH. Genau diese Struktur legt Dockge übrigens selbst an. Wer sie von Anfang an benutzt, kann sich Dockge später jederzeit dazunehmen oder wieder wegnehmen. Wie man den Server dafür sauber vorbereitet, zeigen wir in Linux-Server einrichten.

So installierst du Dockge sicher

Falls du dich für Dockge entscheidest, hier eine Compose-Datei, die die Fallen aus unserem Test vermeidet: fester Stack-Ordner mit gleichem Pfad innen und außen, Port nur lokal.

services:
  dockge:
    image: louislam/dockge:1
    restart: unless-stopped
    ports:
      - "127.0.0.1:5001:5001"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
      - /opt/stacks:/opt/stacks
    environment:
      - DOCKGE_STACKS_DIR=/opt/stacks

Leg die Datei zum Beispiel unter /opt/dockge/compose.yaml ab, starte sie mit docker compose up -d und öffne sie sofort per SSH-Tunnel:

ssh -L 5001:127.0.0.1:5001 user@dein-server
# dann im Browser: http://localhost:5001

Richte das Admin-Konto sofort ein. Erst danach, falls überhaupt nötig, kommt ein Reverse Proxy mit HTTPS davor.

So installierst du Portainer sicher

Für Portainer sieht die sichere Variante ähnlich aus. Port 9000 lassen wir weg, Port 9443 bleibt lokal:

services:
  portainer:
    image: portainer/portainer-ce:lts
    restart: unless-stopped
    ports:
      - "127.0.0.1:9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
volumes:
  portainer_data:

Nach dem Start holst du dir das Setup-Token:

docker compose logs portainer | grep setup_token

Dann den SSH-Tunnel auf Port 9443 öffnen, https://localhost:9443 aufrufen, Token einfügen, Admin anlegen. Denk an die fünf Minuten. Wenn sie abgelaufen sind, hilft docker compose restart portainer, danach gibt es ein neues Token.

Und noch ein Tipp, falls du Portainer-Stacks irgendwann zu Dockge oder auf die Kommandozeile mitnehmen willst: Die Dateien liegen im Volume unter compose/<Nummer>/docker-compose.yml. Mit einem kurzen Wegwerf-Container kommst du heran:

docker run --rm -v portainer_data:/d alpine find /d/compose -name '*.yml'

Grenzen unseres Tests

Ehrlich gesagt: Wir haben beide Werkzeuge an einem Vormittag auf einem Server getestet, nicht über Monate im Dauerbetrieb. Die Speicherwerte sind Momentaufnahmen nach einer halben Minute Leerlauf, mit einem einzigen Stack. Mit vielen Stacks und offenen Browser-Tabs steigt der Verbrauch bei beiden. Die Mehrserver-Funktionen (Portainer-Agent, Dockge-Agents) und die Business Edition haben wir nicht ausprobiert. Alle Container, Volumes, Netzwerke und Images aus dem Test haben wir danach wieder entfernt. Auf dem Server blieben keine Reste.

Häufige Fragen

Ist Dockge besser als Portainer?

Nicht generell. Dockge ist einfacher und lässt deine Compose-Dateien als normale Dateien auf dem Server liegen. Portainer kann viel mehr, wird aktiver gepflegt und braucht in unserer Messung weniger RAM. Für einen Homeserver mit ein paar Stacks ist Dockge oft angenehmer, für Teams und größere Umgebungen Portainer.

Was ist der Hauptunterschied zwischen Portainer und Dockge?

Portainer verwaltet Docker als Ganzes: Container, Images, Volumes, Netzwerke, Benutzer, sogar Kubernetes. Dockge verwaltet nur Docker-Compose-Stacks und speichert sie als compose.yaml in einem Ordner deiner Wahl. Portainer legt seine Stack-Dateien dagegen in seinem eigenen Volume ab.

Kann ich Portainer und Dockge gleichzeitig benutzen?

Ja. Beide sprechen über den Docker-Socket mit demselben Docker-Daemon und stören sich nicht. Bearbeite einen Stack aber nur in einem der beiden Werkzeuge, sonst entstehen zwei unterschiedliche Versionen der Compose-Datei.

Wird Dockge noch weiterentwickelt?

Stand 14. November 2026 ist die letzte Version 1.5.0 vom 30. März 2025. Im Repository gab es danach noch Sicherheits- und Wartungscommits, zuletzt im Oktober 2026, und täglich neue Nightly-Builds. Eine neue stabile Version gibt es seit über eineinhalb Jahren nicht. Dockge funktioniert trotzdem zuverlässig, weil es nur docker compose aufruft.

Ist Portainer kostenlos?

Die Community Edition (CE) ist kostenlos und quelloffen. Daneben gibt es die kostenpflichtige Business Edition mit zusätzlichen Funktionen wie feiner Rechteverwaltung und Support. Für einen eigenen Server reicht die CE fast immer.

Wie viel RAM braucht Dockge?

In unserem Test brauchte Dockge im Leerlauf rund 152 MiB, Portainer rund 22 MiB. Dockge läuft auf Node.js und hält mehrere Prozesse am Leben. Auf kleinen Servern mit 1 bis 2 GB RAM solltest du das einplanen.

Wie übernehme ich meine Portainer-Stacks in Dockge?

Hol die Compose-Dateien aus dem Portainer-Volume (compose/<Nummer>/docker-compose.yml), lege für jeden Stack einen Ordner im Dockge-Stack-Verzeichnis an und speichere die Datei dort als compose.yaml. Wichtig: Der Ordnername wird zum Projektnamen. Heißt er wie in Portainer, erkennt Docker die laufenden Container wieder. Sonst entstehen neue Container und, wenn du Volumes nicht explizit benennst, auch neue Volumes.

Ist es gefährlich, Portainer oder Dockge offen ins Internet zu stellen?

Ja. Wer die Oberfläche bedienen kann, hat über den Docker-Socket praktisch Root-Rechte auf dem Server. Binde den Port an 127.0.0.1 und nutze einen SSH-Tunnel oder ein VPN. Wenn es öffentlich sein muss, dann nur mit HTTPS über einen Reverse Proxy, starkem Passwort und am besten zusätzlichem Schutz davor.

Was ist das Setup-Token bei Portainer?

Seit den aktuellen Versionen schreibt Portainer beim ersten Start ein zufälliges Token in die Container-Logs. Nur wer dieses Token kennt, kann das Admin-Konto anlegen. Ohne Admin-Konto sperrt sich Portainer nach fünf Minuten selbst, ein Neustart des Containers hebt die Sperre auf.

Kann Dockge auch Kubernetes oder Docker Swarm verwalten?

Nein. Dockge kennt nur Docker Compose auf einem oder mehreren Servern (über Dockge-Agents). Für Swarm oder Kubernetes ist Portainer die passende Wahl unter den beiden.

Gibt es Alternativen zu Portainer und Dockge?

Ja, zum Beispiel Komodo, Arcane, Dockhand oder Yacht. Wer Podman statt Docker nutzt, findet in unserem Vergleich Docker vs Podman Hinweise, welche Oberflächen dort funktionieren. Und für viele kleine Server reicht ein Ordner mit Compose-Dateien und SSH völlig aus.

Brauche ich für Dockge Docker Compose auf dem Server?

Nein, das Compose-Plugin ist im Dockge-Image enthalten. Es ist aber praktisch, Compose auch auf dem Host zu haben, damit du die Stacks im Notfall ohne Dockge per Kommandozeile bedienen kannst.

Fazit

Im Vergleich Portainer vs Dockge gewinnt das Werkzeug, das zu deiner Arbeitsweise passt. Dockge ist die schönere Oberfläche für Docker Compose: Es zeigt dir live, was passiert, wandelt docker run in Compose um und lässt deine Stacks als ganz normale Dateien auf dem Server liegen. Dafür ist es überraschend groß, braucht in unserer Messung siebenmal so viel RAM wie Portainer, hat keinen Schutz bei der Ersteinrichtung und seit März 2025 keine neue Version.

Portainer ist die vollständige Verwaltungszentrale, wird aktiv gepflegt, schützt die Ersteinrichtung mit Token und Zeitsperre und braucht kaum Speicher. Dafür versteckt es deine Compose-Dateien in seinem eigenen Volume und ist für reine Compose-Nutzer oft mehr Werkzeug als nötig.

Unser eigener Weg auf den Servern bleibt übrigens die schlichteste Variante: ein Ordner pro Stack, Compose-Dateien in Git, Deploy per SSH. Wenn wir eine Oberfläche dazunehmen, dann Dockge, weil wir sie jederzeit wieder entfernen können, ohne dass sich an den Stacks etwas ändert. Wie Container untereinander reden, sobald du mehrere Stacks hast, erklären wir in Docker-Netzwerk erklärt.