Proxmox VE Helper-Scripts: Dienste mit einem Befehl installieren | MappleBox

Proxmox VE Helper-Scripts: Dienste mit einem Befehl installieren

VonLion Stark

Du hast Proxmox installiert und willst jetzt Dienste wie Vaultwarden, Pi-hole oder ein Dashboard darauf laufen lassen. Von Hand heißt das: Container anlegen, Template laden, Pakete installieren, Service einrichten. Die Proxmox VE Helper-Scripts nehmen dir das ab. Du kopierst einen Befehl in die Shell deines Proxmox-Hosts, beantwortest ein paar Fragen und bekommst einen fertigen LXC mit laufendem Dienst. In diesem Guide zeige ich dir, wie das funktioniert, welche Einstellungen du kennen solltest und wie du die Scripts sicher nutzt.

Kurz erklärt

  • Die Helper-Scripts sind eine Sammlung von Bash-Scripts, die auf Proxmox VE einen Container oder eine VM anlegen und darin einen Dienst installieren.
  • Sie sind gut für alle, die schnell einen Dienst testen oder dauerhaft betreiben wollen, ohne jede Installation selbst zu bauen.
  • Du brauchst einen Proxmox-VE-Host, Zugriff auf dessen Shell als root und eine Internetverbindung.
  • Die Scripts laufen mit vollen Rechten auf deinem Host. Deshalb gehört ein kurzer Blick in den Code und ein Backup vor Updates dazu.

Was die Helper-Scripts sind

Ursprünglich hat der Entwickler tteck die Scripts geschrieben und in seinem Repository gepflegt. Im November 2024 hat die Community das Projekt übernommen. Seitdem liegt es auf GitHub unter community-scripts/ProxmoxVE, das alte Repository ist archiviert. Im README steht bis heute „In memory of tteck“. Die offizielle Website ist community-scripts.org, die alte Adresse community-scripts.github.io/ProxmoxVE leitet dorthin weiter.

Ein LXC ist ein Linux-Container: Er teilt sich den Kernel mit dem Proxmox-Host und braucht dadurch viel weniger Ressourcen als eine VM. Die meisten Helper-Scripts legen genau so einen LXC an. Für ein paar Fälle wie Home Assistant OS gibt es auch Scripts, die eine VM erstellen. Laut README werden aktuell Proxmox VE 8.4 sowie 9.0, 9.1 und 9.2 unterstützt.

Jedes Script bringt sinnvolle Standardwerte mit. Das Script für Stirling-PDF zum Beispiel legt einen unprivilegierten Debian-13-Container mit 2 Kernen, 2048 MB RAM und 8 GB Disk an und sagt dir am Ende die URL mit Port 8080. Du musst nicht wissen, welche Java-Version oder welche Abhängigkeiten das Programm braucht.

Bei mir sind über 40 Container und VMs auf vier Proxmox-Hosts so entstanden, darunter Homarr, Glance, Apache Guacamole, Stirling-PDF, Docmost, Caddy, Pelican Panel und Wings, Pi-hole, Vaultwarden und Home Assistant als VM. Nicht alles: Paperless-ngx betreibe ich zum Beispiel mit Docker Compose. Wie die Hosts verteilt sind, steht in Mein Homelab an zwei Standorten.

Das brauchst du

  • Einen Proxmox-VE-Host in einer unterstützten Version. Ein Mini-PC reicht völlig. Falls deiner im Dauerbetrieb zu warm wird, hilft der CPU-Governor auf powersave.
  • Einen Browser mit Zugriff auf die Proxmox-Weboberfläche oder eine SSH-Verbindung zum Host als root.
  • Genug freien Speicher auf deinem Storage, zum Beispiel local-lvm. Das Script prüft das vorher und warnt dich.
  • Ein DHCP-Server im Netz (meist dein Router), wenn du mit den Standardwerten arbeitest.

Schritt 1: Script auf der Website finden

Öffne community-scripts.org und such nach dem Dienst, den du willst. Jede Script-Seite hat eine Beschreibung, einen Changelog und unter Details Links zum Install- und Update-Code. Lies dort auch die Hinweise, etwa wenn Zugangsdaten in einer Datei landen.

