MeshCentral installieren: self-hosted mit Docker, Let's Encrypt und Härtung (2026)

MeshCentral nicht selbst betreiben? WZ-IT installiert und betreibt MeshCentral als Managed-Plattform mit Monitoring, Updates und Backups. Zu MeshCentral Managed Hosting

MeshCentral ist eine kostenlose, quelloffene Web-Plattform zur Fernverwaltung von Rechnern: Remote-Desktop, Terminal und Dateiverwaltung im Browser, über einen Server, den Sie selbst betreiben (docs.meshcentral.com). Die offizielle Installationsanleitung setzt auf npm, Docker-Anleitungen im Netz verweisen auf unterschiedliche Community-Images. Dieser Leitfaden zeigt den Weg mit dem offiziellen Container-Image, TLS über die eingebaute Let's-Encrypt-Unterstützung und einer gehärteten Grundkonfiguration. Stand Oktober 2026 ist MeshCentral 1.2.6 (24.09.2026) aktuell.

Inhaltsverzeichnis

• Was ist MeshCentral?
• MeshCentral oder RustDesk?
• Offizielles Docker-Image statt Community-Images
• Installation mit Docker Compose
• config.json mit Let's Encrypt
• Let's Encrypt: erst Staging, dann Produktion
• Mit Reverse Proxy davor
• Agents ausrollen
• Härtung
• Backup und Updates
• Wartungsstand und Risiko
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was ist MeshCentral?

MeshCentral besteht aus einem Server auf Node.js-Basis und einem Agent auf den verwalteten Geräten. Der Agent baut eine ausgehende Verbindung zum Server auf und hält sie offen; Techniker melden sich in der Web-Konsole an und arbeiten von dort mit Remote-Desktop, Terminal und Dateiübertragung (MeshCentral Guide). Auf der Technikerseite ist nur ein Browser nötig.

MeshCentral steckt auch in anderen Werkzeugen: Tactical RMM nutzt es für die Fernsteuerung (Take Control) und den Echtzeit-Dateibrowser und installiert dafür eine eigene MeshCentral-Instanz mit.

MeshCentral oder RustDesk?

Beide sind selbst hostbar, lösen aber unterschiedliche Aufgaben. Der ausführliche Vergleich mit Apache Guacamole und NetBird steht in TeamViewer-Alternative self-hosted.

Für eine feste Flotte aus Arbeitsplätzen und Servern passt MeshCentral, für Ad-hoc-Support bei wechselnden Gegenübern passt RustDesk.

Offizielles Docker-Image statt Community-Images

Das offizielle Image wird aus dem MeshCentral-Repository gebaut und liegt in der GitHub Container Registry unter ghcr.io/ylianst/meshcentral (Container-Doku, Paketseite):

Images auf Docker Hub wie typhonragewind/meshcentral stammen aus der Community; auf Docker Hub gibt es kein Image unter ylianst. Für Produktion empfiehlt sich ein fester Versions-Tag statt latest, damit Updates bewusst erfolgen.

Eine Eigenheit des offiziellen Images: Die Umgebungsvariablen wie HOSTNAME oder ALLOW_NEW_ACCOUNTS greifen nur mit DYNAMIC_CONFIG=true, und das ist standardmäßig aus (Docker-README). Ohne vorhandene config.json kopiert der Container beim ersten Start eine Vorlage, in der NewAccounts auf true steht (entrypoint.sh). Die config.json sollten Sie deshalb selbst schreiben, bevor der Container zum ersten Mal startet.

Installation mit Docker Compose

Das folgende Setup folgt dem offiziellen Compose-Beispiel: Ports 80 und 443 werden direkt veröffentlicht, MeshCentral terminiert TLS selbst und holt das Zertifikat über die eingebaute Let's-Encrypt-Unterstützung. Abweichungen vom Beispiel: fester Versions-Tag, Bind-Mounts statt benannter Volumes (einfacher zu sichern und zu bearbeiten) und ein eigenes Verzeichnis für Sitzungsaufzeichnungen. meshcentral-web ist nur für eigene Themes nötig und entfällt hier (Docker-README).

