Deterministic deploy order for multiple services watching the same git repo

What problem will this feature address?

When multiple Dokploy services are linked to the same GitHub repository through the GitHub integration, one push can match multiple services via Watch Paths.

Example monorepo:

• apps/api
• apps/web
• packages/shared
• jobs/worker

A push that changes packages/shared and apps/api can correctly match more than one Dokploy service. Dokploy then enqueues deployments for all matching services.

The problem: I cannot define which matching service should build or deploy first.

This matters in monorepos where services have deployment dependencies, for example:

• a shared base image should build before app images
• the API should deploy before the frontend
• a migration or worker service should deploy before the web service
• service A publishes an image, tag, or artifact that service B consumes

Watch Paths decide which services deploy. They do not define the order in which multiple matching services deploy.

Describe the solution you'd like

I would like Dokploy to let users control the deployment order when one GitHub repository event matches multiple services.

A simple solution would be an optional numeric deploy priority field for Applications and Compose services.

Suggested behavior:

1. Dokploy receives one GitHub repo webhook event.
2. Dokploy collects all matching Applications and Compose services for that event.
3. Dokploy sorts them by deploy priority.
4. Dokploy enqueues deployments in that order.

Example:

• shared-image: priority 10
• api: priority 20
• web: priority 30

If one push matches all three services, Dokploy should enqueue:

1. shared-image
2. api
3. web

A sensible default could be priority 100, so existing projects keep working without configuration.

For equal priorities, Dokploy could use a documented fallback such as service name or creation date.

A more advanced version could support dependency rules, for example:

• web depends on api
• api depends on shared-image

But a numeric priority field would already solve most monorepo cases.

Describe alternatives you've considered

I considered using separate service-specific webhook URLs, but this does not fit the GitHub integration flow where multiple services are linked to the same repository through the UI.

I also considered using GitHub Actions to call Dokploy deployment APIs in a fixed order. That works as a workaround, but it duplicates deployment orchestration outside Dokploy and bypasses the built-in repo watching experience.

Another workaround would be splitting the monorepo into multiple repositories, but that defeats the purpose of using a monorepo.

Relying on the current deployment order is also not ideal, because users do not have an explicit contract for which matching service will deploy first.

Additional context

No response

Will you send a PR to implement it?

Maybe, need help

Start by tracing the GitHub webhook flow that collects matching Applications and Compose services, then follow where deployments are enqueued. Define how an optional priority is stored and exposed, how equal priorities are resolved, and how ordering is verified; done means one event enqueues matching services deterministically while existing defaults continue to work.