Is your feature request related to a problem? Please describe.
Currently, QuickStack appears to process build jobs sequentially. In practice, this can also slow down deployments when multiple apps or projects need to be updated at the same time. This becomes a bottleneck on larger servers or multi-node clusters where enough CPU and RAM are available.
Describe the solution you'd like
Add support for configurable parallel builds and deployments.
Ideally, QuickStack should allow admins to configure concurrency limits, for example:
- maximum parallel builds
- maximum parallel deployments
- optional per-node, per-project, or global limits
1 as the safe default for smaller servers
The existing queue behavior could remain, but instead of allowing only one build/deployment pipeline to run at a time, QuickStack should allow the oldest N pending jobs to run based on the configured limits.
Describe alternatives you've considered
The current workaround is to wait for builds and deployments to finish one by one or trigger some steps manually outside QuickStack. This works, but it slows down rollout workflows significantly when multiple apps need to be updated.
Additional context
This would be especially useful for users running QuickStack on larger servers or clusters with enough resources to safely handle multiple BuildKit/Railpack builds and Kubernetes deployments at the same time.
Is your feature request related to a problem? Please describe.
Currently, QuickStack appears to process build jobs sequentially. In practice, this can also slow down deployments when multiple apps or projects need to be updated at the same time. This becomes a bottleneck on larger servers or multi-node clusters where enough CPU and RAM are available.
Describe the solution you'd like
Add support for configurable parallel builds and deployments.
Ideally, QuickStack should allow admins to configure concurrency limits, for example:
1as the safe default for smaller serversThe existing queue behavior could remain, but instead of allowing only one build/deployment pipeline to run at a time, QuickStack should allow the oldest
Npending jobs to run based on the configured limits.Describe alternatives you've considered
The current workaround is to wait for builds and deployments to finish one by one or trigger some steps manually outside QuickStack. This works, but it slows down rollout workflows significantly when multiple apps need to be updated.
Additional context
This would be especially useful for users running QuickStack on larger servers or clusters with enough resources to safely handle multiple BuildKit/Railpack builds and Kubernetes deployments at the same time.