Der Befehl hat immer dasselbe Format. Nur der Name am Ende ändert sich:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/stirling-pdf.sh)"

ct/ steht für Container-Scripts. VM-Scripts liegen unter vm/, zum Beispiel vm/haos-vm.sh für Home Assistant OS. Werkzeuge für den Host selbst findest du unter tools/pve/.

Schritt 2: Script vorher lesen

Der Befehl oben lädt Code aus dem Internet und führt ihn sofort als root auf deinem Host aus. Das ist dasselbe Prinzip wie das bekannte curl | bash: Du siehst vorher nicht, was läuft. Ein Fehler oder ein manipuliertes Script hätte vollen Zugriff auf den Host und alle Container und VMs darauf. Nimm dir deshalb zwei Minuten und schau rein.

Am einfachsten öffnest du die URL aus dem Befehl im Browser, also https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/stirling-pdf.sh. Oder du lädst das Script auf dem Host in eine Datei und liest es mit less:

curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/stirling-pdf.sh -o /tmp/stirling-pdf.sh
less /tmp/stirling-pdf.sh

Mit q verlässt du less. Wenn dir nichts komisch vorkommt, startest du genau die Datei, die du gelesen hast, statt den Code noch einmal neu herunterzuladen:

bash /tmp/stirling-pdf.sh

Oben im Script stehen die Standardwerte als var_cpu, var_ram, var_disk, var_os und var_version. Die eigentliche Installation im Container macht eine zweite Datei unter install/, hier install/stirling-pdf-install.sh. Die gemeinsame Logik für Menüs und Container-Erstellung liegt inzwischen im eigenen Repository community-scripts/core. Das Script lädt diese Teile und das Install-Script während der Ausführung frisch von GitHub nach, auch wenn du es aus /tmp startest. Du prüfst also die App-spezifische Logik, nicht jede einzelne Zeile. Achte vor allem auf Downloads von fremden Adressen und auf Befehle, die außerhalb des neuen Containers etwas ändern.

Nutze nur Befehle, die auf raw.githubusercontent.com/community-scripts/ zeigen. Kopien in Foren, Videos oder Forks können veraltet oder verändert sein.

Schritt 3: Script in der Proxmox-Shell starten

In der Proxmox-Weboberfläche klickst du links auf deinen Node (nicht auf einen Container) und dann auf Shell. Dort fügst du den Befehl ein und drückst Enter. Beim ersten Mal fragt das Script, ob es Diagnosedaten senden darf. Laut Dialog sind das nur Angaben wie RAM, CPU und Container-Name, keine Nutzerdaten. Du kannst das ablehnen.

Danach siehst du ein Menü mit diesen Optionen:

  • Default Install: übernimmt alle Standardwerte des Scripts.
  • Advanced Install: führt dich Schritt für Schritt durch alle Einstellungen.
  • User Defaults und App Defaults: nutzen Werte, die du früher gespeichert hast. Die globalen liegen in /usr/local/community-scripts/default.vars.
  • Settings: Diagnose-Einstellung ändern und gespeicherte Defaults bearbeiten.

Default Install

Mit Default Install bekommst du einen unprivilegierten Container mit der nächsten freien ID, am Bridge vmbr0, mit IP per DHCP und den Ressourcen aus dem Script. Wenn du mehrere Storages hast, fragt das Script, wo Template und Container hin sollen. Für den Anfang ist das die beste Wahl.

Advanced Install

Advanced Install geht in rund 30 Schritten durch alles. Mit dem Button Back springst du einen Schritt zurück, im ersten Schritt beendet Exit das Script. Die wichtigsten Punkte:

  • Container Type: Unprivileged ist vorausgewählt und empfohlen. Ein unprivilegierter Container bildet root im Container auf einen normalen User am Host ab. Bricht jemand aus dem Dienst aus, hat er auf dem Host keine root-Rechte.
  • Root Password, Container ID und Hostname: Ohne Passwort meldest du dich über die Proxmox-Konsole automatisch an.
  • Disk Size, CPU Cores, RAM Size: Geh nicht unter die Standardwerte. Die sind auf das Programm abgestimmt.
  • Network Bridge, IPv4 und VLAN: Hier stellst du eine feste IP im Format 192.168.1.50/24 plus Gateway ein. Für Dienste, auf die ein Reverse Proxy zeigt, ist eine feste IP oder eine DHCP-Reservierung im Router sinnvoll.
  • Weitere Punkte wie Tags, Zeitzone, SSH-Zugang, Nesting oder GPU-Passthrough kannst du beim ersten Mal so lassen.

