Skip to content

tempus.build · managed runners for GitHub Actions

Cheaper CI.
One line changes.

The same toolset and the same machine size as ubuntu-latest — at $0.004/min instead of $0.006, billed per second, on bare-metal AMD Ryzen machines in the EU. Need speed? 4core doubles the vCPUs: up to 5× on real pipelines, most on compilation, tests and image builds.

From $0.004/min, billed per second, no subscription · $5 to start (1,250 minutes of 2-core), no card required · private repos in GitHub organizations

.github/workflows/ci.yml
jobs: build: -runs-on: ubuntu-latest +runs-on: tempus-ubuntu-24.04-2core
The film uses demo data, and says so on screen.
Read the transcript

Seventy-five seconds of work, billed as two minutes. And your builds are slow.

Meet tempus.build. Change one line.

Install the GitHub App and swap one runs-on label. The rest stays as it was.

Pay for seconds, not rounded-up minutes. Four-tenths of a cent a minute, not six.

Every job is billed to the second.

Set spending limits, and stay in control.

Same build: about twice as fast on four-core, by our estimate. Up to five times on heavy pipelines.

And you see before-and-after run times for every job you move.

Every job gets its own micro-VM: no shared kernel, nothing left behind, lateral movement blocked.

Change one line. Check the rest yourself. Five dollars to start, no card required. tempus.build.

01 advantages

How it differs from GitHub-hosted and your own runners

  • 01

    Pay for seconds, not an end-of-month bill

    A 75-second job costs 75 seconds, not 2 minutes. Prepaid balance, no subscription: spend is capped by your balance and org budgets.

  • 02

    Faster on heavy work

    4core: 4 vCPU and 16 GB instead of the 2 vCPU and 8 GB of ubuntu-latest on private repositories, bare-metal AMD Ryzen, and an image and package cache in the same region — no workflow changes needed: up to 5× on real pipelines.

  • 03

    Every job in its own VM

    Each job gets its own isolated VM, not a container in a shared environment — it's created for the job and destroyed when it finishes. Runner images are open source: you can inspect the environment instead of taking it on faith.

  • 04

    No runners to maintain

    The image, weekly patches, isolation and hardware are on us. You change runs-on instead of running a fleet.

02 how it works

One line in your workflow

No migration, agents, proxies, or extra configuration: just change the value of runs-on — the rest of your workflow stays as it was. Leaving works the same way: switch back to ubuntu-latest.

.github/workflows/ci.yml
jobs: build: -runs-on: ubuntu-latest +runs-on: tempus-ubuntu-24.04-2core steps: - uses: actions/checkout@v4
dashboard › billing history

tempus-ubuntu-24.04-2core · $0.004/min

build 3m 47s · 227s −$0.015

test 6m 12s · 372s −$0.025

lint 47s · 47s −$0.003

Job durations are illustrative; charges are arithmetic from the rate: 227 seconds at $0.004/min = $0.015.

// compatibility

Under the hood it's Ubuntu 24.04, so the usual marketplace actions work unchanged.

// setup

Sign in with GitHub, then connect through a GitHub App with a minimal set of permissions. The App goes on your organization and only on the repositories you choose.

// scope

Today: private repos in GitHub organizations, Linux x64, 2core and 4core sizes. Personal accounts, public repos, ARM, Windows and macOS aren't supported yet.

The film uses demo data, and says so on screen.
Read the transcript

From sign-in to your first job on tempus, in a few minutes.

Go to app.tempus.build and sign in with GitHub.

Runners live in GitHub organizations, and a free one is enough. Click Install on an organization.

On GitHub, pick your organization and the repositories you want, then install.

Back on tempus, your workspace is ready in seconds.

See what your CI costs today, and what you'd save.

The overview has a checklist: the app is installed, your repositories are connected, and five dollars is on your balance. No card required.

One step left: in your workflow, change runs-on to the tempus label, and push a commit.

If you lint workflows with actionlint, add the tempus labels to its allow-list.

The job starts on tempus. You can watch it live.

Done. Setup is complete.

And every job is billed to the second.

Your first job is on tempus. Change the rest of your workflows the same way. tempus.build.

03 security

Don't take our word for it — check

  • runner-images

    A signed, open-source runner image

    The images your jobs run in are built in a public repository under Apache-2.0. Every release is cosign-signed (keyless) and published with an SBOM and SLSA provenance; the base is pinned by sha256 digest, actions by SHA. What's inside the execution environment is a matter of verification, not trust.

    Check for yourself →

  • status

    Status and incidents — public

    Website availability and incident history are on a public status page: what broke, when, and how it was fixed — visible to everyone, not just us. Dashboard and runner monitoring is being added.

    status.tempus.build →

  • isolation

    A separate VM per job, patched weekly

    Every job runs in a single-use, isolated VM — nothing from the job's environment survives it. The image is rebuilt weekly with fresh apt patches; a build with fixable HIGH or CRITICAL vulnerabilities in OS packages doesn't ship.

    The full isolation model and supply-chain verification →

