IDE-Anbindung
Deine IDE läuft auf deinem eigenen Rechner, der Code aber in den Containern des Projekts auf dem Server. Damit beides zusammenfindet, hat jedes Projekt einen Bereich IDE, in dem alles zum Kopieren bereitsteht: SSH-Verbindung, Interpreter-Pfade, Pfad-Mappings, Debugger-Ports und JDBC-URLs. Hier steht, wofür diese Werte gut sind.
Der SSH-Server
Abschnitt betitelt „Der SSH-Server“Envoryx hat einen eigenen SSH-Server auf Port 2222; veröffentliche den Port oder nutze die eigene IP des Containers. Über ihn kommen Remote-Interpreter, SFTP und auch dein eigenes Terminal ins Projekt.
Der Benutzername ist der Slug des Projekts, zum Beispiel shop. Damit landest du im Anwendungscontainer: PHP, wenn das Projekt PHP hat, sonst Python, dann Go, dann Ruby, dann Java, dann .NET, dann Node.js. Hat ein Projekt mehrere Runtimes und du willst eine bestimmte, nimm shop.php, shop.python, shop.go, shop.ruby, shop.java, shop.dotnet oder shop.node.
Als Passwort dient ein API-Token aus Einstellungen → API-Tokens & MCP - oder du hinterlegst unter Einstellungen → SSH-Schlüssel deinen öffentlichen Schlüssel und brauchst gar kein Passwort. Jede Sitzung ist ein docker exec als Projektbesitzer in den Container; bis zu einer Shell auf dem Host selbst kommt man darüber nicht. Per SFTP siehst du zwei Ordner: /var/www/html ist das Projekt, /home/envoryx ein dauerhaftes Home, in dem Tool-Caches und IDE-Helfer liegen können. Ein SFTP-Client startet im Projekt, wie ein ssh-Login. JetBrains-IDEs starten dagegen im Home, weil sie ihre Helfer (~/.phpstorm_helpers und Co.) dort auspacken, wo sie starten, und die gehören nicht in dein Repository.
Shells, Interpreter und Debugger brauchen ein laufendes Projekt. Befehle landen im Audit-Log, und zu viele falsche Tokens sperren eine Adresse für fünf Minuten aus; was dabei zählt, steht unter Ausgesperrt?.
Remote-Interpreter
Abschnitt betitelt „Remote-Interpreter“Mit einem Remote-Interpreter startet deine IDE Tests, Paketmanager und Framework-Befehle direkt im Container, also genau mit den Versionen, die das Projekt benutzt. So richtest du ihn ein:
| IDE | Wo | Werte |
|---|---|---|
| PhpStorm | Settings → PHP → CLI Interpreter → … → From Docker, Vagrant, VM, WSL, Remote… → SSH | PHP /usr/local/bin/php, Helpers /home/envoryx/.phpstorm_helpers, Mapping Projektordner → /var/www/html |
| WebStorm | Settings → Languages & Frameworks → Node.js (in neueren Versionen JavaScript Runtime) → Node interpreter → Add… → SSH | Node /usr/local/bin/node, Projektpfad /var/www/html |
| PyCharm | Settings → Project → Python Interpreter → Add Interpreter → On SSH… | Interpreter /var/www/html/.venv/bin/python, Projektpfad /var/www/html |
| GoLand, RubyMine | der SSH-Remote-Interpreter bzw. die SSH-Konfiguration der IDE | Host, Port und Benutzer aus dem Bereich IDE (<slug>.go, <slug>.ruby), Projektpfad /var/www/html |
| IntelliJ IDEA, Rider | File → Remote Development → SSH (JetBrains Gateway, siehe unten) | Host, Port und Benutzer aus dem Bereich IDE; öffnet /var/www/html mit JDK, Maven und Gradle bzw. dem .NET-SDK aus dem Container |
| VS Code | Remote-SSH: ssh -p 2222 shop@<host> |
/var/www/html als Remote-Ordner öffnen |
Eine statische Seite hat keinen Anwendungscontainer, also gibt es für sie keine Shell und keinen Remote-Interpreter. An die Dateien kommst du trotzdem per SFTP, und der Bereich IDE zeigt dir die SFTP-Werte dafür.
Debugger
Abschnitt betitelt „Debugger“Jede Runtime hat ihren eigenen Debugger, und jeder wird an einer etwas anderen Stelle eingeschaltet:
| Runtime | Debugger | Einschalten | Standard-Port |
|---|---|---|---|
| PHP | Xdebug | Laufzeit → PHP → Xdebug | 9003 (Xdebug verbindet sich zu deiner IDE) |
| Node.js | Node-Inspector | Node.js-Inspector-Port veröffentlichen beim Node-Dienst | 9229 |
| Python | debugpy | debugpy-Port veröffentlichen; die Anwendung startet debugpy selbst | 5678 |
| Go | Delve | Mit Delve debuggen - der Server läuft unter einem headless Delve | 2345 |
| Ruby | rdbg (debug-Gem) | Mit rdbg debuggen - der Server läuft unter rdbg --open |
12345 |
| Java | JDWP | Mit JDWP debuggen - die JVM des Servers startet mit dem Agent | 5005 |
| .NET | vsdbg (VS Code), Riders eigener | für VS Code nichts einzuschalten - es startet den Debugger über SSH; Rider braucht Portweiterleitung (JetBrains Gateway) | keiner |
Xdebug funktioniert andersherum als die anderen: Es meldet sich bei deiner IDE. Es läuft im Step-Debugging-Modus (debug,develop, start_with_request=yes) und ruft den Rechner an, von dem die Anfrage kam. Hinter dem Proxy kommt diese Adresse aus X-Forwarded-For; klappt das nicht, nimmt es den Entwicklerrechner aus Einstellungen → Domains & HTTPS → Projekt-Links & Entwicklerrechner und danach host.docker.internal. In der IDE mappst du /var/www/html auf deinen Projektordner. PhpStorm findet seinen Server über PHP_IDE_CONFIG=serverName=<Projekt-Host>, das Envoryx im PHP-Container setzt, also benenne den Server genau so; die php.xml im Bereich IDE enthält außerdem den Port, den der Browser benutzt (443 hinter dem HTTPS-Proxy). Mehr dazu auf der PHP-Seite. Und schalte Xdebug nach dem Debuggen wieder ab - es macht PHP spürbar langsamer.
Debugger, die deine IDE anrufen (Xdebug, der Python Debug Server von PyCharm), brauchen eine Adresse dafür. Jeder Runtime- und Worker-Container löst host.docker.internal zum Docker-Host auf, mit der IDE auf dem Docker-Host klappt dieser Name also einfach. Deine Workstation ist host.docker.internal aber nicht. Läuft die IDE auf einem anderen Rechner, den der Server nicht erreicht, leitest du den Port mit dem SSH-Login des Projekts weiter (ssh -R 9003:localhost:9003 für Xdebug) und nimmst localhost: bei Xdebug im Feld Debugger-Host (optional) der PHP-Karte, bei PyCharm als Host im pydevd-pycharm-Snippet.
Delve: GoLand verbindest du über Run → Edit Configurations → Go Remote, VS Code mit type: go, request: attach, mode: remote und einem substitutePath von deinem Ordner auf /var/www/html - Host und Port stehen im Bereich IDE. Baut air den Server neu, startet es auch Delve neu, und die Debug-Sitzung endet; verbinde dich wieder, dann greifen deine Breakpoints wie vorher. Ist der Go-Server nicht eingeschaltet, wird nur der Port veröffentlicht, und der wartet auf ein dlv test --headless --listen=:2345 ./pkg/..., das du im Terminal startest.
rdbg: In VS Code hängst du dich mit der Erweiterung VSCode rdbg Ruby Debugger an (type: rdbg, request: attach, debugPort: "<host>:<port>", localfsMap: "/var/www/html:${workspaceFolder}"), im Terminal geht es mit rdbg -A <host> <port>. Ohne Ruby-Server wartet der Port auf so etwas wie rdbg --open --host=0.0.0.0 --port=12345 -c -- bin/rails test, gestartet im Ruby-Terminal.
JDWP: IntelliJ IDEA verbindest du über Run → Remote JVM Debug, VS Code mit dem Extension Pack for Java (type: java, request: attach, hostName, port) - Host und Port stehen im Bereich IDE. Ohne Java-Server wartet der Port auf eine JVM, die du im Java-Terminal mit -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 startest. Mehr auf der Java-Seite.
.NET: .NET braucht keinen Debug-Port. Die C#-Erweiterung von VS Code startet Microsofts vsdbg über pipeTransport per SSH im Container, nachdem du ihn einmal mit vsdbg installieren im Bereich IDE installiert hast. Rider und Visual Studio nehmen Attach to Remote Process über SSH; Rider braucht dafür JetBrains Gateway für dieses Projekt erlauben, weil sein Debugger SSH-Portweiterleitung nutzt. Weil die Pipe keine Passwortabfrage beantworten kann, hinterlegst du vorher deinen öffentlichen Schlüssel unter Einstellungen → SSH-Schlüssel. Eine fertige launch.json steht auf der .NET-Seite. Sobald dotnet watch eine Änderung per Hot Reload übernommen hat, kann sich kein Debugger mehr an diesen Prozess hängen (Fehler 0x80131c69). Starte dann das Projekt neu oder speichere eine Änderung, die Hot Reload nicht übernehmen kann, und hänge dich danach an.
RubyMine ist ein Sonderfall. Sein Ruby remote debug spricht nur ruby-debug-ide, nicht das debug-Gem, und kann sich deshalb nicht an rdbg hängen. In RubyMine richtest du stattdessen den Ruby-Container als SSH-Remote-Interpreter ein (Benutzer <slug>.ruby) und debuggst mit dem eigenen Debugger von RubyMine. Den rdbg-Schalter brauchst du dafür nicht, wohl aber JetBrains Gateway für dieses Projekt erlauben, denn der Debugger von RubyMine leitet einen Port über SSH weiter.
JetBrains Gateway
Abschnitt betitelt „JetBrains Gateway“Mit Gateway läuft das komplette IDE-Backend auf dem Server, auf deinem Rechner nur noch ein schlanker Client. Das ist angenehm auf einem langsamen Laptop, kostet aber den Server Ressourcen - deshalb ist es aus, bis du es pro Projekt einschaltest: IDE → JetBrains Gateway für dieses Projekt erlauben aktiviert SSH-Port-Forwarding in den Container. Das IDE-Backend, das Gateway lädt (etwa 1,5 GB pro IDE-Version), bleibt im Home des Projekts, jedes Projekt lädt also sein eigenes. Wo alle vertrauenswürdig sind, lädt Einstellungen → Paket-Cache → IDE-Backends zwischen Projekten teilen es nur einmal für alle (/config/jetbrains/RemoteDev/dist); dann kann jedes Projekt mit Gateway die geteilten Backends verändern, ein Developer eines Projekts könnte also die IDE eines anderen verändern. Index-Caches, lokaler Verlauf und Beitritts-Links bleiben immer im jeweiligen Projekt, damit kein Projekt den Quelltext eines anderen sieht.
Das Backend läuft als Projektbesitzer im Anwendungscontainer und will beim Indizieren 2-4 GB RAM plus CPU. Solange du dich nicht verbindest, läuft nichts, aber auf einem kleinen NAS würde ich es trotzdem auslassen. Envoryx liefert selbst keine JetBrains-Software aus; Gateway ist kostenlos, und wer sich verbindet, braucht eine gültige Lizenz für die IDE.
Zum Verbinden wählst du in Gateway SSH → New connection, trägst die Werte aus dem Bereich IDE ein, suchst dir die IDE aus und nimmst /var/www/html als Projektverzeichnis. Bist du fertig, schließ das Projekt in Gateway oder klick auf IDE-Backend stoppen, dann wird der Speicher wieder frei. Änderst du die Runtime, wird der Container neu erstellt, und das Backend ist damit auch beendet.
Ein Projekt über SFTP öffnen
Abschnitt betitelt „Ein Projekt über SFTP öffnen“Für die Dateien eines Projekts brauchst du keine Netzwerkfreigabe. Öffne es als SFTP-Deployment in PhpStorm und Co. oder mit VS Code Remote-SSH - gleicher Host, Port und Zugang wie oben, Remote-Pfad /var/www/html.