Private beta on AWS. First measured results are in.

Burst workers for your job queue, at spot prices, in your own AWS account.

When jobs start waiting, JobRunr Spot boots your app on the cheapest spot instance AWS has, drains the backlog, and gives the machine back. Your existing servers keep running like today. In our measured runs, 2.5 hours of backlog was gone in 8 minutes for $0.002.

62 to 69%

below on-demand, measured on live price pairs for the same instance

0 of 40

jobs lost when we killed a spot node mid-run

80 seconds

from queue backlog to extra capacity processing jobs

$0.002

to drain 2.5 hours of backlog

All numbers from our measured test day: 270 jobs, 4 experiments, one deliberately killed node. Read the full write-up.

Spot is cheap. Capturing the saving is hard.

AWS sells spare capacity at up to 90% off, yet almost nobody uses it for background jobs. Configure it once and JobRunr does the hard part, while your existing servers keep running like today.

  • ✓ Spot prices move constantly: the broker tracks them live and picks the cheapest match across your regions. We measured a 9x spread for the same spec.
  • ✓ Reclaims are a non-event: we killed a node mid-run, 17 jobs re-queued in 11 seconds, zero lost.
  • ✓ Your queue is the scaling signal, not CPU: extra capacity was processing jobs 64 to 80 seconds after the queue backed up.
  • ✓ No Terraform changes: no launch templates, no custom metrics. The spot worker is your existing Docker image.
  • ✓ Runs in your own AWS account: your data, your VPC. We're the broker, not the host.
  • ✓ Verifiable savings: the dashboard tracks your spot cost against the same instance on-demand, live.
JobRunrConfiguration.java
// Configure once: JobRunr boots your Docker image on the
// cheapest spot instance whenever your job queue backs up
JobRunr.configure()
    .useStorageProvider(storageProvider)
    .useCostAware(usingStandardCostAwareConfiguration(
            new CostAwareAwsEC2ProviderConfiguration(accessKeyId, secretAccessKey, accountRegion, registryReaderRole),
            "url-to-your-docker-image")
        .andUsingRegions(new String[]{"eu-north-1", "eu-west-1"})
        .andSpotInstanceAmount(1, 5)
        .andScaleUpLatency(Duration.ofMinutes(1)))
    .initialize();

This shows the shape of the configuration API. Final method names may change based on what design partners tell us.

JobRunr dashboard servers view showing spot instances with an Amount saved column

The dashboard during our test day: every spot node reports its live cost next to what the same hours would have cost on-demand.

What would Spot save you?

If Spot is not a fit for your queue, the calculator says so.

1. Where do your background jobs run today?

2. What shape is your workload?

3. Are your jobs safe to re-run?

4. Closest worker instance size, and how many?

5. How many hours a day are those workers actually busy? 6h

1h24h
Strong fit
Today, on-demand 24/7 $189
Same capacity on Spot $17
You'd keep
$172/mo 91% less
  • ✓
  • ✓

Price pairs from the 10,448 live spot prices we collected on our test day. The t3.small and t3.2xlarge pairs are measured, the sizes in between are interpolated. Your workload will differ, which is exactly what the beta is for. See the measured math

Chaos test

We killed a live node to prove the failover.

During a 40-job burst we terminated the spot instance while it was processing 17 jobs. No drain, no warning. That is harsher than a real reclaim, which gives you two minutes notice. Eleven seconds later, all 17 jobs were back in the queue. The cluster provisioned a replacement and all 40 jobs finished. Zero lost.

There is no magic here, and that is the point. JobRunr runs jobs at least once with automatic retries, whether a worker dies from a spot reclaim, a deploy, or a kernel panic. The one rule that stays yours is that jobs on spot must be safe to re-run.

Read the full chaos test

When you don't need this

Spot is not for every queue, and pretending otherwise would cost us your trust. Four honest reasons to skip the waitlist.

You need sub-minute pickup at all times

A spot node takes about a minute to appear. If that minute hurts, keep one spot worker as a permanent floor with andSpotInstanceAmount(1, N), still at the spot discount, and burst the rest.

Your jobs can't be re-run

Keep them on your stable servers and set retries to 0. Spot is for retriable work, which is the same discipline Lambda and every retry-based system already asks of you.

If any of this sounds like you, the waitlist is the right place

JobRunr Spot is for the teams already feeling the cost.

You already run JobRunr

