Eternal Cloud

Die Eternal Cloud ist ein eigener Node als Ersatz für CloudNet. Sie steckt im API-Jar (EternalApi-<ver>.jar) und wird in api.yml eingeschaltet (siehe Installation). Sie startet Proxy- und Spielserver aus Templates, verwaltet Server-Versionen und JDKs. Alles Weitere – Tasks, Gruppen, Templates, Versionen, Java, Plugins – läuft im Dashboard unter Cloud.

Umgebungen und Software

Quellen u. a.: PaperMC Fill (Paper, Folia, Velocity, Waterfall), Purpur-API, Mojang (Vanilla), SpigotMC-Jenkins (BungeeCord), mcjars.app (Spigot, Pufferfish, Leaf, Fabric, Quilt, NeoForge, Forge, Sponge, Limbo), GitHub-Releases (PowerNukkitX, WaterdogPE).

Tasks, Gruppen, Templates

Statisch vs. dynamisch

• Dynamischer Service: Ordner cloud/services/<Name>/, wird bei jedem Start aus den Templates gebaut und nach dem Stopp gelöscht.
• Statischer Service: Ordner cloud/static/<Task>/<Name>/, bleibt erhalten (wichtig für Welten!). Templates nur beim ersten Start, außer ein Eintrag ist alwaysCopy. Im Dashboard unter Services → „Statische Services" mit Dateibrowser.

Setup-Modus (dynamische Tasks)

Dynamische Server (Lobby, Minispiele …) starten jedes Mal frisch aus dem Template. Zum Aufbauen gibt es unter Cloud → Tasks → Task den Setup-Modus:

1. Setup starten: Ein zusätzlicher Server <Task>-Setup-1 startet aus den Templates des Tasks. Er behält seinen Ordner, läuft im Wartungsmodus (nur mit eternal.cloud.maintenance) und ist kein Fallback. Die normalen Services laufen weiter.
2. Aufbauen: mit /server <Task>-Setup-1 drauf, bauen, Plugins einstellen, z. B. den Lobby-Spawn setzen.
3. Setup abschließen: Der Server speichert, stoppt, und sein Ordner (Welten, Plugin-Einstellungen) wird ins Template kopiert. Logs, Server-Jar, Crash-Reports und die Eternal-Datenbank bleiben draußen. Auf Wunsch starten die laufenden Services danach neu.
4. Verwerfen stoppt den Setup-Server und löscht ihn, nichts wird übernommen.

Ziel ist das Template, das wie der Task heißt, sonst das letzte des Tasks. Bei mehreren Templates lässt es sich vorher wählen. Proxys, statische Tasks und Spielmodi (die haben ihr eigenes Setup) haben keinen Setup-Modus.

Versionen & Java

• Cloud → Java: JDKs installieren (Adoptium/Temurin). Der Node wählt beim Start automatisch ein passendes Java nach den Versions-Grenzen: 1.8–1.16 → 17 (das Eternal-Plugin braucht Java 17; Paper prüft dann seine Java-Version nicht), 1.17 → 16+, 1.18–1.20.4 → 17+, 1.20.5–1.21 → 21+, 26.x → 25+ (oder die Task-Vorgabe).
• Cloud → Versionen: Server-Software installieren. Paper-Jars werden einmal vorgepatcht (cache/, versions/, libraries/), ein Service-Start ist danach nur noch Kopieren.

Node: RAM-Budget und Neustart

Oben in der Cloud steht der RAM, den die laufenden Services belegen, neben dem Budget der Node. Mit eternal.web.cloud.manage passt du beides im Dashboard an:

• RAM-Budget: ein Klick auf die RAM-Anzeige. Das Budget gilt für alle Services zusammen, 0 = unbegrenzt. Es wirkt sofort: Neue Starts werden daran gemessen, laufende Services laufen weiter. Gespeichert wird es in der api.yml (cloud.max-memory-mb), es bleibt also auch nach einem Neustart.
• Node neu starten: startet API und Cloud neu. Alle Services dieser Node werden gestoppt, die Spieler fliegen raus, danach kommen die Services mit ihrer Mindestanzahl wieder. Das klappt nur, wenn die API unter einem Dienst-Manager läuft, also systemd mit Restart=always (wie in tools/api/eternal-api.service) oder Docker mit Restart-Policy. Erkennt das Dashboard keinen, warnt es vorher. Unter einem anderen Manager setzt du ETERNAL_SUPERVISED=1, dann entfällt die Warnung.

