Deployment und Remote Hosts in PhpStorm: wann nützlich, wann nicht

1. Was PhpStorm Deployment wirklich ist – und was nicht

Der Begriff "Deployment" in PhpStorm ist irreführend, wenn man ihn mit modernen CI/CD-Pipelines vergleicht. PhpStorm-Deployment ist im Kern ein Datei-Synchronisations-Tool: Es überträgt lokale Dateien per SFTP, FTP oder FTPS auf einen Remote-Server. Es kennt keine Rollback-Mechanismen, keine Deployment-Hooks, kein Zero-Downtime-Deployment und keine Health-Checks. Was es kann: eine lokale Datei bei Speicherung automatisch auf den Server hochladen, Verzeichnisse manuell synchronisieren und Unterschiede zwischen lokalen und Remote-Dateien anzeigen.

Das macht es für bestimmte Szenarien sehr wertvoll: Wenn ein Entwickler auf einem Remote-Server arbeitet, auf dem kein lokales Docker-Setup vorhanden ist, wenn ein Staging-Server schnell mit einer korrigierten Datei aktualisiert werden soll oder wenn ein Legacy-Projekt noch kein Git-basiertes Deployment hat. Für Produktionsserver mit Magento 2 oder anderen komplexen CMS-Systemen, die nach jedem Deployment Cache-Leeren, Compiler-Läufe und Datenbankmigrationen erfordern, ist PhpStorm-Deployment allein nicht ausreichend – es fehlt der Orchestrierungsschritt nach dem Upload.

2. Remote Host und Deployment-Profil einrichten

Die Konfiguration beginnt unter Settings → Build, Execution, Deployment → Deployment → + (Add). Als Typ wählt man SFTP für passwortbasierte oder schlüsselbasierte SSH-Verbindungen. Im Reiter Connection gibt man Hostname, Port (22 für SSH), Benutzername und den Pfad zum privaten SSH-Schlüssel an. PhpStorm unterstützt sowohl RSA- als auch Ed25519-Schlüssel und liest die SSH-Konfiguration aus ~/.ssh/config, was bedeutet, dass bereits definierte SSH-Aliases direkt nutzbar sind – einfach den Alias-Namen als Hostname eintragen.

Für Passwort-Authentifizierung kann PhpStorm das Passwort im System-Keychain speichern, sodass es nicht bei jedem Upload neu eingegeben werden muss. Bei schlüsselbasierter Authentifizierung mit Passphrase integriert sich PhpStorm mit dem SSH-Agent, wenn einer läuft. Das Root Path-Feld im Connection-Reiter definiert den Basispfad auf dem Server, der als Ausgangspunkt für alle relativen Pfade in den Deployment Maps gilt. Bei Webserver-Setups ist das üblicherweise /var/www/html oder der DocumentRoot des VHosts.

# ~/.ssh/config — PhpStorm reads this automatically
# Use Host alias directly as "Host" in PhpStorm deployment settings

Host staging-mironsoft
  HostName staging.mironsoft.de
  User deploy
  Port 22
  IdentityFile ~/.ssh/id_ed25519_deploy
  ServerAliveInterval 60
  ServerAliveCountMax 3
  AddKeysToAgent yes

Host prod-mironsoft
  HostName mironsoft.de
  User deploy
  Port 2222
  IdentityFile ~/.ssh/id_ed25519_deploy
  ForwardAgent no
  # Production: never use automatic upload from PhpStorm
  # Always deploy via CI/CD pipeline (GitHub Actions / GitLab CI)

3. Deployment Maps: lokale Pfade auf Remote-Pfade abbilden

Im Reiter Mappings des Deployment-Profils definiert man, welche lokalen Verzeichnisse auf welche Remote-Verzeichnisse abgebildet werden. Eine Mapping-Regel besteht aus drei Feldern: Local path, Deployment path (relativ zum Root Path) und Web path (für den Browser). Das Web-Path-Feld ist wichtig für das Feature "Open in Browser": PhpStorm berechnet daraus die URL der aktuell geöffneten Datei und kann sie direkt im Browser öffnen.

Für Magento-2-Projekte, die einen src/-Unterordner als Magento-Root verwenden, sieht das Mapping typischerweise so aus: Local path /home/mir/development/mironsoft/src → Deployment path /var/www/html. Mehrere Mappings in einem Profil erlauben unterschiedliche Sync-Regeln für verschiedene Verzeichnisse. So kann man das app/code/-Verzeichnis synchronisieren, aber vendor/ und var/ explizit ausschließen, was sowohl Uploadzeit spart als auch verhindert, dass versehentlich vendor-Dateien überschrieben werden.

4. Manuell, On Save oder On Explicit Save

