Compare
dply vs Laravel Forge
Forge provisions and deploys to a server you own, which runs and bills around the clock. dply runs the same Laravel app as containers on a global edge network, with the database, Valkey and queue workers attached as managed resources. There is no server to size or patch, and an idle app sleeps.
How the pieces map
| Laravel Forge | dply |
|---|---|
| Server + site | A container app, detected from the repo |
| Deploy script | A generated image, or your own Dockerfile |
| php artisan migrate in the deploy script | Migrations when a container starts, or on demand |
| Daemons running queue:work or Horizon | Queue workers that autoscale on queue depth |
| Scheduler cron | The Laravel scheduler, every minute |
| MySQL or Postgres on the server | Managed Postgres, MySQL or MongoDB |
| Redis on the server | dply Valkey |
| Reverb daemon | Realtime (WebSockets for broadcasting) |
| Server size | Instance size, sleep after idle, minimum instances |
What to plan for on dply
- No SSH
- Containers have no shell. Use the logs and the database tools (Migrate, Seed, Connect).
- No persistent disk
- Files written at runtime are lost on restart. Put uploads in object storage.
- Cold starts
- An idle app sleeps after 5 minutes by default. Set a minimum instance to keep one warm.
When Laravel Forge is the better fit
- You need SSH, a persistent disk, or software installed on the box itself.
- You want one fixed server bill no matter how much or little traffic arrives.