Hello! To be honest, this message from me is long overdue, as I only got around to it half a year later, but better later than never :)
In autumn 2025 I started working on my own implementation of background worker queue, because I was not satisfied with most of the existing offerings: they either rely on Redis (which is no-go for me - I want my queues to be durable, so I want to use Postgres), and some of them are too complicated with sandboxed environments or other moving parts.
Inspired by Laravel Queues (as I am sure you were too) I started building lavoro.js.org, which is effectively a fluent API wrapper around pg-boss (and some other drivers). Originally I wanted to propose that project for AdonisJS ecosystem but I never got around to polishing it enough.
Now, seeing how you are effectively creating the same thing and the fact that I do not have sufficient resources myself, I was wondering maybe we could join the effort and improve your implementation together? For instance, I had a vision for a monitoring tool: a TUI and a dashboard which could make it easy to see the jobs.
This is a rough outline of vision parity between your project and mine:
| name |
boringnode/queue |
lavoro |
| Bulk Dispatch |
Yes |
No |
| Job Grouping |
Yes |
No |
| Distributed execution |
No? |
Coordinated through distributed locks with using verrou.dev |
| Job registration |
Glob paths |
Explicit class enumeration in config |
| Job versioning |
No? |
Planned on the roadmap |
| Deduplication |
4 modes + rigid TTL |
on/off, uses distributed locks when on, heartbeats during job execution which automatically extend TTL |
Overall your implementation is much more feature rich, but mine has a couple things you might be interested in:
- Distributed execution
In Lavoro there is no explicit separation of master/worker by design. Every app can be both emitter and worker - conflicts are resolved using distributed locks. I did this because jobs are not always heavy enough to warrant a separate process. Additionally, this makes horizontal scaling effortless: you scale your app and workers scale with it.
- Deduplication with automatic heartbeats
When the job is picked up and is running, there is a mechanism which automatically prolongs its TTL - effectively making it a heartbeat. This helps avoid overlapping jobs, but I have not tested this extensively for edge cases.
- Monitoring tools
TUI and web UI to monitor job regardless of the underlying storage driver.
In conclusion
Your project is undoubtedly much more feature-rich and faster-moving. Please let me know if you are open to suggestions and joining the effort or maybe even merging parts of my project into yours.
Hello! To be honest, this message from me is long overdue, as I only got around to it half a year later, but better later than never :)
In autumn 2025 I started working on my own implementation of background worker queue, because I was not satisfied with most of the existing offerings: they either rely on Redis (which is no-go for me - I want my queues to be durable, so I want to use Postgres), and some of them are too complicated with sandboxed environments or other moving parts.
Inspired by Laravel Queues (as I am sure you were too) I started building lavoro.js.org, which is effectively a fluent API wrapper around pg-boss (and some other drivers). Originally I wanted to propose that project for AdonisJS ecosystem but I never got around to polishing it enough.
Now, seeing how you are effectively creating the same thing and the fact that I do not have sufficient resources myself, I was wondering maybe we could join the effort and improve your implementation together? For instance, I had a vision for a monitoring tool: a TUI and a dashboard which could make it easy to see the jobs.
This is a rough outline of vision parity between your project and mine:
Overall your implementation is much more feature rich, but mine has a couple things you might be interested in:
In Lavoro there is no explicit separation of master/worker by design. Every app can be both emitter and worker - conflicts are resolved using distributed locks. I did this because jobs are not always heavy enough to warrant a separate process. Additionally, this makes horizontal scaling effortless: you scale your app and workers scale with it.
When the job is picked up and is running, there is a mechanism which automatically prolongs its TTL - effectively making it a heartbeat. This helps avoid overlapping jobs, but I have not tested this extensively for edge cases.
TUI and web UI to monitor job regardless of the underlying storage driver.
In conclusion
Your project is undoubtedly much more feature-rich and faster-moving. Please let me know if you are open to suggestions and joining the effort or maybe even merging parts of my project into yours.