services:
  meshcentral:
    image: ghcr.io/ylianst/meshcentral:1.2.6
    container_name: meshcentral
    restart: unless-stopped
    environment:
      - DYNAMIC_CONFIG=false
    volumes:
      - ./meshcentral-data:/opt/meshcentral/meshcentral-data
      - ./meshcentral-files:/opt/meshcentral/meshcentral-files
      - ./meshcentral-backups:/opt/meshcentral/meshcentral-backups
      - ./meshcentral-recordings:/opt/meshcentral/meshcentral-recordings
    ports:
      - "80:80"
      - "443:443"

Ablauf:

1. DNS-Eintrag mesh.example.com auf die öffentliche IP des Servers setzen und nach außen TCP 80 und 443 öffnen. Port 80 ist Pflicht: Let's Encrypt prüft die Domain per HTTP-01-Challenge, die MeshCentrals HTTP-Server auf Port 80 beantwortet (SSL/Let's Encrypt). Die Doku empfiehlt, den DNS-Eintrag schon über einen Tag vor der Zertifikatsanfrage zu setzen; letsdebug.net prüft die Domain vorab (Let's-Encrypt-Abschnitt).
2. Verzeichnis meshcentral-data anlegen und die config.json aus dem nächsten Abschnitt hineinlegen, zunächst mit "production": false.
3. docker compose up -d und das Log verfolgen: docker compose logs -f meshcentral. MeshCentral fordert das Zertifikat beim Start an und startet nach Erhalt automatisch neu; die Anfrage kann einige Minuten bis einige Stunden dauern (Let's-Encrypt-Abschnitt).
4. Sofort https://mesh.example.com aufrufen und das erste Konto anlegen. Es wird automatisch Server-Administrator (Quickstart). Der Browser warnt in dieser Phase: Zuerst liefert MeshCentral ein selbstsigniertes Zertifikat aus, danach eines der Staging-CA, deren Wurzelzertifikate in keinem Browser hinterlegt sind (Let's Encrypt Staging).
5. Auf das Produktionszertifikat umstellen, siehe Let's Encrypt: erst Staging, dann Produktion.

Schritt 4 ist zeitkritisch: Solange noch kein Konto existiert, lässt MeshCentral die Registrierung auch bei newAccounts: false zu (webserver.js). Wer den Server erst später freigeben will, setzt vorher userAllowedIP auf die eigene IP (siehe Härtung).

config.json mit Let's Encrypt

Die Werte folgen dem Let's-Encrypt-Abschnitt der Doku und dem Konfigurationsschema. Groß- und Kleinschreibung der Schlüssel spielt keine Rolle (Guide, Annex 1); letsEncrypt ist die Schreibweise des Schemas, die Doku schreibt letsencrypt.

{
  "$schema": "https://raw.githubusercontent.com/Ylianst/MeshCentral/master/meshcentral-config-schema.json",
  "settings": {
    "cert": "mesh.example.com",
    "WANonly": true,
    "port": 443,
    "redirPort": 80,
    "selfUpdate": false,
    "autoBackup": {
      "backupIntervalHours": 24,
      "keepLastDaysBackup": 10,
      "zipPassword": "ein-langes-zufaelliges-passwort"
    }
  },
  "domains": {
    "": {
      "title": "Fernwartung",
      "newAccounts": false,
      "passwordRequirements": { "force2factor": true },
      "sessionRecording": { "protocols": [1, 2, 5], "index": true }
    }
  },
  "letsEncrypt": {
    "email": "[email protected]",
    "names": "mesh.example.com",
    "rsaKeySize": 3072,
    "production": false
  }
}

Änderungen an der config.json wirken erst nach einem Neustart (docker compose restart meshcentral).

Let's Encrypt: erst Staging, dann Produktion

Zu viele fehlerhafte Anfragen an den Produktionsserver führen zu einer längeren Sperre; die Doku verlangt deshalb, zuerst erfolgreich ein Staging-Zertifikat zu holen (Schema, Let's-Encrypt-Abschnitt). Zeigt der Browser unter https://mesh.example.com ein von der Staging-CA signiertes Zertifikat, folgt die Umstellung:

1. docker compose stop meshcentral
2. Die Let's-Encrypt-Dateien in meshcentral-data entfernen. Die Doku nennt den Ordner letsencrypt; aktuelle Versionen legen die Dateien in meshcentral-data/letsencrypt-certs ab (letsencrypt.js).
3. In der config.json "production": true setzen.
4. docker compose start meshcentral

Das Produktionszertifikat kommt laut Doku nach einigen Minuten bis einigen Stunden. MeshCentral prüft das Zertifikat danach alle 24 Stunden und fordert ein neues an, sobald weniger als 45 Tage Restlaufzeit bleiben (letsencrypt.js); certbot oder ein Neustart-Hook sind nicht nötig. Port 80 muss dafür dauerhaft erreichbar bleiben. Schlägt die Anfrage fehl, fällt MeshCentral auf das selbstsignierte Zertifikat zurück (Let's-Encrypt-Abschnitt).

Läuft die DNS-Zone über Cloudflare, muss der Proxy-Modus für den Eintrag aus sein; sonst bleibt der Remote-Desktop schwarz (FAQ).

Mit Reverse Proxy davor

Sollen nginx, Traefik oder HAProxy vor MeshCentral stehen, etwa weil weitere Dienste auf demselben Server Port 443 nutzen, gilt die offizielle Anleitung: nginx, Traefik, HAProxy. Der Proxy terminiert dann TLS, und in der config.json kommen tlsOffload, aliasPort und certUrl hinzu (TLS-Offloading). Wegen der dauerhaften WebSocket-Verbindungen der Agents braucht der Proxy lange Timeouts.

Agents ausrollen

Agents werden in der Web-Konsole pro Gerätegruppe erzeugt: Gruppe anlegen, „Add Agent“ wählen, Betriebssystem und Installationsart festlegen (im Hintergrund, interaktiv oder beides) (MeshCentral Guide).

• Windows: Die heruntergeladene .exe enthält laut Doku keine sensiblen Daten und kann auf vielen Rechnern wiederverwendet werden. Unbeaufsichtigt installiert sie sich mit -fullinstall (kopiert den Agent nach C:\Program Files\Mesh Agent, registriert und startet den Dienst; MeshAgent-Quelle). Damit lässt sie sich über vorhandene Softwareverteilung ausrollen; einen eigenen GPO- oder MSI-Weg für den Agent beschreibt die offizielle Doku nicht.
• Linux und BSD: Statt einer Binärdatei liefert die Konsole ein Installationsskript, das die passende Agent-Variante selbst wählt.
• macOS: Bildschirmaufnahme, Dateizugriff und Tastatur-/Maussteuerung müssen unter Datenschutz & Sicherheit manuell freigegeben werden (FAQ).

# Windows, als Administrator; Dateinamen an den Download anpassen
.\meshagent.exe -fullinstall

Virenscanner, die unbekannte Dateien zur Analyse einreichen, führen den Agent mitunter in ihrer Sandbox aus; dann tauchen fremde Geräte in der Konsole auf (FAQ). agentAllowedIPNewAgents (seit 1.2.6, PR #8140) begrenzt neue Agent-Registrierungen auf bekannte Adressbereiche.

Härtung

• Keine Selbstregistrierung: newAccounts: false und das erste Konto sofort anlegen, siehe Installation.
• 2FA erzwingen: MeshCentral unterstützt TOTP-Apps, YubiKey-OTP und Duo (Zwei-Faktor-Doku, Security); passwordRequirements.force2factor macht 2FA für alle Konten verpflichtend. Wichtig: Nach einer Passwort-Wiederherstellung per E-Mail ist 2FA wieder aus; das E-Mail-Konto ist damit Teil der Angriffsfläche.
• Anmeldung nur aus dem VPN: userAllowedIP beschränkt die Anmeldung von Benutzern auf Adressbereiche, agentAllowedIP dasselbe für Agents (Schema). Bewährt ist: Agents verbinden sich über das Internet, die Web-Konsole ist nur aus einem Mesh-VPN wie NetBird erreichbar. Steht ein Reverse Proxy davor, muss tlsOffload auf dessen IP zeigen, damit MeshCentral den Forwarded-Headern vertraut und die echte Quell-IP sieht. Grundlagen zu NetBird: Was ist NetBird?.
• Login-Drosselung: maxInvalidLogin sperrt standardmäßig nach 10 Fehlversuchen in 10 Minuten; seit 1.2.6 auch nach IP-Bereich oder Benutzername.
• Sitzungsaufzeichnung: sessionRecording wie oben; Aufnahmen enthalten Bildschirminhalte und gehören in ein Lösch- und Zugriffskonzept. Mehr dazu in Privileged Access Management und Session-Recording.
• Rechte in Gerätegruppen: Techniker nur in den Gruppen berechtigen, die sie betreuen; Server-Administratorrechte für wenige Konten.

Self-Hosting allein macht die Fernwartung nicht DSGVO-konform. Rechtsgrundlage, Auftragsverarbeitung mit Dienstleistern und Regeln zu Aufzeichnung und Protokollierung bleiben Aufgabe des Betreibers, siehe Fernwartung und DSGVO. Dieser Abschnitt ist allgemeine Information, keine Rechtsberatung.

Backup und Updates

Backup. Gesichert werden müssen meshcentral-data und meshcentral-files (Backup-Doku). meshcentral-data enthält die Server-Zertifikate, an die sich installierte Agents binden: Geht der Ordner verloren, verbinden sich die Agents nicht mit einem neu installierten Server, auch nicht unter demselben Namen. Wer eine Kopie davon besitzt, kann den Server imitieren; das Backup gehört deshalb verschlüsselt an einen zweiten Ort. autoBackup erstellt standardmäßig alle 24 Stunden ein ZIP in meshcentral-backups und hält 10 Tage vor; mit zipPassword ist es passwortgeschützt (Schema). Bei MongoDB kommt ein mongodump dazu.

Updates. Im Container nicht die eingebaute Update-Funktion nutzen, sondern das Image tauschen (Container-Doku): Tag in der compose.yaml auf die neue Version setzen, dann

docker compose pull
docker compose up -d

Releases und Changelogs stehen auf GitHub. 1.2.6 enthielt unter anderem Sicherheitskorrekturen, etwa die Durchsetzung der Berechtigung „keine Dateien“ beim Datei-Download und eine Signaturprüfung der Agents auch bei gesetztem ignoreAgentHashCheck (Release Notes). Für abgeschottete Netze wird das Image außerhalb gezogen und per docker save und docker load übertragen.

Wartungsstand und Risiko

MeshCentral wird aktiv entwickelt: 2026 sind bis Oktober zwölf Releases erschienen, von 1.1.56 (21.01.2026) bis 1.2.6 (24.09.2026) (Releases). Getragen wird die Entwicklung inzwischen vor allem von einer Person: Von den 373 Commits im Jahr 2026 (Stand 14.10.2026) stammen 188 vom Community-Maintainer si458, 13 von Gründer Ylian Saint-Hilaire, überwiegend Versions-Commits (Commit-Historie). Ein kommerzieller Hersteller mit Support-Vertrag steht nicht dahinter.

Für den Betrieb heißt das: Releases beobachten, Updates zeitnah einspielen und einen Ausweichweg kennen, falls die Pflege nachlässt. Die Apache-2.0-Lizenz erlaubt Forks; Agents und Server bleiben auch ohne neue Releases funktionsfähig, erhalten dann aber keine Sicherheitskorrekturen mehr.

Unser Vorgehen bei WZ-IT

Wir installieren und betreiben MeshCentral als Managed-Plattform: bei WZ-IT, in Ihrer Cloud, On-Premise oder hybrid, mit Monitoring, Updates, Backups von meshcentral-data und einem geplanten Wiederanlauf. Für die Web-Konsole setzen wir den Zugriff bevorzugt hinter ein Mesh-VPN wie NetBird, damit sie nicht öffentlich erreichbar ist.

Braucht ein Unternehmen mehr als Fernsteuerung, etwa Fernwartung von Anlagen mit Rollen, Audit und Mandanten, bauen wir das als Remote-Management-Plattform oder als Fernwartungssoftware für Maschinen und Standorte.

Weiterführende Guides

• TeamViewer-Alternative self-hosted - RustDesk, MeshCentral, Guacamole und NetBird im Vergleich
• Was ist NetBird? - Mesh-VPN, um die Konsole aus dem Internet zu nehmen
• Privileged Access Management und Session-Recording
• Fernwartung und DSGVO - Auftragsverarbeitung bei Fernwartung
• Fernwartung ohne VPN-Client

MeshCentral aufsetzen oder bestehenden Betrieb übergeben? Lernen Sie uns kennen oder sehen Sie sich MeshCentral Managed Hosting an.