Separate deployment decision trees for PHP, Laravel and Node.js.
All three can be “web apps,” yet their production needs differ. Laravel adds queues, schedulers and migrations; Node.js has different process and health behavior; classic PHP depends on document root and PHP-FPM decisions.
Do not run database migrations on every container restart. Multiple replicas can race the same migration; run it as a single controlled deployment step.
Choose deployment strategy by framework. Define build command, start process, port, health endpoint, persistent paths and secrets per app so Coolify becomes a reliable deployment layer rather than just a container launcher.
Choose deployment strategy by framework. Define build command, start process, port, health endpoint, persistent paths and secrets per app so Coolify becomes a reliable deployment layer rather than just a container launcher.
Deploy PHP, Laravel and Node.js on Coolify with runtime-specific patterns for build/Dockerfile, environment, queue, scheduler, health checks, migrations and rollback.
Separate deployment decision trees for PHP, Laravel and Node.js.
An application health endpoint should pass before a new container serves traffic.
Use platform environment/secret management instead of committing `.env`.
Rollback to the previous release must be tested as carefully as forward deployment.
Before adding a project to Coolify, document which process listens on a port, which paths are persistent and where the build happens.
| App | Build | Process | Persistent data | ||
|---|---|---|---|---|---|
| Classic 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 | Usually stateless; app-specific |
Legacy PHP applications vary between project root, `public_html` and `/public`. A wrong document root can expose source files.
Blindly coupling queue workers to the web-container lifecycle can interrupt jobs during deployment. Preserve single-instance behavior where required by the scheduler.
php artisan aboutphp artisan config:cachephp artisan route:cachephp artisan queue:restartphp artisan migrate --forceFrameworks such as Next.js or Vite may bake some variables into bundles at build time; they do not behave like runtime secrets. Document the distinction.
node --versionnpm --versionnpm cinpm run buildnpm run startA liveness endpoint says the process is alive; readiness says it can serve traffic. A database outage does not necessarily require both to fail identically.
| Endpoint | Purpose | DB check |
|---|---|---|
| /live | Is process alive? | Usually no |
| /ready | Can serve traffic? | If required |
An expand/contract sequence—backward-compatible schema, new app, later cleanup—reduces downtime and rollback risk.
Returning to an old container does not automatically reverse database migrations or user uploads. Release rollback and data rollback are separate procedures.
Plan Eka Sunucu VPS resources around PHP/Laravel/Node.js build time, queues and database load.
Primary documentation and technical references used by this guide.
Continue with related infrastructure and implementation guides.
Coolify App Deploy
In production they usually benefit from separate lifecycle and scaling from the web process.
The app should listen on the port expected by the platform/environment; a public host port is usually unnecessary behind the platform proxy.
Persistent uploads should use a volume or object storage rather than an ephemeral redeployed container filesystem.
No. Container/image rollback and database rollback are separate operations; design migrations accordingly.