04 speed

Estimated 1.8–⁠2.5×, more on heavy pipelines

On 4core we expect 1.8–2.5× for a typical workflow, driven by 4 vCPU instead of the 2 of standard ubuntu-latest on private repositories, bare-metal AMD Ryzen and a dependency cache in the same data-center region as the runners. Real pipelines heavy on compilation, tests and image builds have seen up to 5×. But this is an estimate, not a measured result — your own pipeline will show the real number.

Sign in with GitHub

Measure the speedup on your own workflows: the $5 you start with is 625 minutes of a 4-core runner

ubuntu-latest on private repos → tempus.build
  • before: runs-on: ubuntu-latest

    after: runs-on: tempus-ubuntu-24.04-4core

  • before: 2 vCPU · 8 GB

    after: 4 vCPU · 16 GB

  • before: cloud VM

    after: VM on bare-metal AMD Ryzen

  • before: Docker and apt from the internet

    after: cache in the same region

  • before: rounded up to the minute

    after: billed per second

Compilation, tests and image builds gain the most.

05 pricing

Pay for seconds, not for rounded-up minutes

The rate is per minute, billing is per second. A 3 min 12 s job at $0.004/min costs $0.013 — not $0.016, as it would with rounding up to the minute.

tempus.build runner configurations: resources, per-minute rate, GitHub-hosted equivalent, and intended use
configuration $/min
tempus-ubuntu-24.04-2core available default: the 1:1 ubuntu-latest swap 2 vCPU · 8 GB · ubuntu-latest (private repositories) 0.004
tempus-ubuntu-24.04-4core available heavy builds and tests: twice the vCPU 4 vCPU · 16 GB · GitHub-hosted 4 vCPU (larger runner) 0.008
tempus-ubuntu-24.04-8core on request large test suites, monorepos 8 vCPU · 32 GB · GitHub-hosted 8 vCPU on request
tempus-ubuntu-24.04-16core on request heavy builds 16 vCPU · 64 GB · GitHub-hosted 16 vCPU on request

Per minute of runner time; you're billed for the actual seconds. 2core and 4core are available today; 8core and 16core are on request.

Need 8core or 16core? Get in touch →

free tier

Try it on your workflows — $5 to start

$5 on your balance once you connect your first organization — no card required. That's exactly 1,250 minutes of a 2-core runner ($5 ÷ $0.004/min) or 625 minutes of 4-core, and per-second billing loses nothing to rounding. It's granted once per GitHub user. Run your workflows and watch the numbers before topping up.

Sign in with GitHub →

payment model

01 Prepaid balance

You top the balance up in advance and it's drawn down per second: spend is capped by your balance — jobs already running can overrun it by at most $1. The remainder and billing history are in the dashboard.

02 The balance doesn't expire

Your balance doesn't expire — there's no shelf life, so a pause in development costs nothing. Top up in advance, from $1; auto-recharge is optional.

03 The rate is baked into the label

The per-minute price is baked into the runner label itself: tempus-ubuntu-24.04-2core is always $0.004/min and tempus-ubuntu-24.04-4core $0.008/min, in any repository. What you put in runs-on is what you pay — no hidden multipliers.

04 When your balance hits zero

When your balance hits zero, running jobs finish to the end, and new ones don't start until you top up. Nothing gets cut off mid-build.

payment

A balance in US dollars, topped up by card

You top up by card through DodoPayments, our merchant of record: they process the payment, issue receipts and invoices, and handle VAT. DodoPayments doesn't accept Russian cards yet; we're working on an alternative payment method — write to billing@tempus.build and we'll let you know.

Ask about payment →

compared to github

billing

GitHub-hosted 4 vCPU costs $0.012/min and rounds time up to the minute — on short jobs you pay for seconds you didn't use. With us it's $0.008/min and per-second billing.

ubuntu-latest

2core is the same size as ubuntu-latest on private repos, but cheaper per minute: $0.004 vs $0.006 beyond your plan's included minutes, with no rounding up. 4core has twice the vCPU of ubuntu-latest and pays off once a job speeds up by more than 1.33×; against the 4 vCPU larger runner ($0.012/min) it's cheaper right away.

