feat: allow DEPLOYMENT_QUEUE_CONCURRENCY env to tune deploy parallelism

[freddysae0]

Summary

• Adds a DEPLOYMENT_QUEUE_CONCURRENCY environment variable that controls how many jobs the BullMQ deployments worker processes in parallel.
• Defaults to 1, which preserves current behavior (before this change the worker was created with no concurrency option, silently inheriting BullMQ's default of 1).
• Invalid / non-positive / non-numeric values also fall back to 1.

Closes #4272

Why

On any instance with more than a handful of apps the single-slot queue is a real bottleneck: two webhook-triggered builds arriving at the same time serialize, even when they target unrelated applications on different remote servers. There's no way to raise this today without patching compiled JS inside the running container, which gets wiped on every image update.

This change is additive and opt-in — the default is unchanged.

Diff

One file, 8 net lines:

+// DEPLOYMENT_QUEUE_CONCURRENCY controls how many deploy jobs run in parallel.
+// Defaults to 1 (original behavior); invalid/non-positive values fall back to 1.
+const deploymentConcurrency = (() => {
+  const n = Number(process.env.DEPLOYMENT_QUEUE_CONCURRENCY);
+  return Number.isFinite(n) && n >= 1 ? Math.floor(n) : 1;
+})();

     {
       autorun: false,
       connection: redisConfig,
+      concurrency: deploymentConcurrency,
     },

Test plan

• biome check apps/dokploy/server/queues/deployments-queue.ts — no fixes needed
• Unset env var → deploymentConcurrency === 1 (preserves current BullMQ default behavior)
• DEPLOYMENT_QUEUE_CONCURRENCY=5 → 5
• DEPLOYMENT_QUEUE_CONCURRENCY=-3 / 0 / abc / empty → falls back to 1
• DEPLOYMENT_QUEUE_CONCURRENCY=3.7 → 3 (via Math.floor)

Happy to adjust the env var name, add it to .env.production.example, or wire it through a Settings UI field in a follow-up if preferred — kept scope intentionally minimal per CONTRIBUTING guidance.

Greptile Summary

This PR adds a DEPLOYMENT_QUEUE_CONCURRENCY environment variable that lets operators increase BullMQ worker concurrency beyond the current hard-coded default of 1. The parsing logic correctly handles all invalid inputs (empty, non-numeric, zero, negative, non-finite) by falling back to 1, preserving existing behavior when the variable is unset.

Confidence Score: 5/5

Safe to merge — additive, opt-in, and default behavior is unchanged.

Single-file change with correct input validation, no breaking changes, and well-tested edge cases in the PR description. No P0 or P1 issues found.

No files require special attention.

_{Reviews (1): Last reviewed commit: "feat: allow DEPLOYMENT_QUEUE_CONCURRENCY..." | Re-trigger Greptile}