Smart-Skalierung

Im Task-Editor:

• preparedServices baut Service-Ordner vorab (Status PREPARED, kein JVM) – ein Start ist dann nur noch der JVM-Start.
• percentOfPlayersForNewService startet bei dieser mittleren Auslastung einen weiteren Service (Abstand über startDelaySeconds).
• autoStopEmptySeconds stoppt leere Extras, nie unter minServiceCount.
• replaceIngame: Services im Status INGAME zählen nicht zum Minimum, es wird nachgestartet.

Ingame-Status: /service ingame (Recht eternal.cloud.service) nimmt einen Service aus dem Fallback-Pool; /service lobby gibt ihn frei; /service extra <Text> setzt einen Status-Text.

Deployments & Inclusions

• Deployments: beim Stopp (oder per „Deploy" im Dashboard; vorher save-all) wird der Service-Ordner in angegebene Templates kopiert. Nie kopiert: server.jar, cache/, libraries/, versions/, logs/, session.lock, server.properties, Eternal-Datenbank; dazu eigene Ausschlüsse (ordner/, datei, *.log).
• Inclusions: URLs, die vor dem Start in den Service geladen werden (Karten-Zip, Plugin-Jar); cache hält sie unter temp/inclusions/.
• Nach dem Stopp löschen: relative Pfade, die vor den Deployments entfernt werden.

Cluster (mehrere Nodes)

Mehrere Rechner, ein Dashboard:

• Der Head ist der normale Node mit Dashboard und Datenbank. Er entscheidet, welcher Node welchen Service bekommt.
• Worker führen nur Services aus. Sie haben keinen eigenen HTTP-Port und kein Dashboard.

Einrichten:

1. Head: in seiner api.yml einschalten, dann die API neu starten. Das Cluster-Secret entsteht in cluster-secret.txt.

``yaml cluster: enabled: true role: head ``

1. Worker: auf dem neuen Rechner Java 21+ installieren und das API-Jar ablegen.
2. api.yml des Heads kopieren. Der Worker braucht dieselbe database (MySQL) und dasselbe internal.shared-secret, weil Tasks und Gruppen damit signiert in der Datenbank liegen.
3. Anpassen:
   • cloud.node-name
   • die Adressen (host-address, backend-address, public-address)
   • cloud.api-url: die API des Heads, so wie die Server sie erreichen
   • den Block aus Cloud → Nodes → Worker hinzufügen einfügen (mit Head-URL und Secret)
4. Starten, am besten als Dienst wie den Head. Der Worker erscheint unter Cloud → Nodes.

So verteilt der Head:

• Neue Services gehen auf den erlaubten Node mit dem meisten freien RAM-Budget. Welche Nodes erlaubt sind, steht im Task unter Nodes (leer = alle).
• Docker-Tasks gehen nur auf Nodes mit Docker.
• Statische Services bleiben auf dem Node, der ihren Ordner hat.
• Was der Worker selbst holt: Templates (nur geänderte, per Hash verglichen), cloud/Eternal.jar und fehlende Server-Versionen.
• Was zum Head zurückgeht: Deployments landen in den Templates des Heads, Dumps und Crash-Reports unter Cloud → Reports.
• Alles im Dashboard: Konsole, Befehle, Stop, Neustart, Kill und Dumps funktionieren für jeden Service wie bei einem lokalen.
• Spieler: Die Server auf Workern melden sich beim Head an. Proxys bekommen alle Backends mit der Backend-Adresse ihres Nodes.

Wenn ein Worker wegbricht:

• Seine Services bleiben 2 Minuten in der Liste, sie laufen ja vermutlich weiter.
• Kommt er zurück, gleicht der Head ab.
• Bleibt er weg, schreibt der Head die Services ab und startet Ersatz auf anderen Nodes.
• Startet ein Node nach einem Absturz neu, beendet er Server-Prozesse, die vom letzten Lauf übrig sind. Das gilt für jeden Node, auch ohne Cluster.

Cloud → Nodes zeigt alle Nodes mit RAM, Services, Docker, Adressen und Version. Dort setzt du das RAM-Budget eines Workers und entfernst getrennte Worker.

Docker-Services

Statt einer JVM auf dem Node läuft jeder Service eines Tasks in einem eigenen Docker-Container. Einstellen kannst du das im Task-Editor unter Ressourcen → Laufzeit: Docker-Container.

• Image: leer bedeutet eclipse-temurin:<Java>-jre. Die Java-Version kommt aus der Task-Vorgabe oder automatisch aus der Server-Version, z. B. 21 für 1.21.
• Eigenes Image: möglich, z. B. eclipse-temurin:21-jdk. Dann gehen auch Heap-Dumps.
• Ordner: Der Service-Ordner wird unter demselben Pfad eingebunden. Templates, Deployments, statische Services, Konsole, Befehle und Logs funktionieren wie gewohnt.
• Netz: Der Container nutzt das Host-Netz, der Server hört also auf dem Port, den der Node vergibt. Proxy und API erreichen ihn wie einen normalen Prozess.
• Sicherheit:
  • Der Container läuft als Service-Benutzer (run-as-user), ohne Linux-Capabilities und mit no-new-privileges.
  • Das Speicherlimit ist RAM + 25 % (mindestens + 256 MB).
  • Zugangsdaten gehen über eine Env-Datei, die nach dem Start gelöscht wird. Auf der Kommandozeile stehen sie nie.
• Aufräumen: Stop und Kill entfernen den Container. Bleibt nach einem Node-Absturz einer übrig, entfernt der Node ihn beim nächsten Start.

Speicherplatz

Eine volle Festplatte bricht alles: Welten speichern nicht mehr, und jede Konsole ist voller Fehler. Die Cloud passt darauf auf:

• Anzeige: Im Kopf von Cloud steht der freie Platz. Unter 5 GB wird er rot, dazu kommt ein Hinweis und alle 10 Minuten eine Warnung im Log.
• Unter 1 GB startet kein Service mehr, weder automatisch noch per Hand. Laufende Services laufen weiter.
• Aufräumen (stündlich, bei knappem Platz alle 5 Minuten): alte Logs (je 30 behalten), Spark-Temp-Dateien, Crash-Reports (je 10 behalten), Heap-Dumps (*.hprof) älter als ein Tag, alte Dateien im Temp-Ordner.
• Spark: Der mitgelieferte Profiler von Paper nimmt im Hintergrund dauernd auf. Die Cloud schaltet diese Hintergrund-Aufnahme aus (plugins/spark/config.json → backgroundProfiler: false). /spark profiler geht weiter. Steht der Schlüssel schon in der Datei, bleibt er unverändert.
• Was sonst Platz frisst (Backups, Welten, Datenbank), zeigt auf dem Server du -xh -d1 / | sort -h | tail.

Backups

Cloud → Backups sichert automatisch:

• die Cloud: Templates, Tasks, Gruppen, api.yml (Passwörter entfernt) und die H2-Datenbank
• jeden statischen Server (Welten!)

Zeitplan: Abstand und Uhrzeit, so viele Zips pro Ziel behalten, Ordner. Laufende Minecraft-Server speichern vorher und pausieren das Autosave, solange gezippt wird.

Pro Backup: herunterladen, vor dem Löschen schützen (Pin), wiederherstellen (der alte Stand bleibt als <Name>.before-restore) oder ein eigenes Zip hochladen.

Im Cluster: Statische Server auf Workern erscheinen mit @ <Node>.

• Sichern: Der Worker zippt den Ordner und schickt das Zip an den Head.
• Wiederherstellen: Der Worker holt das Zip vom Head und spielt es auf seinem Rechner ein.

Offsite (S3)

Unter Offsite (S3) wandert jedes neue Backup zusätzlich in einen S3-Bucket. Fällt der Rechner aus, liegen die Sicherungen dann woanders.

Verbindung testen schreibt, listet und löscht ein kleines Testobjekt. Der Secret-Key bleibt auf dem Node, das Dashboard zeigt nur ********. Hochgeladen wird gestreamt, ein großes Welt-Backup belegt also keinen Arbeitsspeicher (bis 5 GB pro Datei).

Metriken (Prometheus, InfluxDB)

Für Grafana & Co. in der api.yml des Heads:

metrics:
  enabled: true
  token: "lange-zufallszeichenkette"   # mindestens 16 Zeichen
  influx:                              # optional
    url: "http://127.0.0.1:8086"
    org: "meine-org"
    bucket: "eternal"
    token: "influx-token"
    interval-seconds: 30

• Prometheus: GET /metrics mit Authorization: Bearer <token> oder ?token=<token>.
• InfluxDB 2: Mit influx.url gehen dieselben Werte alle interval-seconds an die Write-API (Line-Protokoll).

Reports & Dumps

Cloud → Reports:

• Node-Report: ein Zip mit
  • Node-, Betriebssystem-, Java-, Speicher- und Plattenangaben
  • allen Services, Tasks und Gruppen (Passwörter, Tokens und Schlüssel maskiert)
  • dem Node-Log und den Threads der API
  • den letzten 1000 Konsolenzeilen jedes laufenden Services
• Crash-Report: entsteht automatisch, wenn ein Service beim Start stirbt oder mit einem Fehlercode endet (nicht bei Stop/Kill). Darin stehen die letzten Konsolenzeilen, logs/latest.log, die neuesten crash-reports/ und hs_err_pid*.log. Er entsteht vor dem Löschen des Ordners, die Beweise bleiben also erhalten.
• Thread-Dump und Heap-Dump: in der Konsole eines Services (Cloud → Service öffnen).
  • Der Thread-Dump zeigt, wo ein hängender Server feststeckt. Er läuft über jcmd des Service-Javas, sonst über SIGQUIT.
  • Der Heap-Dump (.hprof) ist so groß wie der belegte RAM, der Server hält beim Schreiben kurz an. Er braucht ein JDK, kein reines JRE.

Es bleiben die neuesten 30 Dateien. Download und Löschen gehen auf der Seite, das Recht ist eternal.web.cloud.manage (nur im Dashboard, nicht ingame).

Plugins von außen

Cloud → Plugins: Bibliothek cloud/plugins/ (Upload im Dashboard oder per SFTP). Das Dashboard liest plugin.yml/bungee.yml/velocity-plugin.json und zeigt Name, Version und die Templates, in denen das Plugin liegt. „Installieren" kopiert das Jar in die gewählten Templates und entfernt dort ältere Versionen. Der Katalog sucht auf Modrinth; ohne Suchbegriff zeigt er Empfehlungen in vier Gruppen:

Modrinth-Plugins: Version wählen → Herunterladen (ein Klick, landet in der Bibliothek) → in Templates installieren. In der Versionsliste ist die Version, die schon in der Bibliothek liegt, als In Bibliothek markiert, eine in Templates installierte als Installiert (mit den Templates).

Auto-Update

Die Leiste Auto-Update in der Bibliothek hält Plugins von Modrinth aktuell:

• Jede Jar der Bibliothek wird an ihrer Prüfsumme bei Modrinth erkannt, auch hochgeladene oder per URL geladene Modrinth-Builds. Jars, die Modrinth nicht kennt (PlotSquared, Citizens, eigene Builds), zeigen „ohne Auto-Update“.
• Geprüft wird alle 6 Stunden und mit Jetzt prüfen. Gesucht wird der neueste Build für dieselben Loader und die Minecraft-Version der Tasks, deren Templates das Plugin haben (Proxy-Plugins: jede Version). Ein Build ist nie instabiler als der installierte (Release bleibt Release).
• für alle Plugins schaltet Auto-Update für jedes Plugin ohne eigene Einstellung. Das Pfeil-Symbol in der Zeile schaltet es nur für dieses Plugin.
• Ohne Auto-Update zeigt die Zeile Update verfügbar mit dem Knopf Aktualisieren.
• Ein Update lädt die Jar von Modrinth, prüft die SHA-512-Prüfsumme und ersetzt sie in der Bibliothek und in allen Templates, die das Plugin hatten. Laufende Server behalten die alte Jar bis zum nächsten Neustart. Bis dahin steht „Update installiert · wirkt nach Neustart“.
• Verlauf listet jedes Update (wer, von → nach, Templates, Fehler) und ist durchsuchbar. Gespeichert wird alles in cloud/plugins/.updates.json.

Schilder, NPCs, Navigator

Lobbys bekommen die Service-Liste vom Node per Push – ohne Cloud bleibt das aus.

• Schilder: /cloudsign set <Task> auf ein Schild schauend (Recht eternal.cloud.signs). Die Services eines Tasks verteilen sich auf seine Schilder; Rechtsklick verbindet. Zustände SEARCHING, STARTING, EMPTY, ONLINE, FULL, INGAME, MAINTENANCE mit eigenen Frames; Layout im Dashboard → Cloud → Schilder & NPCs.
• NPCs: /cloudnpc create <Task> [Entity|PLAYER[:Skin]] [OPEN_MENU|CONNECT_BEST|CONNECT_LOWEST|CONNECT_RANDOM] (Recht eternal.cloud.npcs). Das NPC ist eingefroren, hat ein Hologramm (%task% %online% %services%), und ein Rechtsklick öffnet das Service-Menü oder verbindet.
  • Spieler-NPC mit Skin (Standard ab Minecraft 1.21.9/Paper, ein Mannequin; auf älteren Servern steht bis zum Update ein Villager da). Ohne Angabe bekommt das NPC den vorgeladenen Skin des Spielmodus — passend zum Task-Namen: Lobby, CityBuild, Survival, Farmwelt, SkyBlock, BedWars, SkyWars, SkyPvP, TTT, PvP, UHC, Build, Minigames, Event, Zombie. PLAYER:<Vorlage> wählt eine Vorlage (z. B. PLAYER:bedwars), PLAYER:<Spielername> den Skin eines beliebigen Spielers (z. B. PLAYER:Notch). Die Skins werden vom Server selbst geladen, sie erscheinen also auch im Offline-Modus hinter dem Proxy.
  • Im Dashboard (Cloud → Schilder & NPCs → NPC bearbeiten → Aussehen): Spieler oder Mob, dann Skin — passend zum Task, eine der Vorlagen oder ein Spielername, mit Kopf-Vorschau.
• Navigator (Lobby-Modul): server: "task:BedWars" statt eines festen Servernamens verbindet zum besten Service des Tasks.

Gespeichert wird alles netzwerkweit in der Datenbank, je Lobby-Servername.

Proxy-Anzeige

Netzwerk › Proxy-Anzeige (SyncProxy-Ersatz), gespeichert in der Datenbank, jeder Proxy liest alle 5 s nach – mit oder ohne Cloud-Node:

• MOTD-Frames mit Animation und eigenen Wartungs-MOTDs.
• Tab-Header/-Footer mit Platzhaltern %online% %max% %proxy% %player% %server% %task% %ping% %version% %time%.
• Slots: fester Wert, Listener-Limit oder Auto-Slot; voll → Kick-Text, eternal.cloud.joinfull darf trotzdem.
• Wartung mit Whitelist (Namen/UUIDs); eternal.cloud.maintenance kommt durch.

Module und Rechte je Task

Mit Cloud gelten zwei Einstellungen pro Task statt pro Server – neue Services eines Tasks starten so gleich richtig:

• Einrichtung › Module (eternal.web.modules): Module für alle Services eines Tasks. Ein einzelner Server mit eigener Einstellung (Liste „Einzelne Server“) geht seinem Task vor; ohne Cloud steht die Seite wie bisher im Dashboard unter Server › Module (pro Server).
• Ränge & Rechte › Rechte je Task (eternal.web.perms): Rechte, die ein Rang oder ein Spieler nur auf den Services eines Tasks hat (z. B. WorldEdit nur auf dem Bauserver).

Was wo steht

Läuft die Cloud (und darf das Konto sie nutzen), liegt alles, was zum Netzwerk gehört, im Cloud-Bereich: Logs, Live-Ansicht, Karte, Welten, Lobby-Karte, Welt-Regeln, Proxy-Anzeige, Module. Alles zu Rängen und Rechten hat einen eigenen Bereich Ränge & Rechte in der Leiste oben (/perms): Rollen & Rechte, Benutzer & Ränge, Rechte je Task, Rechte-Anfragen, Rechte bestellen und den Rechte-Katalog; alte Adressen (/admin/users …) leiten dorthin. Im Dashboard bleibt nur, was mit der Cloud nichts zu tun hat. Ohne Cloud gibt es keinen Cloud-Bereich – dieselben Seiten (Logs, Welten, Proxy-Anzeige …) stehen dann im Dashboard. Die Adressen (/cloud/logs …) sind in beiden Fällen gleich.

Logs, Farmwelten, Welt-Regeln

Diese Seiten gehen auch ohne Cloud-Node (dann im Dashboard):

• Betrieb › Live-Ansicht (eternal.web.live): Server live in 3D ansehen, siehe Replays.
• Betrieb › Logs (eternal.web.logs): API, Cloud-Node, Live-Konsolen und Log-Dateien aller Server. Pro Server werden die letzten 30 rotierten Logs aufgehoben (ältere löscht der Node stündlich automatisch, ebenso im Archiv gestoppter dynamischer Services); in der Übersicht stehen die letzten 7, der Link „ältere Logs laden“ öffnet die vollständige Liste.
• Welten › Farmwelten (eternal.web.farm), siehe Farmwelten.
• Welten › Lobby-Karte (eternal.web.lobbymap), siehe Lobby.
• Welten › Welt-Regeln (eternal.web.worldrules), siehe Einstellungen.

Ohne eternal.web.cloud stehen diese Seiten im Dashboard.

Player-Executor

Dashboard → Services → Spielername: verbinden, kicken, Nachricht schicken, Befehl ausführen. Der Node reicht das an alle angemeldeten Proxys weiter.

Ingame verwalten (/cloud)

Auf jedem Cloud-Service öffnet /cloud ein Menü mit dem Node-Status, allen Tasks und Services. Darin:

• Task: Service starten, min./max. Anzahl (Links +1, Rechts −1), RAM (±256 MB, Shift ±1024), max. Spieler, Wartung, Fallback, Offline, Version, löschen (Shift+Klick, dann bestätigen).
• Service: betreten, neu starten, stoppen (Shift = hart beenden), Konsole (Befehl in den Chat), letzte Log-Zeilen, offline schalten, Liste der Spieler.

Alles geht auch als Befehl: /cloud tasks | services | status, /cloud start <Task> [n], /cloud stop|restart|kill|join <Service>, /cloud cmd <Service> <Befehl>, /cloud log <Service> [Zeilen], /cloud task <Task> <min|max|memory|players|version|java|port|maintenance|fallback|static|offline> <Wert>, /cloud create <Name> <server|proxy|velocity|limbo> <Version> [RAM], /cloud delete <Task> confirm, /cloud groups | templates | versions [Software].

Der Push-Kanal (REST & WebSocket)

Alles unter /cloud/* (Dashboard-Token) bzw. /cloud/internal/* (Plugin-Secret). Live-Konsole über ws://…/cloud/ws/console/<Service>?token=…, Service-Push über /cloud/ws/services. Hinter Apache/nginx müssen diese WebSockets durchgereicht werden – die Snippets dafür stehen in der Installation.

Sicherheit

Die API läuft als root (JDK-Installation, niedrige Ports) und startet fremde Server-Jars. Das Wichtigste:

• Run-as-user: Game-Server laufen per runuser als cloud.run-as-user, nicht als root. Ohne gesetzten Benutzer verweigert der Node den Start (außer allow-root-services: true). Beim Einrichten unbedingt setzen – siehe Installation.
• Rechte sind faktisch Shell-Zugriff: eternal.web.cloud.manage und .console erlauben JVM-Flags, Plugins und Konsole als Service-Benutzer – nur an Owner geben (siehe Rechte).
• Netzwerk: nur der Proxy-Port gehört nach außen. Backends binden auf 127.0.0.1 mit online-mode=false und dürfen nie aus dem Internet erreichbar sein.
• Signierte Konfiguration: Task-/Gruppen-Rows in der DB sind HMAC-signiert; ein DB-Schreiber kann keine JVM-Flags oder Inclusions einschleusen.
• Pro Service ein Token statt des Netzwerk-Schlüssels; Downloads nur über HTTPS mit Prüfsumme; api.yml wird 600 geschrieben.

Rechte

eternal.web.cloud (ansehen), eternal.web.cloud.manage (ändern, starten, stoppen, installieren), eternal.web.cloud.console (Konsole + Befehle), eternal.web.cloud.java (JDKs), eternal.cloud.maintenance (Wartung betreten). Vollständig unter Rechte.

Grenzen

• Worker brauchen dieselbe MySQL wie der Head. Mit H2 bleibt die Cloud auf einem Node.
• Das Eternal-Plugin läuft auf Spigot/Paper 1.8.8 bis 26.x und braucht Java 17 oder neuer. Der Node startet 1.8–1.16 deshalb automatisch mit Java 17 – außer in der Task steht eine feste ältere Java-Version, dann lädt das Plugin nicht (siehe Versionen).

Weiter

• Installation & Einrichtung – von Grund auf aufsetzen.
• Auto-Updates – das Plugin-Jar in den Templates aktuell halten.