migration

No agents, proxies, or pipeline rewrites. You change one runs-on value — a drop-in replacement for GitHub-hosted, and you can leave the same way, in one line.

06 calculator

Run the numbers for your CI volume

GitHub-hosted rounds every job up to a full minute and bills the rounded value; tempus.build counts the actual seconds and divides time by the speedup. Plug in your own numbers — the formulas are below the results.

The same size as ubuntu-latest: the saving comes from the rate and per-second billing; no speedup is assumed by default.

2core is cheaper per minute than ubuntu-latest ($0.004 vs $0.006) at the same size; within your plan's included minutes GitHub is cheaper.

now, on ubuntu-latest (2 vCPU)

1.0×

estimate for 4core on a typical workflow: 1.8–2.5× (not a measurement); compilation, tests and image builds can gain more; 1.0 — no speedup

account for your GitHub plan's included minutes

GitHub-hosted rates are from the official GitHub documentation (as of August 2026). The calculator is about private repositories: on public ones GitHub's standard runners are free, and tempus.build doesn't serve them yet. GitHub plans' included minutes apply only to standard runners, not larger ones. The speedup is an estimate; the real figure depends on your pipeline. The tempus.build balance is in US dollars.

Done the math? Check the estimate on real jobs.

Sign in with GitHub

$5 to start · no card required

07 under the hood

How speed and isolation work

  • cache

    docker · apt · go · maven

    A dependency cache in the same region

    A pull-through cache sits in the same data-center region as the runners, over a private network. Docker Hub and other image registries, apt, Go, Maven/Gradle, NuGet, RubyGems and conda-forge go through it. The cache doesn't store private packages or images — and can't fetch them: it pulls anonymously, without your credentials, and your own registry settings always take precedence, so private dependencies are fetched directly from your registry. Secure by design.

  • isolation

    a vm per job

    A separate VM for every job

    Each job runs in its own isolated virtual machine, not a shared environment. The VM is created for that specific job; once the job finishes, the VM is destroyed. Nothing from the job's environment survives it.

  • hardware

    bare-metal · eu

    Bare-metal instead of cloud instances

    Jobs run on bare-metal servers with AMD Ryzen, not on cloud instances. Every job gets a fixed-size VM set by the label: 2 vCPU and 8 GB, or 4 vCPU and 16 GB RAM. Jobs and your code run in the EU (Finland) — by default, not on a separate tier.

  • images

    ubuntu 24.04 · cis · slsa

    Images you can verify

    Ubuntu 24.04 x64, compatible with GitHub's ubuntu-24.04 image (currently ubuntu-latest). Rebuilt weekly; every release is signed and gated on a vulnerability scan before it ships — details on /security.

same toolchain

The same languages, runtimes, and tools as on GitHub-hosted — from the standard Ubuntu 24.04 image; nothing to reconfigure.

Full parity — and ahead where it counts: twice the vCPU of standard ubuntu-latest on private repositories, per-second billing, a signed open-source image.

● OpenTofu — beyond ubuntu-latest: GitHub dropped Terraform; we ship the open-source alternative.

08 faq

Questions and answers

setup and speed

How do I connect?

Sign in with GitHub at app.tempus.build — the first sign-in creates your account. Install the GitHub App tempus-build on your organization and choose which repositories to grant access to; the platform creates the runner group itself. Then replace runs-on: ubuntu-latest with runs-on: tempus-ubuntu-24.04-2core — the same size as ubuntu-latest; for heavy builds there's tempus-ubuntu-24.04-4core. Nothing else changes — it's a drop-in replacement for GitHub-hosted runners: the same Ubuntu 24.04 and compatibility with marketplace actions.

Why is it faster?

Three reasons: on 4core, 4 vCPU and 16 GB instead of the 2 vCPU and 8 GB of ubuntu-latest on private repositories; bare-metal AMD Ryzen; and a cache for Docker images, apt, Go, Maven/Gradle, NuGet, RubyGems and conda-forge in the same data-center region, over a private network. That's why compilation, tests and image builds gain the most — up to 5× on real pipelines. More in the speed section.

What do I need to connect?

A GitHub organization and private repositories. Personal GitHub accounts aren't supported yet — a free organization is enough. Public repositories aren't served yet either; fork PRs to private repositories run and are billed to the organization's balance — an organization budget caps this spend. There are two runners today, both Ubuntu 24.04 x64: tempus-ubuntu-24.04-2core — 2 vCPU, 8 GB RAM, and tempus-ubuntu-24.04-4core — 4 vCPU, 16 GB RAM; 8- and 16-core are on request (get in touch). Each organization has a concurrent-job ceiling (raised on request); jobs above it wait in the queue.

