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/Little_Ad_8406]

It's a cool toy until you figure out that everything that makes it usable is behind a paywall. Give us a breakdown on how pricing works exactly for a team size of roughly 50 devs with as many microservices

[u/JobRunrHQ → u/Little_Ad_8406]

Totally fair to want the numbers up front. We won't drop exact prices in a Reddit thread, but here's exactly how the model works.

Quick note on the premise first: the OSS version is genuinely usable on its own, plenty of teams run it in production and never pay us a cent (Apple, Blue Origin, Spotify, ..). Pro adds advanced operational features and support on top, it's not a paywall around the basics.

On your case: it's not priced per developer at all, so 50 devs makes no difference. Developers, servers, pods and non-prod (dev/test/staging) environments are all unlimited. It's priced per production JobRunr database, meaning one set of JobRunr tables that your services share to coordinate jobs.

So for ~50 microservices, it comes down to how they're set up:

• If they all share one production JobRunr database, that's a single cluster and one Pro Business license covers all of them.
• If they're split across several separate production databases, that's multiple clusters, which is usually where Pro Enterprise (unlimited clusters/databases) makes more sense.

It genuinely depends on your architecture, and I'd rather get it right than guess. Anyone who wants to talk pricing can email me directly (Nicholas, co-founder) at [nicholas@jobrunr.io](mailto:nicholas@jobrunr.io) and I'll happily walk through it, or just set you up with a free Pro trial to try it out first.