[ MANAGED RUNNERS · NEW ]

GitHub Actions runners, hosted by us.

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.

Job Per Runner

JIT

Just-In-Time Launch

/min

Per-Minute Billing

[ THE ONLY CHANGE ]

One label. That's the whole 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 ]

Three Steps.
No Fleet.

From install to first job, there's nothing to provision and nothing to register.

Install The App

Install the "Jumpdrive Runners" GitHub App on your org.

Toggle Runners On

Toggle Runners on in the Jumpdrive console.

Label The Job

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 ]

Queued To
Destroyed.

Same six steps for every job, every time — nothing improvised at launch.

Queued

GitHub queues the job because the workflow points runs-on at jumpdrive.

→

Matched

Jumpdrive's dispatcher picks up the queued job for your org.

→

JIT Config Issued

A single-use runner registration is generated and delivered via a sealed secret.

→

Container Launched

An ephemeral container starts on Jumpdrive infrastructure, scoped to this one job.

→

Job Executes

The container runs exactly one job, start to finish. Nothing else touches it.

→

Destroyed

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 ]

Same Infrastructure. Two Ways In.

GitHub Actions Runners

Ephemeral runners for your GitHub Actions jobs, launched on our infrastructure.

Per-job isolation — one container, one job
No fleet to babysit
No registration tokens to manage
Billed for actual job minutes only

Jumpdrive Workflow Runners

Isolated containers for your org's Jumpdrive workflow executions.

Per-run isolated containers
Available to paid orgs
Metered by the minute
Gated by entitlement

[ METERING YOU CAN AUDIT ]

Every Minute, Accounted For.

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.

Immutable Ledger

Usage is recorded to an append-only, idempotent ledger — entries are never edited or replayed twice.

Traceable To The Source

Every billed minute traces back to a specific job or run, with the raw timing evidence behind it.

Entitlement-Gated

A job only launches a runner if your org's plan and monthly cap allow it — checked before launch, not reconciled after.

Live Usage, Live Cap

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 · immutable

This 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 ]

Isolated By Default.

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

Single-Use JIT Configs

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

No Shared Containers

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 & Concurrency

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

Runs To Completion

Nothing is ever killed mid-job.

Answers: infra churn can't sever a job and leave bad state behind.

[ THE TRADE-OFF ]

Fleet vs. Managed.

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 ]

Metered By The Minute.

Both runner kinds are metered per minute and gated by entitlement — a job only launches a runner if your org's plan allows it.

[ Illustrative — Not A Quote ]

Actual rates, caps, and entitlement tiers are set per plan and shown in the console. Nothing on this page is a committed price.

[ GET STARTED ]

Install The App. Label The Job.

Add the Jumpdrive Runners GitHub App to your org and start running jobs on our infrastructure in minutes.

Get Started Read The Docs