tempus.build · managed runners for GitHub Actions
CI ~2× faster.
One line changes.
A drop-in replacement for GitHub-hosted runners: change one line in your workflow and your jobs run on bare-metal AMD EPYC/Ryzen, billed by the second instead of rounded up to the minute.
$5 on signup · no card required
jobs: build: -runs-on: ubuntu-latest +runs-on: tempus-ubuntu-24.04-4core 01 problem
Paying for rounded-up minutes — overpaying.
Waiting on GitHub-hosted runners — slow.
// problem
GitHub-hosted runners take their time: you wait longer than you should. And every job's time is rounded up to a full minute — on short builds you pay for seconds that never ran.
// solution
tempus.build fixes both. Billing is per-second — you pay for the actual time, with no rounding. Jobs run on bare-metal servers next to the dependency cache, so builds are noticeably faster; exactly how much we're measuring right now in open benchmarks.
02 advantages
Build faster, pay simpler
-
01
No surprise invoice
Your balance is prepaid: jobs draw down the actual seconds they run, and the remainder is visible in the dashboard. Pay up front, exactly for what you use — no surprise invoice at the end of the month.
-
02
Per-second billing
GitHub rounds every job up to the minute. With us a 75-second job costs 75 seconds, not 2 minutes: you're billed only for the actual run time.
-
03
Builds ~2× faster
Bare-metal AMD EPYC/Ryzen plus a dependency cache colocated with the runners: packages don't travel half the internet, so builds run roughly twice as fast as GitHub-hosted.
-
04
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. Exactly what private repositories need.
03 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 exactly as it was.
jobs: build: -runs-on: ubuntu-latest +runs-on: tempus-ubuntu-24.04-4core steps: - uses: actions/checkout@v4 tempus-ubuntu-24.04-4core · $0.008/min
build 3m 47s · 227s −$0.030
test 6m 12s · 372s −$0.050
lint 47s · 47s −$0.006
Job durations are illustrative; charges are arithmetic from the rate: 227 seconds at $0.008/min = $0.030.
// compatibility
Under the hood it's Ubuntu 24.04, so the usual marketplace actions work unchanged.
// setup
Connect through a GitHub App with a minimal set of permissions. The App is installed only on the repositories you choose.
// isolation
Works with private and public repositories. Every job runs in its own isolated VM, so public repos are as safe as private ones.
coming soon
MCP server
The Model Context Protocol is the open standard agents use to plug in tools. We're eyeing it for tempus.
04 benchmarks
We claim a ~2× speedup — and measure it in public
Expected speedup ranges from 1.8 to 2.5× depending on the workflow, driven by bare-metal AMD EPYC/Ryzen servers and a dependency cache on the same node. But this is a claim, not a measured result — so instead of a table of numbers, public benchmarks will live here.
How the testing will work: a cron job runs the same builds of public open-source projects on ubuntu-latest and on a tempus runner, with timings recorded by GitHub Actions itself — no manual measurements or cherry-picked runs. The workflow files and results live in an open repository: github.com/tempusbuild/benchmarks — soon.
Beta participants hear about the results first — and can measure the speedup on their own workflows without waiting for our numbers
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.008/min costs $0.026 — not $0.032, as it would with rounding up to the minute.
| configuration | resources | replaces | $/min |
|---|---|---|---|
| tempus-ubuntu-24.04-2core lint, simple tests 2 vCPU · 8 GB · ubuntu-latest (private repositories) | 2 vCPU · 8 GB | ubuntu-latest private repositories | 0.004 |
| tempus-ubuntu-24.04-4core popular standard build 4 vCPU · 16 GB · ubuntu-latest (public repositories) | 4 vCPU · 16 GB | ubuntu-latest public repositories | 0.008 |
| tempus-ubuntu-24.04-8core large test suites, monorepos 8 vCPU · 32 GB · ubuntu-latest-8-cores | 8 vCPU · 32 GB | ubuntu-latest-8-cores | 0.016 |
| tempus-ubuntu-24.04-16core heavy builds 16 vCPU · 64 GB · ubuntu-latest-16-cores | 16 vCPU · 64 GB | ubuntu-latest-16-cores | 0.032 |
Per minute of runner time; you're billed for the actual seconds.
free tier
Try it on your workflows — $5 on signup
$5 on your balance — no card required. That's about 10 hours of a 4-core runner. Run your workflows and watch the numbers before topping up.
payment model
01 Prepaid balance
Your balance is prepaid, in US dollars: jobs draw the actual seconds they run from it; the remainder and a per-second billing history are visible in the dashboard. No surprise invoice at the end of the month.
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, in any amount.
03 The rate is baked into the label
The per-minute price is baked into the runner label itself: tempus-ubuntu-24.04-4core is always $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
US dollars by default. Need another currency — let us know
Top up your balance in US dollars. Need another currency — let us know and we'll find an option that fits your team.
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.
price
Our $0.008/min for 4core is cheaper than comparable GitHub-hosted, and you pay for the actual seconds, not rounded-up minutes.
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 counts the actual seconds and divides time by the speedup. Plug in your own numbers — the formulas are below the results.
GitHub-hosted rates are from the official GitHub documentation (as of July 2026). On public repositories GitHub's standard runners are free — this calculator is about private ones. The speedup is an estimate; the real figure depends on your pipeline. tempus rate — $0.008/min for 4-core, cheaper than the comparable GitHub-hosted price; billed in US dollars, another currency on request.
Done the math? Check the estimate on real jobs.
$5 on signup · no card required
07 under the hood
How speed and isolation work
-
cache
npm · pip · docker
Dependency cache on local NVMe
The dependency cache lives next to the runner, on local NVMe disks: npm install doesn't cross the ocean. It's transparent to your workflow — npm, pip, and docker work as usual, except packages are served from the cache on the same node rather than from external registries.
-
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 survives the job boundary.
-
hardware
bare-metal · eu
Bare-metal instead of cloud VMs
Jobs run on bare-metal servers with AMD EPYC and Ryzen, not on cloud VMs where a noisy neighbor can grab the CPU at any moment. The servers are located in the EU.
-
images
ubuntu 24.04 · cis · slsa
Images built to industry standards
Under the hood it's Ubuntu 24.04 x64, compatible with ubuntu-latest; no other images yet. Hardened to CIS Docker Benchmark and NIST SP 800-190, supply chain following SLSA: non-root execution, base image pinned by sha256 digest, and a weekly rebuild that pulls in the latest patches. Every release passes an internal CI gate: a benchmark against GitHub-hosted with thresholds for cold start and warm-cache speedup. Miss the threshold, and the release doesn't ship.
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: ~2× faster builds, per-second billing, a signed open-source image.
● OpenTofu — beyond ubuntu-latest: GitHub dropped Terraform; we ship the open-source alternative.
08 transparency
Don't take our word for it — check
-
runner-images
Runner images — open source
The images your jobs run in are built in a public repository on GitHub: every release is signed with cosign, published with an SBOM, and scanned by a vulnerability scanner. What's inside the execution environment is a matter of verification, not trust.
-
status
Status and incidents — open from day one
Service status and incident history will be open on a public status page: what broke, when, and how it was fixed — visible to everyone, not just us.
-
docs
Documentation — publicly available
The quickstart and the migration guide from ubuntu-latest will be published openly: you can read them and assess the migration without signing up for the service.
09 security
Parity is the floor, not the ceiling
-
// proactive patching
Vulnerabilities close before you ever hit them
Images rebuild weekly and pull in the latest patches; trivy fails the build on fixable HIGH and CRITICAL. We don't bake EOL runtime minors, and Renovate bumps dependencies — the environment doesn't accumulate known holes between releases.
-
// verifiable provenance
What's in the image is a matter of checking, not trust
Every release is cosign-signed (keyless), ships an SBOM and SLSA provenance with GitHub attestations; CI runs OpenSSF Scorecard and CodeQL. Everything is pinned by version and SHA, no floating :latest — you can walk the chain back to the source yourself.
-
// open source
You can read the execution environment
Runner images are built in a public repository under Apache-2.0: you can see what gets installed and how, on which base image and as which user. Jobs run in a single-use, isolated VM — nothing is left behind once it ends.
10 faq
Questions and answers
setup and speed
How do I connect?
Two steps. Install the GitHub App tempus-build and choose which repositories to grant access to. Then replace runs-on: ubuntu-latest with runs-on: tempus-ubuntu-24.04-4core in your workflow. 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?
Jobs run on bare-metal AMD EPYC/Ryzen servers, and the dependency cache is colocated with the runners: packages are served from the same node rather than external registries. Together that produces the claimed ~2× speedup — we're measuring it right now with public benchmarks and will publish the results soon.
billing
How does billing work?
Prices are in US dollars per minute, the balance is prepaid. Jobs bill the actual seconds they run — per second, no rounding. Balance and per-job history are in the dashboard. Billed in US dollars; need another currency — let us know.
Who pays for CI on pull requests from outside contributors?
The installation owner — that's how GitHub Actions works with every provider, including GitHub itself. Protection against unexpected costs: the prepaid model (you can't spend more than your balance), a concurrent-job limit, and a daily budget alert.
Is there a free plan for open source?
There's no formal OSS program yet. Running a notable open-source project? Get in touch and we'll top up your balance by hand.
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 and built to industry standards (CIS Docker Benchmark, NIST SP 800-190, SLSA): 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 account or 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 when installed on an organization -
Administration: read & write(repository) — the same when installed on individual repositories; one of these two permissions is needed, not both -
Metadata: read(repository) — the mandatory minimum for any GitHub App -
Actions: read(repository) and theworkflow_jobwebhook events — job statuses for per-second billing
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 generated on demand — we don't store any long-lived access tokens. App page: github.com/apps/tempus-build
Can I use it on public repositories?
Yes. Each job is isolated in its own VM and can't affect the infrastructure or other jobs. For public repositories we recommend enabling GitHub's standard approval setting for workflows from outside contributors.
Can a runner's power differ between private and public repositories?
No. The shape is determined solely by the label in runs-on and is fixed: tempus-ubuntu-24.04-4core is always 4 vCPU and 16 GB RAM — on a private repo, a public one, or a PR from a fork. With GitHub, ubuntu-latest is different hardware: 4 vCPU on a public repository and 2 vCPU on a private one; with us the spec is baked into the label itself. Repository visibility only affects the policy for running jobs from forks, not the hardware — your CI timings are reproducible regardless of repository type.
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 and launch
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.
What happens to my balance if the service shuts down?
We refund the remainder. Your balance is prepayment for runner time; if you didn't spend it, the money is yours.
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 we'll open a status page with incident history — judge by the facts: status.tempus.build. And per-second billing cuts both ways: if it wasn't running, you didn't pay.
When does it launch?
We're not announcing a launch date — the product is in development. A private beta is running now: participation is free, $5 on signup, no card required. Participating teams get runners first and shape how the service ships.
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; private-beta participants hear first.
blog
From the blog
all posts →-
Kata Containers 4.0: the runtime rewritten in Rust — what changes inside
In 4.0 the default Kata runtime becomes runtime-rs, in Rust instead of Go. What changes inside: how runtime-rs is built, what memory safety buys a host-side runtime, the new block storage model, and a verified rootfs via dm-verity/EROFS.
-
Kata Containers: how every CI job gets its own kernel
Ordinary containers share the host kernel. Kata Containers runs each pod in a lightweight VM with its own guest kernel — OCI-compatible, under containerd. A look at the Kata 3.x architecture and why it's the right boundary for untrusted CI code.
Change one line in your workflow — check the rest yourself
A private beta is running now, free to join: $5 on your balance right after signup, no card required. Participants get runners first and shape the product.