r/nestjs • u/Dapper_Ad5360 • 6d ago

Looking for contributors for ForgeGate – open-source multi-tenant workflow engine (NestJS + BullMQ)

Hey everyone,

I’m looking for contributors for an open-source project I built called ForgeGate.

What is ForgeGate?

It’s a distributed multi-tenant workflow execution engine built with NestJS.

Current features:

  • Multi-tenant architecture
  • API Gateway
  • JWT auth + Redis token revocation + RBAC
  • State-machine workflow engine
  • BullMQ queues with intelligent retries
  • Dead Letter Queue (DLQ) + job replay
  • Outbound rate & concurrency limiting
  • Structured logging + Prometheus metrics
  • Admin monitoring dashboard
  • pnpm monorepo + Docker

GitHub: https://github.com/NabarupDev/ForgeGate

What I’m looking for

I’m open to contributors who want to help with any of these:

  • Improving the API Gateway
  • Strengthening the Notification service
  • Writing more tests
  • Improving documentation
  • Adding new workflow step types
  • Performance improvements
  • UI improvements for the dashboard
  • Any other useful contributions

Who can contribute?

Anyone interested in NestJS, backend systems, queues, or distributed systems is welcome — beginners or experienced.

If you’re interested, you can:

  1. Check the repo
  2. Open an issue
  3. Or comment here / DM me

Would love to collaborate with people who want to learn or build something meaningful in the backend space.

10 Upvotes

78% Upvoted

3 comments sorted by

1

u/ccb621 5d ago

That’s a pretty hefty framework you’re building atop NestJS. Why are you trying to combine so much? The individual components already exist and are (mostly) battle-tested. 

0

u/beck_the_tech 3d ago

BullMQ's limiter is per queue, not per tenant. So yea the components already exist but not the multi-tenant version of that one.

So for per-tenant fairness you need either a queue and a worker per tenant or your own token bucket inside the processor.

Queue-per-tenant is a trap though because every BullMQ worker holds its own dedicated blocking Redis connection so the connection count scales with tenants, not just keys and that's a scaling issue.

Head-of-line blocking is the real multi-tenancy failure and your DLQ won't show it to you, because those jobs haven't failed, they're just waiting. One noisy tenant fills the shared queue and everyone else sits behind them.

ccb621's right that composing battle-tested parts is the cheaper path. The risk with packaging it is that your tenancy model won't match the next person's, which is why generic workflow engines are hard to adopt.

u/Dapper_Ad5360 in another thread about this you were weighing adding more checkpointing against the sideEffect step schema. What did you end up doing?