Deployments

A deployment is a single, successful build of your project's code at a particular Git commit. This page covers everything about deployments — how to trigger one, what happens during a build, how Depfloy queues concurrent pushes, how to roll back, and what to do when a deployment goes wrong.

For the broader concept of projects and deployments, see Projects and Deployments.

How a deployment is triggered

Two ways:

• Automatic — when you create a project in Depfloy, a webhook is registered with your Git provider. Tick Enable Auto Deploy on the project (during create, or later under Settings) and every push to the configured branch triggers a deployment.
• Manual — click Deploy on the project's Summary view, or use the API.

Deployment lifecycle

A deployment moves through these states:

1. Created — the request was recorded.
2. Queued — Depfloy is waiting for the server's deployment queue to free up, or for an in-flight deployment on this project to finish.
3. Deploying — Depfloy is running the build (install dependencies, build assets, switch the active release, restart services).
4. Success or Failed — the final state.

A failed deployment leaves your previous successful deployment running — your site does not go down because a build broke.

Multiple pushes to the same project

If commits arrive faster than Depfloy can deploy them, the currently running deployment keeps going and the newer commits sit in a queue behind it. The project header shows Deploying with a small +N queued badge so you know more work is coming. When the active deployment finishes, the next queued one starts automatically.

This is a recent change. Previously, a second push could appear to bump the running deployment off the project view, and people tended to click Reset Deployment Status to "clear" things — which actually caused the running deployment to lose its tracking and leave the project in an inconsistent state.

Resetting the deployment state

If a project ever does get stuck in Deploying for far longer than it should, the project actions menu (three-dot in the header) has a Reset Deployment Status action. Use it sparingly.

When you click it, Depfloy first checks whether a deployment is genuinely still running:

• If not, the state is cleared and you can deploy again.
• If yes, you'll see a strong warning: resetting will delete the active deployment record and may leave the project in an inconsistent state. Only confirm if you understand the consequences.

In most cases, Rerun on the Deployments page is the safer recovery action.

Inspecting a failed deployment

When the most recent deployment failed, the red Failed badge in the project header is clickable. Clicking it opens a side sheet with the full deployment log, ANSI-coloured, so you can scroll through what went wrong without leaving the Console.

The global Deployments page

The Deployments tab in the top bar lists every deployment across all servers in your organization, with filters and bulk actions.

Filters and search

• Search — across description, branch, commit SHA prefix, commit message, and project name
• Project and Server — filter to a single project or server
• Status — multi-select chip group: Queued / Deploying / Success / Failed / Created
• Branch — filter by branch name (case-insensitive equality)
• Date range — Last 24 hours (default), 7 days, 30 days, All time

The filter combination is reflected in the URL so you can share or bookmark a view. Clear filters resets everything.

Stats summary

The top of the page shows a quick count for the selected date range: X deploys · Y succeeded · Z failed · N in progress. Realtime updates keep this current as deployments finish.

Per-row actions

Click the kebab … on a deployment row:

• View Log — always available; opens the full deployment log dialog.
• Rerun — only available for failed deployments. Queues a new deployment using the same commit. Requires confirmation.
• Rollback — only available for successful deployments that are not the currently active one. See below.

Rerun and Rollback

Rerun

Rerun is the right tool when a deployment failed because of a transient cause (registry timeout, flaky test, environment quirk) and the code itself is fine. Click Rerun on a failed deployment row, confirm, and Depfloy queues a new deployment at the same commit. Your deployment history grows by one entry.

Rollback

Rollback returns you to an earlier successful deployment. Use it when a release broke production and you need to revert quickly. Depfloy creates a new deployment that targets the rolled-back commit — your history is preserved, and the rollback itself appears as a new deployment.

To roll back:

1. From the Deployments page or the project's Summary, find a previous successful deployment.
2. Click Rollback on it (or on the active deployment to see a chooser).
3. Pick the target deployment and confirm.

A deployment can be rolled back to if:

• Its status is Deployed
• It has a recorded commit ID
• It is not the currently active deployment

You cannot roll back while another deployment is in progress.

Zero-downtime deployments

Every deployment in Depfloy is zero-downtime by default. Your application stays available to users throughout the deploy — there's no service interruption.

How files are laid out

When you SSH into your server, the project files look like this:

/home/depfloy/{project_id}/
├── current/     # Your active application code
└── shared/      # Persistent files (.env, storage/)

• current/ — the running version of your application. When you run commands manually (php artisan migrate, for example), run them in this directory.
• shared/ — contains your .env file and storage/ directory. These persist across deployments.

Node.js port rotation

Node.js projects (Next.js, Nuxt, Remix, React Router) use blue/green deployment, which rotates the application's port between deployments. If you write a custom nginx configuration that references a Node.js project, use the upstream alias rather than a hardcoded port — see Nginx Configuration → Node.js Upstream.

What's preserved

• Environment variables — your .env lives in shared/.env and is symlinked into each new release.
• Storage directory — for Laravel, Statamic, and Symfony, storage/ is preserved at shared/storage. Uploaded files, logs, cache — all intact between deployments.
• Custom shared directories — if you defined extra shared paths under Settings, they persist the same way.
• Custom commands — your custom deploy command runs in the new current/ directory after the symlink switch.

What happens on failure

If a deployment fails, the symlink stays pointing at the previous release. Your site keeps serving the old version. Check the deployment log to see what went wrong, fix it, and either re-push or use Rerun.