PhpStorm bietet drei Upload-Modi: Manuell (Upload to im Kontextmenü), Upload changed files automatically to the default server (On Save) und Always upload. Der On-Save-Modus ist der bequemste, aber auch der gefährlichste für geteilte Server: Jedes Speichern einer Datei löst sofort einen Upload aus, auch wenn die Datei noch nicht fehlerfrei ist. Eine halbfertige Refaktorierung, die lokal compiliert, aber remote einen Syntaxfehler erzeugt, landet sofort auf dem Server und kann die Anwendung brechen.

Die sicherere Alternative ist der manuelle Upload oder Upload on Explicit Save, bei dem der Upload nur nach einem expliziten Ctrl+Shift+S statt dem normalen Ctrl+S ausgelöst wird. Für Staging-Server, wo ein Entwickler allein arbeitet und schnell Änderungen testen will, ist On Save akzeptabel. Für jeden Server, auf dem mehrere Entwickler arbeiten oder auf dem Live-Traffic läuft, ist manueller Upload die einzig vertretbare Option. PhpStorm zeigt im Status-Bereich oben rechts den Upload-Fortschritt und eventuelle Fehler an.

5. Exclude-Regeln: was niemals hochgeladen werden darf

Die Excluded Paths in den Deployment-Einstellungen sind eine der wichtigsten Sicherheitsfunktionen. Unter Settings → Deployment → Options → Excluded paths definiert man Pfade, die von der Synchronisation ausgeschlossen werden – auf beiden Seiten oder nur lokal. Für ein Magento-2-Projekt sind mindestens folgende Pfade auszuschließen: vendor/ (Remote wird durch Composer verwaltet), var/ (Cache, Logs, Session-Dateien), pub/static/ (Static Content gehört deployt, nicht synchronisiert) und alle .env-Dateien, die Produktionskonfiguration enthalten.

Eine weiterer kritischer Ausschluss: Das .git/-Verzeichnis sollte niemals auf den Server hochgeladen werden. PhpStorm schließt es standardmäßig nicht aus, daher muss man es explizit in die Excluded Paths eintragen. Das Deployment von .git/ auf einen Webserver ist ein Sicherheitsrisiko, weil der Quellcode über öffentliche URLs abrufbar wird, wenn der Web-Server das Verzeichnis nicht explizit blockiert. Die Exclude-Regeln unterstützen Wildcards, sodass man Muster wie *.log oder *cache* definieren kann.

<?php
// PhpStorm Deployment: Excluded Paths für Magento 2
// Settings → Build, Execution, Deployment → Deployment → [Profile] → Excluded Paths

/*
Lokale Pfade, die NIEMALS hochgeladen werden dürfen:

Deployment Path (relative to root):    Reason
/vendor/                               Managed by Composer on server
/var/                                  Cache, logs, sessions — server-specific
/pub/static/                           Deploy via setup:static-content:deploy
/.git/                                 Security: source code exposure
/.env                                  Server-specific environment config
/env/                                  Docker environment files
/node_modules/                         Build artifacts, server not needed
/pub/media/ (optional)                 Large binary files — use CDN sync instead

Recommended: always use SSH key auth, never password for deployment profiles.
Recommended: mark production server profile as "disabled" to prevent accidents.
Set default server to Staging only — never Production.
*/

// After uploading PHP files to Magento staging, always run:
// bin/magento cache:flush
// bin/magento setup:di:compile (if DI changes)
// The PhpStorm deployment does NOT handle post-deploy steps automatically.

6. Remote File Browser: Dateien direkt auf dem Server bearbeiten

Der Remote File Browser (View → Tool Windows → Remote Host) zeigt die Verzeichnisstruktur des konfigurierten Remote-Hosts direkt in PhpStorm. Man kann Dateien vom Server öffnen, lokal bearbeiten und mit einem Klick zurückspeichern. Das ist nützlich für schnelle Korrekturen auf Staging-Servern, ohne eine vollständige lokale Kopie des Projekts zu haben, oder für das Lesen von Remote-Log-Dateien.

Eine wichtige Einschränkung: Wenn man eine Datei aus dem Remote File Browser öffnet und lokal bearbeitet, ist diese lokale temporäre Kopie nicht mit dem Git-Repository verknüpft. Änderungen, die nur remote gespeichert werden, gehen beim nächsten Deployment aus dem Repository verloren. Wer Dateien über den Remote File Browser bearbeitet, muss sicherstellen, dass die Änderungen auch in das lokale Repository übernommen werden. Für diesen Workflow ist es besser, die Datei lokal zu bearbeiten und über das Deployment-Profil hochzuladen, statt direkt im Remote-Browser zu editieren.

7. Risiken des automatischen Uploads – und wie man sie mindert

