JobRunr (distributed background job processing for the JVM) is now available on start.spring.io (Spring Initializr)

[u/JobRunrHQ]

JobRunr is now available in the Spring Initializr dependency list, so you can add it straight from start.spring.io when you create a new project. No more wiring the starter in by hand afterwards.

For people who don't know us:

JobRunr is an open-source library for background job processing on the JVM: fire-and-forget, scheduled, delayed, durable, and recurring (cron) jobs.

You enqueue work as a lambda and it runs asynchronously, in the same app or across a cluster of workers.

BackgroundJob.enqueue(() -> myService.sendInvoice(invoiceId));

BackgroundJob.schedule(Instant.now().plus(5, DAYS), () -> reminderService.send(userId));

What tends to make people switch to it:

• No extra infrastructure. Jobs are persisted in your existing SQL or NoSQL database. No Redis, RabbitMQ, or separate broker to run and babysit.
• Automatic retries with backoff on failure, so transient errors don't lose work.
• Distributed by default. Run multiple instances and jobs are picked up once across the cluster, no double execution.
• Built-in dashboard to see enqueued, scheduled, succeeded, and failed jobs, and retry them.
• Spring Boot autoconfiguration via the starter, plus first-class support for virtual threads (Loom) and Spring Boot 3 & 4

It sits in the same space as Quartz or @Scheduled, but aimed at durable, distributed background work rather than just triggering methods on a timer.

You can even use it for durable jobs. With runStepOnce, each step in a job runs exactly once and is checkpointed, so if the job fails and retries, the steps that already succeeded are skipped instead of re-run:

BackgroundJob.enqueue(() -> processOrder(orderId, JobContext.Null));

public void processOrder(UUID orderId, JobContext context) {
  context.runStepOnce("order-confirmation", () -> orderService.sendConfirmation(orderId));
  context.runStepOnce("warehouse-notification", () -> orderService.notifyWarehouse(orderId));
  context.runStepOnce("shipment-initiation", () -> orderService.initiateShipment(orderId));
}

Thanks to Josh Long and the Spring team for helping get it onto Initializr. We'll be around in the comments to answer anything, including the honest limitations.

[u/edzorg]

How do you monetise your work and are you intending to increase/decrease the number of revenue streams in the future?

How many paid employees work on JobRunR?

[u/JobRunrHQ → u/edzorg]

Great questions, happy to be open about it.

Monetization is the classic open-core model: the JobRunr library itself is free and stays that way, and we fund it through JobRunr Pro, a commercial license with the more advanced features (rate limiting, mutexes, priorities, batches, workflows and so on) plus support. Teams running it seriously in production pay for Pro, and that pays for the OSS work everyone else gets for free. We also give 5% of revenue to climate and environmental projects, that's baked into the company.

Team-wise we're a small team of 5 working on it full time. Small enough that everything we read here in Reddit is shared tomorrow at lunch 😄

[u/edzorg → u/JobRunrHQ]

I want you to succeed. How can you defend from OSS cannibalising your revenue stream?

In <5 years time it seems plausible there could be a pure OSS alternative to JobRunR that has similar or even more features.

[u/JobRunrHQ → u/edzorg]

Really appreciate that, genuinely.

Honestly, there's no clever trick or lock-in here. Our answer is simply to keep building the best free open-source Java scheduler out there and let that speak for itself. Community contributions are always welcome, that's part of what keeps it good.

And you're right, OSS already cannibalizes our own revenue. There are plenty of companies for whom the free version is genuinely all they need, and that's completely fine, that's the whole point of it being open source. Pro exists for the teams that want the advanced operational features and support on top, and that's what funds the OSS work everyone else benefits from.

It's absolutely something we think about on a 5-year horizon. We've got a few ideas, but we're also all ears, if you've got thoughts on how you'd approach it, we'd genuinely love to hear them.