Am Ende zeigt dir das Script eine Zusammenfassung. Erst nach deiner Bestätigung legt es los. Die gewählten Werte kannst du als App Defaults speichern, dann sparst du dir das beim nächsten Mal.

Debian oder Alpine?

Fast alle Scripts nutzen Debian, aktuell meist Debian 13. Für einige Dienste gibt es zusätzlich ein Alpine-Script, dessen Name mit alpine- beginnt. Alpine-Container sind kleiner, nutzen aber musl und den Paketmanager apk, und die meisten Anleitungen im Netz gehen von Debian aus. Als Einsteiger nimmst du deshalb die Debian-Variante.

Schritt 4: Was im Container gelandet ist

Am Ende gibt das Script die URL aus, unter der dein Dienst erreichbar ist. Damit du später weißt, wo was liegt, schau dich kurz im Container um. Öffne in Proxmox den Container und dort die Konsole, oder nutze auf dem Host pct enter <ID>.

ls /opt
systemctl list-units --type=service --state=running
ls /root
  • Die Anwendung liegt meist unter /opt/<app>, bei Stirling-PDF also /opt/Stirling-PDF.
  • Der Dienst läuft als systemd-Service. Bei Stirling-PDF heißen sie stirlingpdf und unoserver. Den Namen findest du im Install-Script.
  • Manche Scripts legen Zugangsdaten in einer Datei wie /root/<app>.creds ab. Bei mir gibt es solche Dateien zum Beispiel für Docmost, Guacamole und das Pelican Panel. Notiere dir den Inhalt in deinem Passwort-Manager und ändere Standardpasswörter nach dem ersten Login.
  • Im Proxmox-UI bekommt der Container den Tag community-script und in der Übersicht unter Hinweise eine Beschreibung mit Logo. So erkennst du später, welche Container aus einem Script stammen.

Schritt 5: Updates mit dem Befehl update

Jeder Script-Container bekommt das Kommando update unter /usr/bin/update. Es ruft das passende Script von GitHub erneut auf, diesmal im Update-Modus. Gibt es eine neue Version, stoppt es meist den Dienst, spielt sie ein und startet ihn wieder. Bei Breaking Changes warnt es vorher und fragt nach.

Mach vorher einen Snapshot auf dem Host. Die ID deines Containers zeigt dir pct list. Im Webinterface geht das auch über den Container, dann Snapshots und Snapshot erstellen. Wenn das Update schiefgeht, bist du mit einem Befehl zurück:

# auf dem Proxmox-Host
pct snapshot <ID> vor-update

# im Container
update

# falls etwas kaputt ist, wieder auf dem Host
pct rollback <ID> vor-update

# wenn alles läuft, Snapshot später wieder löschen
pct delsnapshot <ID> vor-update

Snapshots funktionieren nur auf Storages, die das können, etwa local-lvm (LVM-Thin) oder ZFS. Liegt der Container auf einem reinen Verzeichnis-Storage wie local, bricht pct snapshot mit einem Fehler ab. Dann machst du vorher ein Backup mit vzdump <ID>. Lösch alte Snapshots wieder, sonst wächst der Platzbedarf. Unabhängig davon gehört ein regelmäßiges Backup mit vzdump auf ein anderes Gerät zu jedem Setup.

Das Post-Install-Script für frische Proxmox-Hosts

Neben den Dienst-Scripts gibt es Werkzeuge für den Host. Das bekannteste ist das Post-Install-Script:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"