Automatic Upload ist komfortabel und birgt gleichzeitig drei ernste Risiken. Erstens kann eine syntaktisch fehlerhafte PHP-Datei auf den Server hochgeladen werden, bevor der Entwickler den Fehler bemerkt – bei Magento 2 führt das zu einem komplett unbrauchbaren Shop. Zweitens kann ein Entwickler unbeabsichtigt eine Konfigurationsdatei mit lokalen Entwicklungsdaten hochladen, die Production-Einstellungen überschreibt. Drittens sind gleichzeitige Uploads mehrerer Entwickler auf denselben Server ein Rezept für inkonsistente Zustände.

Die wichtigsten Maßnahmen zur Risikominderung: (1) Automatic Upload nur für Staging-Server aktivieren, nie für Produktion. (2) PhpStorm-Deployment niemals als einzigen Deployment-Weg für Produktion verwenden. (3) Excluded Paths vollständig konfigurieren, bevor das Profil aktiviert wird. (4) Regelmäßige Synchronisation prüfen: Tools → Deployment → Compare with Deployed Version zeigt Unterschiede zwischen lokal und remote und deckt auf, wenn jemand direkt auf dem Server editiert hat.

8. Wann CI/CD und Git-Deployment besser sind

Git-basierte Deployments über CI/CD-Pipelines sind für alle Szenarien die bessere Wahl, wo mehr als eine Person am Projekt arbeitet, wo Produktionsserver betroffen sind oder wo das Deployment mehr Schritte umfasst als den reinen Dateiupload. Eine GitHub-Actions-Pipeline kann nach einem Push auf den Hauptbranch automatisch Composer-Install, Static-Content-Deploy, DI-Compile und Cache-Flush ausführen – ohne manuellen Eingriff und mit vollständigem Audit-Trail. Das ist nicht nur sicherer, sondern auch reproduzierbarer.

Für Magento 2 ist der Deployment-Prozess komplex genug, dass er immer über eine Pipeline oder ein Deploy-Skript laufen sollte: CSS-Build, Static Content Deploy mit den richtigen Locales und Themes, DI Compile, Cache Flush – in genau dieser Reihenfolge. PhpStorm Deployment übernimmt keine dieser Schritte. In der Praxis ist PhpStorm Deployment am nützlichsten für PHP-Projekte ohne Kompilierungsschritt – klassische Laravel- oder Symfony-Apps ohne Asset-Pipeline, wo ein Dateiupload tatsächlich ausreicht.

9. Deployment-Methoden im Vergleich

Die Wahl des Deployment-Wegs hängt von der Projektgröße, dem Team und der Server-Infrastruktur ab. Eine direkte Gegenüberstellung hilft bei der Entscheidung.

Für Einzelentwickler, die an einem einfachen PHP-Projekt ohne Kompilierungsschritte auf einem Staging-Server arbeiten, ist PhpStorm SFTP eine schnelle und praktische Lösung. Sobald das Projekt wächst, ein Team hinzukommt oder die Produktionsumgebung Kompilierungsschritte erfordert, ist der Wechsel zu einer CI/CD-Pipeline notwendig. Die gute Nachricht: Beide Methoden können parallel existieren. PhpStorm SFTP für schnelle Staging-Tests, CI/CD-Pipeline für saubere Produktions-Deployments.

10. Zusammenfassung

PhpStorm Deployment ist kein vollständiger Deployment-Mechanismus, sondern ein Datei-Synchronisations-Tool per SFTP. Für einfache PHP-Projekte ohne Kompilierungsschritte und für Einzelentwickler auf Staging-Servern ist es eine bequeme und schnelle Lösung. Für Magento 2, Teams und Produktionsserver reicht es nicht aus, weil es Post-Deploy-Schritte, Rollback und Audit-Trail nicht abdeckt. Die Excluded Paths sind keine optionale Konfiguration, sondern Sicherheitspflicht: vendor/, var/, pub/static/, .git/ und Umgebungsdateien müssen immer ausgeschlossen sein.

Die beste Strategie für Magento-2-Projekte: PhpStorm SFTP für schnelle Staging-Tests aktivieren (manueller Upload, nie Automatic Upload), parallel eine CI/CD-Pipeline für alle Produktions-Deployments einrichten. So nutzt man die Stärke beider Ansätze ohne die Risiken des automatischen Uploads auf Produktionsservern. Der Schlüssel ist, dass das Team genau versteht, welcher Weg für welche Umgebung gilt – und dass Produktions-Deployments niemals über einen IDE-Button ausgelöst werden.

11. FAQ: Deployment und Remote Hosts in PhpStorm

PhpStorm-Deployment und Remote-Hosts sind wertvolle Werkzeuge für bestimmte Szenarien, ersetzen aber keine vollständige CI/CD-Pipeline. Nutze diese Funktionen gezielt dort, wo schnelles Testen auf Staging-Systemen wichtiger ist als vollständige Automatisierung.

Die richtige Kombination aus lokalem Deployment für schnelle Iteration und einer vollständigen CI/CD-Pipeline für Produktivsysteme ist der Schlüssel zu einem effizienten und sicheren Deployment-Workflow in PHP-Projekten.