Security & trust

You’re trusting us with your CI and your keys. Here’s exactly how we handle them.

Baremetal custodies your GitHub App keys and runs jobs on your hardware. That only works on trust, so we keep the security model simple, outbound-only, and verifiable — and we limit our claims to what the system is actually built to do.

Your GitHub App keys

  • Your GitHub App private key is stored encrypted at rest in a dedicated secrets vault. It is never written to disk on your machines and never stored in our database.
  • The key is used for one thing: minting short-lived, just-in-time runner registration tokens. It never leaves the backend.
  • You create the GitHub App in your own org and can revoke or rotate it at any time, independently of Baremetal.

Ephemeral, single-job runners

  • Every CI job runs in a fresh, single-use virtual machine created from a pristine image — a Tart VM on a Mac, a KVM VM on Linux.
  • Runners are just-in-time and single-use: one job, then the VM is destroyed. Secrets, caches, and artifacts never survive into another job.
  • Failed or orphaned VMs are garbage-collected, and stale runner registrations are purged.

Tenant isolation

  • Agents and the runners scheduled onto them are fenced to your workspace by label. Another customer’s job cannot land on your hardware.
  • Baremetal orchestrates your machines for you — it is not a marketplace and never shares your hardware with anyone else.

Network posture

  • Every connection is outbound. Your machine dials the cloud backend — nothing reaches into your machines.
  • You don’t open inbound ports or expose anything to the internet, which keeps it firewall- and NAT-friendly.
  • Traffic to the backend is over TLS with publicly-trusted certificates.

Isolated runner networking

  • Every runner VM is network-isolated behind a default-deny egress policy — Linux KVM guests via an nftables-firewalled bridge, macOS guests via Tart’s Softnet. A job reaches the public internet and DNS, and nothing else.
  • Private ranges (RFC1918 / your LAN), carrier-grade NAT, the cloud metadata endpoint (169.254.169.254), the host itself, and the host’s loopback are all blocked. So untrusted code — for example a public-repo pull request, which runs the contributor’s code — can’t pivot into your network, internal services, or cloud credentials.
  • Runners can’t talk to each other: guest-to-guest traffic is blocked.
  • Isolation is enforced on the host; if the isolation tooling isn’t present the agent refuses to start the VM rather than run it unprotected. Every job is also bounded by a wall-clock cap so a runaway can’t hold hardware indefinitely.

Access & least privilege

  • You sign in with Google. The dashboard holds no long-lived credentials.
  • The dashboard has zero direct database access — the data rules deny everything. Every read and write goes through an authenticated API with your ID token.
  • Mutating actions (rotating a key, editing pools, revoking a machine) require an owner or admin role; viewers are read-only.
  • Each machine authenticates with its own token, stored only as a hash at rest and revocable instantly.

Open foundations

  • Runners are created with open-source, auditable tooling — the Tart VM engine on macOS, QEMU/KVM on Linux — so you can read exactly how each runner is booted and torn down.
  • We describe the architecture plainly and only make claims this design actually supports. We do not hold formal compliance certifications, and we won’t pretend to.

Responsible disclosure

Found a security issue? We want to hear about it. Reach the team through Premex AB and we’ll respond quickly. Please give us a chance to fix issues before disclosing them publicly.

See how it works in the docs →Get started free →