Projects and Deployments

This page explains the two concepts you will see most often in Depfloy: projects and deployments. Understanding the difference makes everything else in the docs easier to follow.

Projects

A project is one of your applications running on one of your servers. Each project is tied to:

A server (where the application runs)
A Git repository and branch (where the source code lives)
A framework (Laravel, Next.js, Wordpress, React Router, Nuxt.js, plain PHP, ...) that determines how Depfloy builds and starts your app

You can have as many projects as you like, on the same server or spread across many. Each project gets its own URL, environment variables, schedulers, background jobs, and deploy history.

To create a project, see Create Project.

The project workspace

When you open a project in the Console, the main panel splits into tabs across the top:

Summary — current state, last deployment, quick links
Domains — custom domains and SSL certificates
Environments — environment variables (plain or encrypted)
Commands — run one-off shell commands
Schedulers — Laravel scheduled commands defined in your code
Background Jobs — Laravel plugins (Octane, Reverb, Horizon, Nightwatch) and any custom workers
Logs — nginx and application logs
Nginx Configuration — the project's nginx template and any custom snippets
Settings — Git repository, deploy triggers, maintenance mode, project lifecycle

You will only see the tabs you have permission to see — Viewers see fewer than Admins, for example. See Members for how roles map to what's visible.

A deployment is a single, successful build of a project's code at a particular Git commit. Each deployment leaves a record you can inspect later — who triggered it, which commit, when it ran, how long it took.

How a deployment is triggered

Two ways:

Auto-deploy — Depfloy listens to your Git provider through a webhook. Every push to the project's branch starts a deployment automatically.
Manual — you click Deploy in the project Summary, or call the API.

You can mix both: leave auto-deploy on for staging and disable it on production, for instance.

Deployment lifecycle

A deployment moves through these states:

Created — the request has been recorded.
Queued — Depfloy is waiting for the server's deployment queue to free up, or for an in-flight deployment on this project to finish.
Deploying — building and releasing your code: install dependencies, build assets, switch to the new release, restart services.
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 you push commits 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.

If you ever need to clear stuck state, the project menu has a Reset Deployment Status action — use it sparingly, and if a deployment is genuinely running you will see an extra warning before it lets you reset.

Looking at deployments globally

Beyond a project's own history, the Deployments tab in the top bar lists every deployment across all your servers. From there you can:

Filter by project, server, status, branch, or date range
Search across description, branch name, commit hash, commit message, and project name
View the full log of any deployment
Rerun a failed deployment (re-uses the same commit)
Roll back to an earlier successful deployment

See Deployments for the full reference.