Feature: Skip superseded queued deployments (latest deployment wins)

What problem will this feature address?

When multiple commits are pushed or merged into the same branch in a short period of time, Dokploy may enqueue multiple automatic deployments for the same application.

For example:

commit A -> running
commit B -> queued
commit C -> queued
commit D -> queued

Once deployment A finishes, Dokploy may continue processing B, then C, then D, even though B and C are already obsolete revisions and D is the latest desired revision.

This can result in:

• unnecessary builds consuming CPU, memory, disk and build cache resources;
• significantly longer time until the latest revision reaches production;
• intermediate revisions being deployed even though a newer revision is already waiting;
• unnecessary container/image churn;
• particularly poor behavior when several pull requests are merged into the same branch close together.

For automatic deployments from a branch, the useful desired state is usually the latest revision, not every intermediate queued revision.

Describe the solution you'd like

Add an optional deployment queue strategy for automatic deployments that coalesces queued deployments for the same deployment target.

For example:

A -> running
B -> queued
C -> queued
D -> queued

should become:

A -> running
B -> superseded
C -> superseded
D -> queued

The currently running deployment should be allowed to finish.

Only queued automatic deployments that have been superseded by a newer revision should be skipped.

A possible configuration could be:

Deployment queue strategy:

[ ] FIFO — deploy every revision
[x] Latest wins — skip superseded queued revisions

Suggested scope

The superseding key could be based on the effective deployment target, for example:

application + environment/server + branch

so deployments belonging to different applications or branches remain independent.

Suggested behavior

Automatic deployments

When a new automatic deployment is received:

1. Check whether another deployment for the same target is currently queued.
2. If one or more queued automatic deployments already exist, mark them as superseded.
3. Keep only the newest revision queued.
4. Do not interrupt a deployment that is already running.
5. Start the newest queued revision once the active deployment finishes.

Example:

A running
B arrives -> B queued
C arrives -> B superseded, C queued
D arrives -> C superseded, D queued

Final queue:

A running
D queued

Preserve deployment history

Ideally, superseded deployments should remain visible in deployment history instead of disappearing.

For example:

A  SUCCESS
B  SUPERSEDED
C  SUPERSEDED
D  RUNNING

Potential metadata:

supersededByDeploymentId
supersededAt

This would preserve auditability and make it clear why a deployment did not run.

Manual deployments and rollbacks

I would suggest excluding explicit/manual actions from automatic superseding.

For example:

• manual deploy -> should not be silently superseded;
• rollback -> should not be silently superseded;
• explicit redeploy of the same revision -> should remain allowed.

The optimization is primarily intended for automatic deployments generated by repository/webhook events.

Optional follow-up: skip release of an already obsolete running build

A further optimization could eventually check whether a revision is still the latest desired revision after its build finishes but before it is released.

Example:

A starts building
B arrives
C arrives
D arrives

A build finishes
latest desired revision = D

Dokploy could choose not to release A, and instead proceed directly to building/deploying D.

However, this could be treated as a separate enhancement. The minimal useful implementation would simply coalesce queued deployments while allowing the active deployment to complete normally.

Describe alternatives you've considered

1. Handle it in CI/CD before calling Dokploy

A GitHub Actions workflow or another CI system could debounce deployment requests and only call Dokploy for the newest commit.

This works, but it moves deployment queue semantics outside Dokploy and requires every repository to implement the same coordination logic.

2. External deployment coordinator

A service could sit between GitHub webhooks and Dokploy and maintain the latest desired revision for each application.

This adds another service, persistence/locking requirements, and another potential failure point.

3. Manually cancel queued deployments

Users can manually remove obsolete queued deployments when they notice several commits have accumulated.

This does not scale and defeats the purpose of automatic deployments.

4. Keep current FIFO behavior

FIFO is still useful in some environments, so this proposal does not necessarily need to replace it.

It could be an optional per-application deployment queue policy.

Additional context

This is especially useful for monorepos and projects where multiple pull requests are frequently merged in a short window.

Example:

PR #101 merged -> commit A
PR #102 merged -> commit B
PR #103 merged -> commit C
PR #104 merged -> commit D

If the first build takes several minutes, there is generally little value in deploying all four revisions sequentially.

With a latest-wins queue:

A -> running
B -> superseded
C -> superseded
D -> queued

instead of:

A -> build/deploy
B -> build/deploy
C -> build/deploy
D -> build/deploy

This reduces wasted build resources and, more importantly, reduces the time required for the newest revision to become active.

Similar concepts are sometimes described as:

• deployment coalescing;
• latest-wins queue;
• superseded deployments;
• cancel redundant deployments;
• desired-revision deployment.

Will you send a PR to implement it?

Potentially yes, if the maintainers agree with the desired behavior and proposed scope first.

The issue names no files, tests, or entry points. Start by locating the automatic deployment queue and webhook-handling paths, then inspect how deployment history and manual or rollback actions are represented. Done means an optional latest-wins policy supersedes only older queued automatic deployments for the same target while preserving history and leaving running, manual, and rollback actions unaffected.