Important
This panel is a work in progress. Production use is not recommended.
Ein Panel, um Server jeder art auf deinem eigenen Linux-Server zu verwalten — ganz ohne Kommandozeile.
Der Maunting Server Manager ist ein Web-Panel. Du öffnest es im Browser und kannst damit:
- Game-Server installieren, starten, stoppen und neustarten
- Ports automatisch vergeben lassen (keine Kollisionen)
- CPU/RAM/Disk-Limits pro Server setzen
- Backups erstellen und wiederherstellen
- Mods verwalten
- Mehrere Benutzer mit unterschiedlichen Rechten anlegen
- 2FA und Email-Verifikation nutzen
- Kein Game-Server-Hosting-Anbieter (du brauchst einen eigenen Linux-Server, z.B. bei Hetzner, OVH, Strato)
- Kein Windows-Tool (läuft nur auf Linux — Ubuntu 22.04+ oder Debian 12+)
- Kein Ersatz für SteamCMD-Kenntnisse (das Panel nutzt SteamCMD im Hintergrund, du musst es nicht bedienen)
- Kein kostenloser Root-Server (du musst den Server selbst mieten)
Bevor du loslegst, brauchst du:
- Einen Linux-Server (Ubuntu 22.04 oder Debian 12 empfohlen)
- Root-Zugang (SSH-Key oder Passwort)
- Eine Domain (optional, aber empfohlen für HTTPS)
- Einen Resend-Account für die einfache Browser-Einrichtung (SMTP bleibt über den klassischen Installer möglich)
Öffne ein Terminal (PowerShell auf Windows, Terminal auf Mac/Linux) und verbinde dich:
ssh root@DEINE-SERVER-IPcurl -fsSL https://raw.githubusercontent.com/einmalmaik/maunting-server-manager/main/scripts/bootstrap.sh | sudo bash -s -- --domain panel.example.comErsetze panel.example.com durch die Domain, deren DNS bereits auf den Server
zeigt. Der Befehl fragt keine weiteren technischen Einstellungen ab.
Das war's. PostgreSQL, Rootless Docker, DIS, der lokale Agent, Caddy und die
Systemdienste werden automatisch eingerichtet. Eine vorhandene Legacy-SQLite-
Datenbank wird vor dem Update gesichert, einmalig geprüft nach PostgreSQL
importiert und anschließend als Migrationsarchiv behalten. Erkennt der
Bootstrap eine vorhandene Installation, verwendet er automatisch den sicheren
Updater; Serverdaten, Backups, Agent-Tokens und Konfigurationen bleiben erhalten.
Auf minimalen Ubuntu-/Debian-Systemen installiert derselbe install.sh-Pfad
alle benötigten Basispakete und repariert auch eine zuvor unvollständig
eingerichtete Caddy-Paketquelle, ohne eine vorhandene Caddyfile zu ersetzen.
Falls eine Erstinstallation nach dem Anlegen der lokalen msm-Datenbank
abbricht, kann sie ausdrücklich mit --resume-partial fortgesetzt werden. Der
Installer übernimmt dabei nur eine exakt passende, unprivilegierte Datenbank
msm mit Eigentümer msm; fremde PostgreSQL-Zustände bleiben blockiert.
MSM richtet Docker im Rootless-Modus für den msm-User ein. Der Panel-User
ist nicht Mitglied der globalen docker-Gruppe und nutzt
unix:///run/user/<msm_uid>/docker.sock statt /var/run/docker.sock.
- Öffne die Panel-URL im Browser (steht im Installer am Ende)
- Hinterlege im Setup-Wizard Absender und Resend-API-Key
- Erstelle den ersten Owner-Account und bestätige die E-Mail
- Lege deinen ersten Game-Server an
Für Self-Hosting und manuelle Installationen enthält jede Komponente eine vollständige, kommentierte Vorlage. Bei jeder Variable steht, was sie macht, ob sie automatisch erzeugt wird, wann sie geändert werden muss und wo ein externer Wert bezogen wird:
backend/.env.example— Panel, Panel-Datenbank, E-Mail, DIS, Steam/GitHub und Updatesmsm-agent/.env.example— lokaler oder entfernter Node, TLS, Docker und node-eigenes PostgreSQLfrontend/.env.example— ausschließlich öffentliche Build-Werte, niemals Secretsdis-sidecar/.env.example— lokale Kryptografie-Secrets, identisch zum Backend
Der normale Installer generiert alle sicherheitskritischen Werte und verweist
in den erzeugten .env-Dateien auf die jeweilige Vorlage. Manuell angelegte
Dateien müssen Modus 600 erhalten und dürfen niemals committed werden.
Die vollständige Komponenten-, Release- und Node-Anleitung steht in
docs/self-hosting.md und nach der Anmeldung im Panel
unter Dokumentation → Self-Hosting & Nodes.
Eine bestehende All-in-one-Installation wird mit dem interaktiven Assistenten aufgeteilt. Er kann ein bereits gebautes externes Frontend verbinden, ausgewählte Gameserver vollständig zwischen Nodes kopieren und die Backend-Control-Plane fehlersicher auf einen frischen Linux-Server verschieben:
sudo /opt/msm/helper-scripts/migrate-panel-components.shDer Assistent behält Quelldaten und eine deaktivierte Quell-Control-Plane als
Rollback-Basis. DNS beim externen Anbieter und die einmalige Owner-Freigabe
eines neuen Agents bleiben bewusste Sicherheitsgrenzen. --dry-run führt eine
echte, rein lesende Vorprüfung der gewählten Ziele durch. Die kurze,
verbindliche Anleitung steht in docs/self-hosting.md.
sudo bash /opt/msm/update.shDer Updater erstellt vor Schemaänderungen einen verifizierten PostgreSQL-Dump (bei Altinstallationen eine bytegenau geprüfte SQLite-Sicherung), nimmt nur das Panel kurz in Wartung und meldet erst nach Agent- und Backend-Healthchecks Erfolg. Laufende Game-Server auf den Nodes werden nicht gestoppt.
Aktiviere Auto-Update in der Konfiguration:
# Bearbeite die .env-Datei:
nano /opt/msm/backend/.env
# Setze:
MSM_AUTO_UPDATE=true
# Starte den Timer:
sudo systemctl start msm-update.timer| Befehl | Was er tut |
|---|---|
sudo systemctl status msm-panel |
Zeigt ob das Panel läuft |
sudo systemctl restart msm-panel |
Startet das Panel neu |
sudo journalctl -u msm-panel -f |
Zeigt Live-Logs |
sudo bash /opt/msm/update.sh --check-only |
Prüft ob ein Update verfügbar ist |
sudo ufw status |
Zeigt Firewall-Regeln |
Das Panel nutzt folgende Ports:
| Port | Protokoll | Zweck |
|---|---|---|
| 80 | TCP | HTTP (wird zu HTTPS weitergeleitet) |
| 443 | TCP | HTTPS (Panel-Webinterface) |
| 27015-27999 | UDP/TCP | Game-Server (automatisch vergeben) |
Game-Server-Ports müssen über 1024 liegen. Rootless Docker bindet keine
privilegierten Ports; MSM setzt dafür bewusst keinen setcap-Workaround.
Bei einer Re-Installation stoppt der Installer alte rootful MSM-Container
(msm-srv-*) und weist auf die Rootless-Migration hin. Die alten Container
werden nicht automatisch gelöscht.
Die Game-Server-Ports werden automatisch aus der Range 27015-27999 vergeben. Du musst nichts manuell einstellen.
┌─────────────────────────────────────────┐
│ Browser (HTTPS) │
│ → panel.deinserver.de │
└────────────┬────────────────────────────┘
│
┌────────────▼────────────────────────────┐
│ Caddy (Reverse-Proxy + TLS) │
│ → Port 443 │
└────────────┬────────────────────────────┘
│
┌────────────▼────────────────────────────┐
│ FastAPI Backend (Python) │
│ → Port 8000 (nur localhost) │
│ → PostgreSQL (nur Loopback) │
│ → Redis (optional) │
└────────────┬────────────────────────────┘
│
┌────────────▼────────────────────────────┐
│ Local Node Agent + Rootless Docker │
│ → Conan Exiles UE5 (Linux native) │
│ → DayZ (Linux native) │
│ → Jeder Server eigener Linux-User │
└─────────────────────────────────────────┘
- HTTPS via Caddy (automatische Zertifikate von Let's Encrypt)
- Firewall (UFW) — nur Ports 22, 80, 443 und Game-Range offen
- Fail2ban — blockiert Brute-Force auf SSH und Panel
- JWT-Auth mit kurzlebigen Tokens (15 Min) + Refresh (30 Tage)
- CSRF-Schutz für alle state-changing Requests
- Rate-Limiting — 10/min für Auth, 100/min für alles andere
- 2FA via TOTP + Backup-Codes
- Email-Verifikation für Setup und neue Accounts
- Resource-Limits — CPU/RAM/Disk pro Game-Server begrenzbar
MSM besitzt ein vollständiges Backup-System mit lokalen Backups und verschlüsseltem Off-Site-Upload zu S3-kompatiblem Object Storage. Alle kryptografischen Operationen laufen über den DIS Sidecar (@msdis/shield) mit AES-256-GCM und Argon2id-Key-Derivation. Das Panel selbst implementiert keine eigene Kryptografie (Zero-Knowledge-Prinzip).
- Server-Backups: lokales
tar.gzpro Game-Server + verschlüsselter Streaming-Upload zu S3 - Panel-Backups:
pg_dumpder MSM-Datenbank + Konfigurationsdateien (.env,install.shetc.), verschlüsselter S3-Upload - Local + S3-Mirror: lokale Backups für schnelle Recovery, S3 für verschlüsselten Off-Site-Schutz
- Best-Effort S3: schlägt der S3-Upload fehl, bleibt das lokale Backup erhalten und blockiert nicht
- Retention: konfigurierbare Aufbewahrung für lokale und S3-Backups (Server und Panel separat)
- Scheduler: automatische Server- und Panel-Backups inklusive S3-Upload
In den Einstellungen → Backup kannst du S3-kompatiblen Object Storage einrichten:
- S3-Endpoint (z.B. MinIO, Hetzner S3, AWS S3)
- Access Key & Secret Key — verschlüsselt via DIS mit AAD-Domain-Separation gespeichert
- Bucket & Region
S3-Credentials und das Backup-Passwort werden nie im Klartext gespeichert. Sie liegen verschlüsselt in den panel_settings und sind nur über den DIS Sidecar entschlüsselbar.
Das Backup-Passwort wird für die Verschlüsselung der S3-Uploads verwendet. Es wird ebenfalls via DIS verschlüsselt in den panel_settings abgelegt. Ohne DIS Sidecar und das gespeicherte Passwort lassen sich S3-Backups nicht entschlüsseln.
| Server-Backup | Panel-Backup | |
|---|---|---|
| Inhalt | Game-Server-Daten (tar.gz) |
MSM-Datenbank (pg_dump) + Konfigurationsdateien |
| Lokal | ja | ja |
| S3-Upload | ja (verschlüsselt) | ja (verschlüsselt) |
| Retention | konfigurierbar | konfigurierbar |
| Automatisch | ja (Scheduler) | ja (Scheduler) |
Für bestehende lokale Server-Backups gibt es zudem eine Upload-to-Cloud-Funktion, um ältere Backups nachträglich verschlüsselt zu S3 hochzuladen.
Server-Backups:
- Wiederherstellung aus lokalem Backup
- Wiederherstellung aus S3 (Download + Entschlüsselung + Restore)
Panel-Backups:
- Restore startet über die PanelBackups-Seite (Prepare-Restore)
- Das Panel generiert ein Bash-Restore-Skript, das folgendes ausführt:
- Panel stoppen
- Datenbank aus
pg_dumpwiederherstellen - Konfigurationsdateien zurückspielen
- Panel neu starten
- Einstellungen → Backup-Tab: S3-Konfiguration und Backup-Passwort verwalten
- Backups-Seite: S3-Status-Badges und Cloud-Icons pro Backup
- PanelBackups-Seite: Panel-Backups erstellen, löschen, Restore vorbereiten und Einstellungen verwalten
Wenn du Auto-Update aktiviert hast, passiert folgendes:
- Ein systemd-Timer prüft alle 24h GitHub Releases
- Wenn eine neue Version verfügbar ist, wird sie automatisch installiert
- Vor dem Update wird ein Backup erstellt
- Bei Fehlern wird automatisch zum alten Stand zurückgerollt
- Der Admin sieht im Dashboard, dass ein Update verfügbar ist
Für die Zukunft ist eine Tauri-Desktop-App geplant. Sie nutzt denselben GitHub-Release-Feed für Updates.
- GitHub Issues: github.com/einmalmaik/maunting-server-manager/issues
- Logs prüfen:
sudo journalctl -u msm-panel -n 100 - Update manuell:
sudo bash /opt/msm/update.sh
MIT License — siehe LICENSE