Türkei (Türkisch)
Germany (German)
Worldwide (English)
Separate Deployment-Entscheidungen für PHP, Laravel und Node.js.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Alle drei können Web-Apps sein, benötigen produktiv aber Unterschiedliches: Laravel braucht Queue/Scheduler/Migration, Node.js hat eigenes Process-/Health-Verhalten, klassisches PHP hängt stark von Document Root und PHP-FPM ab.
DB-Migration nicht bei jedem Container-Restart automatisch ausführen. Mehrere Replicas können konkurrieren; als kontrollierten Deployment-Schritt ausführen.
Deployment-Strategie nach Framework wählen. Build-Befehl, Startprozess, Port, Health-Endpoint, persistente Pfade und Secrets pro App definieren, damit Coolify eine zuverlässige Deployment-Schicht wird.
Deployment-Strategie nach Framework wählen. Build-Befehl, Startprozess, Port, Health-Endpoint, persistente Pfade und Secrets pro App definieren, damit Coolify eine zuverlässige Deployment-Schicht wird.
PHP, Laravel und Node.js auf Coolify runtime-spezifisch deployen: Build/Dockerfile, Env, Queue, Scheduler, Healthcheck, Migration und Rollback.
Separate Deployment-Entscheidungen für PHP, Laravel und Node.js.
Ein App-Health-Endpoint sollte vor Traffic-Freigabe bestehen.
Plattform-Env/Secret-Management statt `.env` im Repository nutzen.
Rollback auf vorheriges Release genauso testen wie Forward-Deployment.
Vor dem Hinzufügen zu Coolify dokumentieren: welcher Prozess hört auf welchem Port, welche Pfade sind persistent, wo findet Build statt.
| App | Build | Prozess | Persistente Daten | ||
|---|---|---|---|---|---|
| Klassisches PHP | Composer/Assets optional | Nginx/Apache + PHP-FPM | uploads | ||
| Laravel | Composer + Frontend | Web + Queue + Scheduler | storage/uploads | ||
| Node.js | Node.js | Node.js | npm/pnpm/yarn build | node/pm2/framework server | Meist stateless; app-spezifisch |
Legacy-PHP nutzt unterschiedliche Roots wie Projektwurzel, `public_html` oder `/public`. Falscher Document Root kann Quellcode exponieren.
Queue Worker nicht blind an Web-Container-Lifecycle koppeln; Deployments können Jobs unterbrechen. Scheduler bei Bedarf single-instance betreiben.
php artisan aboutphp artisan config:cachephp artisan route:cachephp artisan queue:restartphp artisan migrate --forceFrameworks wie Next.js/Vite können Variablen beim Build ins Bundle schreiben; das ist nicht dasselbe wie Runtime-Secrets. Unterschied dokumentieren.
node --versionnpm --versionnpm cinpm run buildnpm run startLiveness zeigt Prozessleben, Readiness Traffic-Bereitschaft. Bei DB-Ausfall müssen beide nicht gleich reagieren.
| Endpoint | Zweck | DB-Prüfung |
|---|---|---|
| /live | Lebt der Prozess? | Meist nein |
| /ready | Kann Traffic bedienen? | Bei Bedarf ja |
Expand/Contract—kompatibles Schema, neue App, spätere Bereinigung—reduziert Downtime- und Rollback-Risiko.
Zum alten Container zurückzukehren macht DB-Migrationen oder Uploads nicht automatisch rückgängig. Release- und Data-Rollback sind getrennt.
Eka-Sunucu-VPS-Ressourcen nach PHP/Laravel/Node.js Build-Zeit, Queues und Datenbanklast planen.
Primärdokumentation und technische Referenzen dieses Leitfadens.
Mit passenden Infrastruktur- und Implementierungsleitfäden fortfahren.
Coolify App Deploy
Produktiv ist ein separater Lifecycle und Scaling vom Webprozess meist kontrollierter.
Die App sollte auf dem von Plattform/Environment erwarteten Port hören; ein öffentlicher Host-Port ist hinter dem Plattform-Proxy meist unnötig.
Persistente Uploads gehören auf Volume oder Object Storage statt ins ephemere Container-Dateisystem.
Nein. Container-/Image-Rollback und DB-Rollback sind getrennte Vorgänge; Migrationen entsprechend planen.