Enable Account administrators to set maximum concurrent pipeline execution limits for individual projects. Currently, without per-project controls, a single misconfigured project can exhaust shared cluster resources and cause platform-wide disruptions affecting other applications.

What we need:

Admin-configurable concurrency limits per project (e.g., Project A max 20 concurrent executions)

Real-time enforcement with queuing/rejection when limits are reached

Exception process for high-priority projects

API support and full audit logging

Minimal performance impact on pipeline starts (<100ms)

Why the two-bucket approach is insufficient:

The current PIPE_PROJECT_LEVEL_EXECUTION_CONCURRENCY feature flag groups all projects into only two buckets. For large enterprises managing thousands of projects, this lacks necessary granularity—a misconfigured project in either bucket can still exhaust resources for all other projects in that bucket. This approach redistributes risk rather than eliminating it.

Business Impact:

Prevents platform-wide outages caused by runaway pipelines

Ensures fair resource allocation across all teams

Provides parity with legacy CI/CD platforms where this control existed

Critical for enterprise customers operating at scale with thousands of applications

Expected Workflow:

Admin sets per-project limit → Pipeline checks current executions → Enforces limit (start, queue, or reject) → Audit logging → Admin can monitor and adjust as needed