Nativ vs. Container — wofür soll ich mich entscheiden?

Nativ führt deine Web-App direkt auf dem Host unter systemd aus — schnell, wenig RAM, gemeinsam genutzte Laufzeitumgebung. Container führt sie in Docker aus — eigene Laufzeitversion pro App, ~30–100 MB zusätzlicher RAM.

Zuletzt aktualisiert am 24. Mai 2026

Nur relevant, wenn du eine Web-App bereitstellst (Node, Python, Go). Bei statischen Websites und WordPress wird diese Auswahl nicht angezeigt.

Wenn du eine Web-App bereitstellst, gibt es im Bereitstellungsfenster im Bereich Erweitert einen Umschalter: Als nativen Prozess bereitstellen oder Container. Beides bringt deine App hinter mit -HTTPS online — der Unterschied ist, wie dein Code darunter läuft.

Was du auswählst

Der Umschalter „Bereitstellen als“ im Bereich „Erweitert“ des Bereitstellungsfensters

Nativer Prozess — Server Manager installiert die Laufzeitumgebung einmal auf dem Host (Node 22 LTS, Python 3 + venv oder Go) und führt deine App dann direkt unter als eigenen Dienst aus.
Container — Server Manager baut ein Docker-Image für deine App mit der von dir gewählten Laufzeitversion und startet es dann als Container hinter dem Caddy des Hosts.

In beiden Fällen gilt: dieselbe Domain, dasselbe HTTPS, derselbe Button zum Abrufen der neuesten Version aus Git, derselbe Zugriff auf deinen Code im Dateien-Tab.

So funktioniert Nativ

Deine App liegt unter /opt/<appName>/ und läuft als -Unit namens <appName>.service. Die Laufzeitumgebung (Node, Python, Go) wird einmal auf Betriebssystemebene installiert und von allen nativen Web-Apps auf dem Server gemeinsam genutzt.

Native Bereitstellung — drei Apps unter systemd, die sich alle eine Node- und eine Python-Installation auf dem Host teilen

Dateien unter /opt/<appName>/
Dienst wird von systemd verwaltet — sudo systemctl status <appName> funktioniert wie erwartet
Logs werden von journald erfasst und im Logs-Tab angezeigt
Laufzeitumgebung eine Node-22-, eine Python-3- und eine Go-Installation auf dem Host — alle nativen Apps teilen sie sich

So funktioniert Container

Deine App läuft in ihrem eigenen Docker-Container. Die Compose-Datei liegt unter /opt/<appName>/docker-compose.yml, und der Container hängt hinter dem Caddy des Hosts, der deine Domain per Reverse Proxy an den internen Port des Containers weiterleitet.

Container-Bereitstellung — drei Apps, jede in ihrem eigenen Docker-Container mit eigener festgelegter Laufzeitversion

Dateien unter /opt/<appName>/ — dein Quellcode plus ein Dockerfile und eine docker-compose.yml, die wir erzeugen
Dienst wird von Docker verwaltet — sudo docker compose -f /opt/<appName>/docker-compose.yml ps zeigt den Status
Logs werden von Docker erfasst und im Logs-Tab angezeigt
Laufzeitumgebung jede App legt ihre eigene Version fest — Node 18, Node 22, Python 3.11, Python 3.13 können alle parallel laufen

Wofür soll ich mich entscheiden?

Die meisten Apps sollten mit Nativ starten. Wähle Container nur, wenn du einen konkreten Grund dafür hast.

Wenn …	Wähle
Du hast eine App auf dem Server und Versionsfestlegung ist dir egal	Nativ
Du möchtest den geringsten RAM-Overhead (wichtig bei Servern mit 1 GB / 2 GB)	Nativ
Du möchtest die schnellsten Bereitstellungen (kein Image-Build)	Nativ
Du hast zwei Apps mit unterschiedlichen Laufzeitversionen (z. B. Node 18 + Node 22)	Container für mindestens die App, die aus der Reihe fällt
Du möchtest strikte Isolation zwischen Apps (z. B. weil eine App Fremdcode ist, dem du nicht vollständig vertraust)	Container
Deine App bringt eine komplexe Abhängigkeit außerhalb der Laufzeitumgebung mit (bestimmte Postgres-Client-Version, ImageMagick-Build usw.)	Container (alles wird im Image mitgeliefert)
Du planst, diese App später auf einen anderen Host umzuziehen	Container (das Image ist portabel; native Bereitstellungen hängen von der Laufzeitumgebung des Hosts ab)

Der grobe Kompromiss in Zahlen:

Nativ: ~50–200 MB RSS pro App (nur die App + Interpreter). Erste Bereitstellung: 10–30 s.
Container: ~50–200 MB RSS für die App + ~30–100 MB Docker-Overhead pro Container. Erste Bereitstellung: 1–3 min (Image-Build).

Auf einem 2-GB-Server, der größtenteils im Leerlauf ist, kannst du 5–8 native Web-Apps + Caddy + eine kleine Datenbank betreiben. Mit Containern sinkt das auf etwa 4–6.

Später wechseln

Der Modus ist fest mit der App verbunden: Im Dienstbereich gibt es keinen Umschalter, mit dem du eine native App in einen Container umwandeln kannst oder umgekehrt.

Um zu wechseln, stelle die App erneut bereit und wähle im Dialog die andere Option:

Öffne Aktionen → Von meinem Computer bereitstellen (oder Eine Web-App aus einem Git-Repo bereitstellen)
Lege deinen Code ab oder füge die Repo-URL ein
Erweitert aufklappen → den Umschalter Bereitstellen als umlegen
Klicke auf Bereitstellen — die vorhandene App wird durch den neuen Modus ersetzt

Der Code bleibt auf der Festplatte (die .helm-keep-Regeln aus Mehrere Websites auf demselben Server gelten genauso für erneute Container-Bereitstellungen). Deine Domain zeigt weiter auf dieselbe Stelle. Die Ausfallzeit entspricht der Dauer einer normalen erneuten Bereitstellung — meistens unter einer Minute.