[ GET STARTED ]
OPEN THE CONSOLE[ CONTACT ]
[email protected][ MANAGED RUNNERS · NEW ]
Install the GitHub App, label a job, and we launch one ephemeral runner per queued job on our infrastructure. No fleet to babysit, no registration tokens to manage.
1
Job Per Runner
JIT
Just-In-Time Launch
/min
Per-Minute Billing
[ THE ONLY CHANGE ]
Point runs-on at jumpdrive and the job runs on our infrastructure instead of yours. Same rule for matrix builds — every cell still carries the one label.
.github/workflows/ci.yml
jobs:
build:
runs-on: jumpdrive
steps:
- uses: actions/checkout@v4
- run: make test.github/workflows/test.yml — matrix
jobs:
test:
runs-on: jumpdrive
strategy:
matrix:
ruby: ["3.3", "3.4"]
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
ruby-version: ${{ matrix.ruby }}
bundler-cache: true
- run: bundle exec rspec[ MATRIX FANS OUT TO INDEPENDENT JOBS ] — each matrix cell queues as its own job and gets its own just-in-time runner, launched independently.
[ HOW IT WORKS ]
From install to first job, there's nothing to provision and nothing to register.
01
Install the "Jumpdrive Runners" GitHub App on your org.
02
Toggle Runners on in the Jumpdrive console.
03
Add runs-on: jumpdrive to your job.
One ephemeral, just-in-time runner per queued job — one container, one job, destroyed after.
[ PER-JOB ISOLATION ]
[ HOW A JOB FLOWS ]
Same six steps for every job, every time — nothing improvised at launch.
01
GitHub queues the job because the workflow points runs-on at jumpdrive.
→02
Jumpdrive's dispatcher picks up the queued job for your org.
→03
A single-use runner registration is generated and delivered via a sealed secret.
→04
An ephemeral container starts on Jumpdrive infrastructure, scoped to this one job.
→05
The container runs exactly one job, start to finish. Nothing else touches it.
→06
The container and its one-time credentials are torn down. Nothing persists.
Caps and concurrency limits are enforced at step 02, before a container ever starts. Between 04 and 06, nothing happens except the job finishing on its own.
[ NEVER KILLED MID-JOB ]
[ TWO KINDS OF RUNNERS ]
01
Ephemeral runners for your GitHub Actions jobs, launched on our infrastructure.
02
Isolated containers for your org's Jumpdrive workflow executions.
[ METERING YOU CAN AUDIT ]
Billing isn't a black box. What you see in the console is what's in the ledger, and what's in the ledger is what ran.
Usage is recorded to an append-only, idempotent ledger — entries are never edited or replayed twice.
Every billed minute traces back to a specific job or run, with the raw timing evidence behind it.
A job only launches a runner if your org's plan and monthly cap allow it — checked before launch, not reconciled after.
The console shows your usage against your monthly cap in real time.
[ WHAT AN AUDIT SEES — ONE LEDGER ENTRY ]
job_id 7c3a9f2e-19b0-4e7a-9c2e-51f0a2d1b8aa
run acme-web #4821 · build
started 2026-07-02T09:14:03Z
finished 2026-07-02T09:18:15Z
duration 00:04:12
status settled · immutableThis is the shape of the record, not a live example — every billed minute in your console resolves back to a row like this one, with the raw start and end timestamps behind it.
[ SECURITY POSTURE ]
Every runner is launched, constrained, and torn down the same way, every time.
These are the questions a security review asks first: can a compromised job reach another job's secrets or files? Can a runner outlive the job it was issued for? Can a launch exceed your org's caps? Each guarantee below answers one directly.
Credentials
Runner credentials are single-use, just-in-time configs delivered via sealed secrets.
Answers: a leaked token can't be replayed for a second runner.
Isolation
Workloads never share a container with another job or run.
Answers: a compromised job can't read another job's files or env.
Limits
Caps and concurrency limits are enforced at launch, before a runner ever starts.
Answers: a launch storm can't exceed your org's cap or entitlement.
Execution
Nothing is ever killed mid-job.
Answers: infra churn can't sever a job and leave bad state behind.
[ THE TRADE-OFF ]
A conceptual comparison of the shape of the trade-off — not a benchmark against any specific setup.
Self-Managed Fleet
Jumpdrive Managed
Registration Tokens
Generate, distribute, and rotate them yourself.
None — a single-use JIT config is issued per job.
Provisioning & Patching
Build and patch your own runner images.
Nothing to provision or patch.
Scaling
Size the fleet ahead of peak load.
One runner launched per queued job, on demand.
Idle Cost
Pay for capacity sitting idle between jobs.
Billed for actual job minutes only.
Isolation
Depends on how the fleet is configured.
One container, one job, every time.
Ops Burden
Yours to own, monitor, and repair.
Ours to own, monitor, and repair.
[ PRICING ]
Every plan includes a monthly allotment of runner minutes; past it, you pay per minute of actual execution. Both runner kinds are metered the same way and gated by entitlement — a job only launches a runner if your org's plan allows it.
| Plan | Included | Then | Runners |
|---|---|---|---|
| Free | 50 min / mo | Hard cap — no overage | 1 |
| Team | 3,000 min / mo | $0.005 / min | 5 |
| Enterprise | 15,000 min / mo | $0.004 / min | 20 |
Live usage vs. included minutes is always visible in the console.
[ GET STARTED ]
Add the Jumpdrive Runners GitHub App to your org and start running jobs on our infrastructure in minutes.