Will it work for public repos and open source?

Not yet: runners serve only private repositories in GitHub organizations, so there's no free plan for open source either. Fork PRs to private repositories run and are billed to the organization's balance. If public repository support matters to you, get in touch — we'll add it as demand grows.

billing

Can I pay with a Russian card?

Not yet: top-ups go through DodoPayments, which doesn't accept Russian cards. We're working on an alternative — write to billing@tempus.build. The $5 you start with works without a card.

How does billing work?

Prices are in US dollars per minute; the balance is prepaid, in US dollars. Jobs bill the actual seconds they run — per second, no rounding. Balance and per-job history are in the dashboard. Top up by card through DodoPayments (merchant of record), from $1, with optional auto-recharge.

How do I avoid a surprise bill?

The model is prepaid: new jobs don't start at a zero balance; running ones finish, with an overrun of at most $1. On top of that: organization budgets that alert or stop new jobs, budget alerts per repository, workflow and actor, and email alerts for a low balance and spending spikes.

security and isolation

Is it safe for private repositories?

Each job runs in its own isolated VM, not a shared environment with other users: the VM is created for the job and destroyed when it finishes. The servers are located in the EU. Runner images are open source, checked against CIS Docker Benchmark image guidance and published with SLSA provenance: github.com/tempusbuild/runner-images — you can see exactly what your code runs in.

What permissions does tempus.build get in my GitHub?

You connect through the GitHub App tempus-build: you install it on your organization and choose which repositories to grant access to. The App requests the minimum permissions — here's the full list and why each is needed:

  • Self-hosted runners: read & write (organization) — registering runners and the tempus-runners group
  • Members: read (organization) — member roles and repository access, so each member sees only what they can see on GitHub
  • Metadata: read (repository) — the mandatory minimum for any GitHub App
  • Actions: read (repository) and the workflow_job webhook events — job statuses for per-second billing; the installation, repository, organization, member and team events — keeping the organization in sync

The Contents permission isn't on the list — the platform can't read your source code through the API. Your code, just like on GitHub-hosted runners, is checked out by the job itself inside the runner and destroyed along with its micro-VM. Installation tokens are short-lived and minted on demand; we keep no long-lived per-customer tokens. Dashboard sign-in uses GitHub OAuth with the read:user, user:email and read:org scopes. App page: github.com/apps/tempus-build

What resources does a job get?

The shape is determined solely by the label in runs-on and is fixed: tempus-ubuntu-24.04-2core is always a VM with 2 vCPU and 8 GB RAM, and tempus-ubuntu-24.04-4core one with 4 vCPU and 16 GB. With GitHub, ubuntu-latest on a private repository is 2 vCPU and on a public one 4; with us the spec is baked into the label and doesn't depend on the repository type. VMs run on shared bare-metal hosts: you get a separate virtual machine, not a dedicated server.

How do you handle my repositories' secrets?

Secrets reach only the inside of the job, which runs in its own isolated VM: once the job finishes, the VM is destroyed along with its entire environment. We don't write secrets to the platform logs.

trust

What if we want to leave?

Put runs-on: ubuntu-latest back in your workflow — that's the whole migration, the same one line as when you connected. Your code, workflows, and run history stay exactly where they were — in your GitHub. There's nothing to retrieve from tempus.build: the dependency cache is just copies of public packages, and the originals are in the registry anyway. The last step is to remove the GitHub App tempus-build in your GitHub settings and, optionally, delete the tempus-runners runner group.

What happens to my balance if the service shuts down?

Unused paid balance is refunded on request (welcome and bonus grants aren't refundable).

Where's the uptime guarantee?

We're not publishing an SLA yet: promising percentages before a real operating history confirms them is marketing, not a guarantee. Instead there's a public status page with website availability and incident history (dashboard and runner monitoring is being added) — judge by the facts: status.tempus.build. And per-second billing cuts both ways: if it wasn't running, you didn't pay.

Do you have SOC 2?

No. Instead of an auditor's report: what you can verify yourself — a signed open-source image with SBOM and SLSA provenance, a separate VM per job, the public isolation model on /security.

Will there be an MCP server?

Yes, it's on the roadmap: tempus will connect to AI agents over the Model Context Protocol. Details closer to release; announcements go to the Telegram channel t.me/tempusbuild.

blog

From the blog

all posts →

Change one line in your workflow — check the rest yourself

Sign in with GitHub and connect your organization — $5 lands on your balance, no card required. Change runs-on — and compare timings and the bill on your own jobs.