Dokploy
feat(server): add ability to change builds concurrency (reopened)
Summary
This PR adds the ability to configure concurrent builds in Dokploy. Users can now change the number of simultaneous builds from the default of 1 to up to 20 through the settings interface.
Before: All deployments (local + all remote servers) shared one queue with a single concurrency limit set to one by default.
After: Each remote server now has its own dedicated deployment queue and worker with independent concurrency settings.
This feature will be quite usefull for my team and I as we are using dokploy more and more and are getting a bit limited when a developper has to wait for others apps to build before its own.
We've been loving Dokploy so far and I'm very happy to try to help :)
Feel free to share what you think about it !
Changes
- Database: Added
buildsConcurrencycolumn to user table (default: 1) - Backend: Added API endpoints to get/update build concurrency settings
- Frontend: Added modal dialog in Settings → Web Server → Server → Change builds concurrency or for remote servers Remote servers → Actions → Change builds concurrency
- Workers: Created a map of workers (one for each remote server) with each their own concurrency setting
Technical details
I've made the deployment workers as a map of singleton to make it available to the Trpc endpoints. However, I'm not sure about the implementation but it's one I could get working reliably.
How to Use
- Go to Settings → Web Server → Server → Change builds concurrency or Remote servers → Actions → Change builds concurrency
- Enter number (1-20) and save
Resource Warning
The UI warns that each concurrent build needs ~2 vCPUs + 4GB RAM. It may be update for debate, I took this from the warning about builders ressource consumption.
Screenshots
Related issues
Closes #1283 Partially closes #2000 Mentionned here: #877
When saving the values I'm getting this error: Deployment worker is not available in getBuildsConcurrency
@Siumauricio My bad, the default key for the main server queue was wrong, I've fixed it.
Hey @Siumauricio, any news on this one ? Our team is really looking forward to it :)
Is there anything stopping this PR to be merged?
There is merge conflicts that must be resolved.
it'd be awesome to get this merged. building one at a time is so archaic. love dokploy and we need this!
Yes please get this merge. Our workflows are very slow without any level of concurrency!
Getting notified of your commits @Siumauricio and it's getting me excited to get this merged. Very excited to get this for my team!
Thank you for your interest. I am looking into this, as I have wanted to change this for some time, but I am considering removing bullmq and redis.
Because, looking at the current situation and the problems that currently exist, such as this one https://github.com/Dokploy/dokploy/issues/2106, and also because we cannot cancel ongoing builds (there are many issues surrounding this),
I have been thinking about having a much simpler system with queues in memory without redis
For example, if you are doing a build and your server freezes due to the Docker build, bullmq will keep trying again and again due to its mechanism of saving jobs and retrying, and you are basically in an infinite loop.
So I was thinking, if we used a memory queue, if a freeze occurs, at least you can recover, but with the downside that your deployments that were in the queue will be lost due to the restart. However, I prefer that the system can recover and lose the deployments. I'm not sure what you think yet.
One of the advantages would also be that we could eliminate Redis.
@Siumauricio thinking for now, you could allow the multiple concurrency feature. Make it only be able to run 1 by default as you do. Do not advertise that Dokploy can make concurrent builds but put it as an option. If somebody wants to select anything above 1, they would get a warning highlighting the major problem that may occur and they are at risk of losing their web server and would be a good idea to backup.
Basically, it's better to provide the option than not as soon as possible since it seems to be a highly requested feature. As an example, I have a 32GB RAM + 16vCPU setup for Dokploy. I would rather have the option and allow up to 4 concurrent builds than being limited by 1 despite my hardware being absolutely capable of doing 4-8 concurrent builds very easily.
In the future, it would be worth investing in a new architecture to help make Dokploy more stable and faster for builds. But we should focus on getting these small wins in to make the product better right now.
Hope this perspective helps with making a solid decision.
Agree, I think the in-memory queue would have huge benefits (mainly the ability to cancel an ongoing build). But I think that while waiting for this to be implemented, allowing us to have multiple build concurently now would have huge benefits for our team as we're having more and more projects with multiple builds a day.
Hope it gets merged for now and reworked later :)
Hi @Siumauricio, are there any blockers you could highlight that would make this unable to merge? Ideally, it's best to get this merged before this gets tossed aside, since it seems to be overall, a working feature that @NoeGrangier @ardasevinc @RDeluxe @Marukome0743 and many others need right now.
With @broimsuperman on this one: we would heavily appreciate it if we could look into this.
Dokploy as of now, works well for very few services, but once you reach 10+ services/application and have multiple developers working on these applications/services, it's nearly impossible to rely on it for automated deployments. Our team sometimes needs to wait an hour for all queues to clear up.
@Siumauricio thinking for now, you could allow the multiple concurrency feature. Make it only be able to run 1 by default as you do. Do not advertise that Dokploy can make concurrent builds but put it as an option. If somebody wants to select anything above 1, they would get a warning highlighting the major problem that may occur and they are at risk of losing their web server and would be a good idea to backup.
Basically, it's better to provide the option than not as soon as possible since it seems to be a highly requested feature. As an example, I have a 32GB RAM + 16vCPU setup for Dokploy. I would rather have the option and allow up to 4 concurrent builds than being limited by 1 despite my hardware being absolutely capable of doing 4-8 concurrent builds very easily.
In the future, it would be worth investing in a new architecture to help make Dokploy more stable and faster for builds. But we should focus on getting these small wins in to make the product better right now.
Hope this perspective helps with making a solid decision.
I still stand by what I said here. @Siumauricio I believe the community would really benefit heavily from this. If you are still concerned about it crashing, you could leave the concurrency on to 1 by default and if the user modifies the concurrency, show the following text:
Increasing concurrency can cause high CPU and memory usage, longer queues, failed builds if resources run out. Also, your Dokploy server may freeze, and you need to hard-reboot your server. Data may be lost. Keep backups ready. Proceed only if you understand the risks.
It makes it very clear it is an experimental feature. Any power user of Dokploy would seriously benefit from this and anybody can easily opt out if they want to keep things as they are. Feel free to let us know how we can help. We would be happy to handle the work. All we need is your approval. Understandably, you have lots to look into and happy to make this as easy as possible for you @Siumauricio.
@Siumauricio Are there any obstacles? What can be done to overcome them? I would love to help with this feature; I believe it's essential.
