FEATURES / DEPLOYMENTS

Zero-downtime deploys, from a git push.

Push to your repo and Depfloy builds a new release on your server, then flips a symlink to make it live. A failed build never gets linked, and rolling back is the same flip in reverse.

Deployments
Last 7 days: 19 deploys · 18 succeeded · 1 failed
STATUS PROJECTSERVERBRANCH / SHAINITIATED BY DURATION
Success
acme-app-staging
Laravel
acme-staging-1
develop 16c6653
Try the new onboarding flow
System 1m 9s
Success
acme-app
Laravel
acme-web-1
main 9c0382a
Add per-seat billing to the subscription API
System 1m 14s
Success
acme-web
Next.js
acme-web-2
main 0a19dbb
Rewrite the pricing page copy
System 1m 58s
Success
acme-docs
Nuxt
acme-web-1
main bae5587
Document the backup restore flow
System 1m 36s
Success
acme-status
React Router
acme-web-2
main c498cde
Show maintenance windows on the timeline
Priya Raman 1m 3s
Failed
acme-app
Laravel
acme-web-1
main acd9b30
Bump Laravel to 12.31
System 48s
HOW IT WORKS

The release is built next to the live one — never on top of it.

STEP 1
You push

A push to the connected branch triggers the deploy. Or trigger one manually — from the dashboard, the CLI, or an agent over MCP.

$ git push origin main
STEP 2
Your server builds

The new release is built in its own directory while the current one keeps serving. Your per-project deploy script runs here.

releases/
2026-07-25_1417/ ⟳ building
2026-07-25_0912/ ● live
STEP 3
The symlink flips

When the build succeeds, current is re-pointed at the new release. The swap is atomic — no request ever hits a half-deployed app.

current → releases/2026-07-25_1417

A failed build leaves the current release selected

For release-based deployments, a build failure before switchover leaves the current release selected. Shared configuration, database changes and server resource pressure can still affect it.

deploy acd9b30 ✕ failed at build step 3/5
composer install: ext-intl missing
current → releases/2026-07-24_0917 (unchanged)

Roll back to an earlier deployment

PHP-FPM projects can reuse a target release that is still on disk. Node.js, Octane and targets missing from disk use a normal deployment at the selected commit. Rollback does not reverse database migrations.

2026-07-25_1402 1 hour ago live
2026-07-24_0917 1 day ago ⟲ roll back
2026-07-23_1130 2 days ago keep
acme-web-1 · Queue Concurrent deploys 2
acme-app main a1c93f4 Deploying 0:41
acme-docs main 7d2e105 Deploying 0:12
acme-shop main 3fb8c22 Queued waiting for a slot
CONCURRENT DEPLOYS

Ten pushes at once start ten builds. You can put a ceiling on that.

Depfloy starts every deploy the moment it arrives. Ten projects on one server and ten pushes in the same minute means ten builds competing for the same memory — a small box can run out and take the sites already running there down with it. So you can set a ceiling per server: two at a time, and the rest wait their turn.

A ceiling per server
The number lives on the server, so the 8 GB machine can build three at once while the 2 GB box beside it is held to one. Leave it empty and that server has no ceiling, which is where every server starts and where it stays until you say otherwise. On every plan.
Deploys past the ceiling still run
A deploy that arrives while the server is full is marked Queued and dispatched the moment a slot frees, in the order it arrived. You do not push again. Ten projects behind a ceiling of two deploy all ten, two at a time.
One project deploys once at a time
Ceiling or no ceiling, a second deploy of a project that is already deploying waits behind the first. Both would write the same release directory and flip the same symlink, so whichever finished last would decide what is live.

A ceiling spends the memory you have more carefully; it does not add any. On a box that struggles with one build, two at a time is two slow builds.

BEYOND THE PUSH

Deploys are step one. The app has to keep running.

Per-project deploy scripts
Migrations, cache warms, asset builds — your commands, run on every release.
Scheduled jobs
Cron entries managed from the dashboard, per project.
Background workers
Queue workers that are supervised, restarted on deploy, and visible next to the code they run.
SummaryEnv Commands SchedulerJobsLogs
Deploy script · acme-app
composer install --no-dev
php artisan migrate --force
php artisan config:cache
npm ci && npm run build
SCHEDULER
artisan schedule:run * * * * *
WORKERS
queue:work ● 2 running
FAQ

Deploy questions

What happens if several projects on the same server deploy at once? +
They all start. Depfloy does not cap concurrent deploys unless you ask it to — set a maximum per server and deploys arriving past it are marked Queued, then run in turn as slots free up. Nothing is refused, and nothing needs pushing again. The setting is on every plan.
Can the same project deploy twice at the same time? +
No, at any ceiling. A second deploy of a project that is already deploying waits behind the first: both would write the same release directory and flip the same symlink, so whichever finished last would decide what is live.
What counts as zero-downtime? +
The new release is built in its own directory while the old one serves every request. Going live is an atomic symlink flip — there is no window where the app is stopped, rebuilding, or half-copied.
What if the build fails halfway? +
The symlink never moves, so the failed release never receives a request. You get the build log; the previous release keeps serving until you push a fix.
How fast is a rollback? +
PHP-FPM projects can reuse a target release that is still on disk. Node.js, Octane and targets missing from disk use a normal deployment at the selected commit. Rollback does not reverse database migrations.
Does this work the same for PHP and JavaScript apps? +
Yes. The release model is identical across all 10 frameworks — Laravel, Next.js, Nuxt, Astro, Remix, React Router, WordPress, Symfony, Statamic and PHP. Build steps differ per framework; the flip does not.

Your next push can deploy itself.

7 days free, no credit card. Works with all 10 frameworks.