You have the cluster and the jobs. Trying Spot is a config block and a Docker image, not a migration. Your OSS or Pro setup stays exactly as it is.

Java teams with bursty batch work on AWS

PDF generation, ETL, report rendering, imports, transcoding. You're paying on-demand for capacity you only need in bursts.

Teams who tried spot and got burned

Sudden shutdowns killed your throughput. You missed an SLA. You quietly moved back to on-demand. We killed a node mid-run to prove the failover. Zero jobs lost.

Be one of the first 100 design partners

We're picking a small group of teams to shape the product before the September launch. You'll run it on your own AWS account, on your own workload, and you get direct input on the API, the pricing, and which providers we add next.

We'll reach out before the private beta opens. No spam, ever.

Early access before the September public release
Direct input on the API, pricing, and provider roadmap
Free use of the JobRunr Spot platform for the first 90 days
1:1 onboarding call with the founding team

From the team behind JobRunr. Trusted by

Adobe JP Morgan Chase Thoughtworks Capgemini Intuit

FAQ

Questions before you sign up?

What we know so far. Some of this will change based on what design partners tell us.

The first public release ships in September 2026. The private beta opens earlier for design partners on the waitlist. You’ll get access weeks before everyone else.
For steady near-24/7 load, that’s genuinely fine and we say so. The measured math: on AWS there is no break-even, a spot worker attached 24/7 still costs 62% less than the same on-demand instance. Against the cheapest external VPS the crossover is about 18 attached hours per day, and below that spot wins on price while also scaling past one machine, patching itself, and sitting network-close to your job storage. Full math in the results post.
A real reclaim gives you two minutes notice. Our chaos test gave none: we terminated a spot node while it was processing 17 jobs, and 11 seconds later all 17 were back in the queue. The cluster provisioned a replacement and all 40 jobs in the burst finished, zero lost. JobRunr runs jobs at least once with automatic retries, whether a worker dies from a reclaim, a deploy, or a kernel panic. Read the full chaos test.
Jobs that can’t be re-run. The one rule that stays yours is that jobs on spot must be safe to re-run. Keep non-retriable work on your stable servers and set retries to 0, and with JobRunr Pro you can pin it there with server tags. Imports, PDF runs, ETL, reports and transcoding are exactly what spot is for.
64 to 80 seconds from queue breach to processing, measured across 6 provisionings. If sub-minute pickup matters, keep a warm floor of one spot worker with andSpotInstanceAmount(1, N), still at the spot discount, and burst the rest.
Your jobs run in your own AWS account. You connect it once with a service role, and JobRunr Spot dispatches work into your environment. The data stays in your VPC, your security and compliance posture doesn’t change, and you keep your existing cloud relationships and discounts. We’re the broker, not the host.
AWS today in the private beta. Google Cloud is next, with full multi-region and multi-AZ spot routing on both. We picked these two because they cover most of the Java workloads in production today. Azure and the GPU-specialist clouds (CoreWeave, RunPod, Lambda Labs) follow once the broker is stable.
Yes, but only because we want to ship something stable. GPU brokering is the very next milestone, on the same API and dashboard. Most Java workloads are CPU-bound (PDF, ETL, reporting, transcoding), so starting there gives the most teams an immediate win.
Same configuration, same dashboard. You’ll specify the GPU and the model you need (A100, H100, L4) in your hardware requirements instead of CPU only; GPU memory is already a configuration option. If your team is already thinking about AI workloads, tell us in the waitlist follow-up and we’ll keep you in the loop on GPU access specifically.
Yes. It’s configuration, not a rewrite. You point JobRunr Spot at your cloud account and the Docker image of your app, and the spot workers join your existing JobRunr cluster like any other node. You don’t change how you define jobs.
You pay AWS directly for the compute, and the spot saving stays with you: in our measured runs, 62 to 69% below on-demand for the same instance. Our own pricing on top of that is still open. A flat platform fee, a small percentage of spot spend, tiered usage: we’re not locked into any model yet. That’s one of the things we want to figure out together with design partners, so we land on something that actually works for the teams using it.
No. JobRunr Pro keeps doing what it does inside your app: priority queues, batches, workflows, multi-cluster dashboard. JobRunr Spot handles what happens outside your app: watching spot prices, booting and retiring instances in your cloud account, and reporting what you actually saved.
Sign up anyway and tell us in the follow-up email. We’d rather hear about a use case we hadn’t thought of than miss a design partner who would have been a great fit.