Deployment queue concurrency is hardcoded to 1 (no env/config to override)

Summary

The BullMQ worker that processes deployments is created without a concurrency option, which means it defaults to 1. Every deploy job in the deployments queue is executed strictly one at a time, regardless of cluster size, host CPU/RAM, or how many independent applications are queued.

Tested on Dokploy v0.28.6.

Where it is

apps/dokploy/server/queues/deployments-queue.ts — the Worker is instantiated with:

new Worker(
  "deployments",
  async (job: Job<DeploymentJob>) => { ... },
  {
    autorun: false,
    connection: redisConfig,
    // <- no concurrency option; BullMQ default = 1
  },
);

For comparison, the schedules workers in apps/schedules/src/workers.ts do pass concurrency: 100 explicitly.

Why it matters

Teams running many independent applications on Dokploy hit this constantly:

• Two webhook-triggered builds arriving at the same time: the second one sits in waiting until the first finishes, even if they target unrelated apps on different servers.
• Monorepo setups where one push can deploy 3-4 services: they serialize even though the machine has spare capacity.
• Long-running builds (Docker build of a big image) block every other deploy in the meantime.

The UI already shows the queue (Deployments tab, "Queued" column) but there's no way to widen it.

Proposed

Expose concurrency via an env var, keep default = 1 so existing installs don't change behaviour:

concurrency: Math.max(1, Number(process.env.DEPLOYMENT_QUEUE_CONCURRENCY) || 1),

Env var name (open to bike-shedding): DEPLOYMENT_QUEUE_CONCURRENCY.

Downsides of raising it are on the user (CPU/RAM/disk IO saturation on the build server), not Dokploy, and are documented well enough by "set this higher at your own risk".

Workaround we're using

Because the setting is hardcoded in the bundled JS, the only runtime workaround is to edit the compiled file inside the running container and restart it — gets wiped on every image update. We're running a small systemd reconciler on the worker node for a different Dokploy limitation (ContainerSpec.Hosts in #4270) and would love to retire both of these.

Happy to open a PR for this — the change is three lines including a default. Would you prefer:

1. Env var only (minimal, what this proposal shows)
2. Env var + a "Deployment Queue Concurrency" field in Settings → Cluster (or similar)?

I'll go with (1) unless you'd rather have (2).

Start in apps/dokploy/server/queues/deployments-queue.ts and inspect the Worker options, then compare the explicit concurrency setting in apps/schedules/src/workers.ts. Confirm the chosen environment variable preserves a default of 1 and controls deployment worker concurrency; document the setting and verify the deployment queue still starts correctly.