Es fragt jeden Schritt einzeln ab. Es korrigiert die Paketquellen, deaktiviert das pve-enterprise-Repository (das ohne Subscription nicht funktioniert) und aktiviert stattdessen pve-no-subscription. Optional entfernt es den Subscription-Hinweis beim Login, schaltet High Availability und Corosync auf einem Einzel-Host ab, aktualisiert Proxmox und startet neu. Wenn du einen Cluster betreibst, lass HA und Corosync an. Das Script ist für frische Installationen gedacht. Auf einem Host, den du schon länger betreibst, lies vorher genau, was jede Frage ändert.

PVE Scripts Local: die Scripts mit Weboberfläche

Wenn du lieber klickst, gibt es vom selben Team PVE Scripts Local (Repository community-scripts/ProxmoxVE-Local). Das ist eine Weboberfläche, über die du Scripts durchsuchst, herunterlädst und mit Live-Terminal im Browser ausführst. Sie merkt sich, was auf welchem Host installiert ist, und erkennt bestehende Container über ihre Tags. Installiert wird sie selbst wieder per Helper-Script:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/pve-scripts-local.sh)"

Danach erreichst du sie unter http://192.168.1.x:3000. Bei mir läuft sie in einem Debian-LXC mit 2 Kernen und 4 GB RAM. Damit die Oberfläche Scripts auf deinen Hosts starten kann, hinterlegst du dort SSH-Zugangsdaten zu Proxmox. Die liegen in einer SQLite-Datei unter data/settings.db. Schalte deshalb die optionale Anmeldung ein und mach die Oberfläche nicht aus dem Internet erreichbar. Von außen gehst du besser über Tailscale oder ein VPN.

So prüfst du, ob es läuft

  • Auf dem Host zeigt pct list den neuen Container mit Status running.
  • Im Container zeigt systemctl status <dienst> „active (running)“.
  • ss -tlnp im Container listet den Port, auf dem der Dienst lauscht.
  • Die URL vom Ende der Script-Ausgabe öffnet sich im Browser.

Typische Probleme

Der Container bekommt keine IP. Prüf, ob die Bridge stimmt und ob im Netz ein DHCP-Server läuft. Wenn du ein VLAN nutzt, muss der VLAN-Tag im Advanced Install gesetzt sein.

Die Installation bricht ab. Oft fehlt RAM oder Platz. Das Script bietet bei manchen Fehlern einen neuen Versuch mit mehr Ressourcen an. Sonst lösch den halb fertigen Container und starte neu.

Das Update meldet „Legacy installation“. Manchmal ändert sich der Aufbau einer App so stark, dass das Script nur noch neue Container sauber aktualisieren kann. Dann legst du einen frischen Container an und ziehst deine Daten um.

Ein Script ist verschwunden. Die Sammlung wird von Freiwilligen gepflegt. Wenn ein Script zu viel Pflege braucht, fliegt es raus. Das Habitica-Script wurde zum Beispiel am 28. November 2025 entfernt. Bei mir laufen noch zwei Habitica-Container, die ich vorher damit angelegt habe. Der Dienst läuft weiter, nur update findet sein Script nicht mehr. Wie ich Habitica inzwischen manuell betreibe, steht in Habitica selbst hosten.

Bind Mounts funktionieren nicht. In unprivilegierten Containern stimmen die User-IDs nicht mit denen auf dem Host überein. Mehr zu Bind Mounts und geteilten Ordnern in LXCs findest du in LXC migrieren mit Bind Mounts.

Passende Guides für einzelne Dienste

Fazit

Die Helper-Scripts sind für mich der schnellste Weg, einen neuen Dienst auf Proxmox auszuprobieren und dauerhaft zu betreiben. Für den Einstieg reicht Default Install mit Debian. Gewöhn dir drei Dinge an: Script vorher kurz lesen, nur das offizielle Repository nutzen und vor jedem update einen Snapshot machen. Damit du mitbekommst, wenn ein Dienst ausfällt, lohnt sich danach Uptime Kuma mit ntfy.

Guide teilen

Hat dir der Guide geholfen? Dann spendier mir gern einen Kaffee auf Ko-fi. Damit bleibt MappleBox werbefrei.

Weitere Guides

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert