Running your code on our machines is a trust decision.
So this page is the answer to the only question that matters when you make it: what, specifically, keeps one job from seeing another, where your data lives, who can reach it — and what we do not have yet. No badges we did not earn.
Every job runs on its own, and nothing it touches outlives it
The honest version of this is not “we take security seriously” — everyone says that. It is the mechanism.
One job, one machine, then gone
Every job gets its own virtual machine, which no other job uses and which is destroyed when the job ends. It is never reused between jobs — not between repositories, and not between two jobs of the same repository. The disk it ran on is a throwaway copy that is destroyed with it.
A job cannot reach another job
Each machine sits on its own network interface, firewalled so that a job can reach exactly one port on the host it needs — to read and write its cache — and nothing else: not another job, not the host's other services. Each organisation's outbound network identity is its own, so one organisation's traffic can never appear to come from another.
Credentials that fit one job
A job is handed a credential scoped to that job alone. It unlocks that job's own cache namespace and nothing wider — there is no “list everything” shape to it — and it is useless once the job is done. One job's credentials cannot be used by another.
Where your data lives, and how it is protected
Your code and your account stay in the European Union, with one exception we would rather name than let you assume. Your CI jobs run in France and Belgium. The service that schedules them runs in Belgium and the Netherlands. Your account, your usage records, your invoices and your Terraform state are held in Ireland. The dashboard itself is hosted in the United States, so what you view in it — build logs included — passes through there. The full list of who processes your data, and where, is on the privacy page.
Encrypted in transit
Everything you reach is served over HTTPS, and the links between our own systems are encrypted too. The site is told to upgrade any plain-HTTP request before it is made.
Encrypted at rest
The stored copies of your build caches and sticky disks are encrypted in our object storage with AES-256 — checked every day by a probe that also tries, and fails, to write something unencrypted. Your account data and Terraform state sit in a managed European database that encrypts data at rest.
Deleted on a clock
Build logs and test results are deleted automatically after 90 days — about when they age out of GitHub — whether or not you ask. The privacy page says exactly what is kept, and for how long.
The dashboard, and the parts you sign in to
A strict content policy
Scripts run only from us, each one tagged with a single-use value minted per request; the browser runs no inline script we did not mint. The dashboard cannot be embedded in another site, and every request is forced onto HTTPS.
Sessions are checked, not trusted
Every page behind sign-in revalidates your session against the authentication server rather than trusting a cookie the browser could have written. A session that does not check out is sent back to sign in.
What we do, and don't do, with your data
There is no analytics on this site: no Google Analytics, no product analytics, no session recording, no advertising pixels, no third-party scripts of any kind, and one cookie — the one that keeps you signed in. Card details are entered on Stripe's own pages and are never held by us. We do not sell your data, share it for advertising, or use it to train models.
The same discipline on our side
Least privilege, and a closed database
The engine that runs your CI connects to the database as a role that can read and write only its own tables — no access at all to your account records or your Terraform state, verified against the live database where it is refused. The schemas holding job and Terraform data are not reachable with any public key, and every table a signed-in user can touch carries a rule that keeps one tenant out of another's.
The master key is kept away from your code
The most valuable secret we hold — the key that acts on GitHub on your behalf — is deliberately kept off the machines that run your jobs. A script sweeps the live machine on every deploy and fails the deploy if it finds it there.
Secrets are backed up and locked down
Every credential that protects something live gets a second copy in a dedicated secret store the day it is created, so losing one place cannot lose the key. On the machines we operate they live in a root-only directory, and nothing writes them to a log or onto a command line.
What we do not have — yet
We would rather under-claim here than wear a badge we did not earn. So, plainly:
- No formal certifications. We are not SOC 2, ISO 27001 or PCI certified, and we have not yet commissioned an independent penetration test. When any of that changes, it will be stated here with the evidence, rather than asserted.
- No uptime guarantee. We do not publish a service level agreement yet. What we do publish is a live status page, so you can see for yourself whether a problem is ours or yours.
- Draft legal terms. Our terms and privacy policy are still a draft while the company details are finalised, and both say so at the top.
Think you have found a security problem? Email legal@runners.io and we will respond.