Privacy policy

Lineman operates runners.io and decides what happens to the personal data described below. The registered company details are not stated on this page yet — see the draft notice above. Write to legal@runners.io about anything on this page.

This is the whole of it, taken from the database rather than from memory, and, for the email you send us, from our mailbox:

• Your email address, and the GitHub account you signed in with. We use it to identify you, to send you the emails in the next section, and to address an invoice.
• Your organisation’s name and who belongs to it, including invitations you have sent that have not been accepted.
• Which GitHub installation is linked to your organisation, so we know whose jobs to accept.
• A record of each job we ran: which repository and workflow it came from, which runner size it asked for, when it started and finished, and how it ended. This is what your usage page and your invoice are built from.
• The output of each CI job: its log, collected while it runs, and the names and failure messages of its tests. “How long we keep it” below says for how long.
• What you give the Terraform-compatible runs, if you use them: the configuration you upload, your workspace variables (sensitive ones included), any SSH keys you add for modules, and the state, plans and output of each run — what that service exists to keep.
• Billing records — invoices, their lines, and the billing email you gave Stripe.
• Security and audit events: sign-ins, changes to an organisation, and administrative actions, with the account that took them. We keep these so that we can answer “who changed this” honestly.
• Email you send us, including the requests in clause 8: your address, what you wrote, and our reply. It is held in Google Workspace, which clause 5 lists, not in the database.

We used to say we did not store your build output. We do— since 2026-09-11, so that you can watch a build as it happens rather than waiting for GitHub to publish the log at the end. It is described in full under “How long we keep it” below, with what is kept, for how long, and what is dropped. This paragraph said the opposite until that shipped, and is corrected rather than deleted because a privacy policy that quietly stops saying something is worse than one that says what changed.

We never see your card. Card details are entered on Stripe’s own pages and are held by Stripe.

There is no analytics on this site. No Google Analytics, no product analytics, no session recording, no advertising pixels, and no third-party scripts of any kind. The only cookie we set is the one that keeps you signed in — so there is nothing here to ask your consent for, and we have not put a banner in your way pretending otherwise.

Because we need it to give you the service you asked for, to bill you correctly, and to keep a multi-tenant system safe for the other people on it. We do not sell it, we do not share it for advertising, and we do not use it to train models.

Running the service means other companies handle some of this data on our behalf. This is all of them, and what each one does:

Your jobs run in France and Belgium, the service that schedules them runs in Belgium and the Netherlands, and the database that holds your account is in Ireland. The dashboard runs in the United States, so what you view in it, build logs included, passes through there; payment, email and the GitHub connection involve companies in the United States too.

Confirmations, password resets, invitations, invoices and notices about your account — including a warning before anything is limited over an unpaid invoice. These are part of the service rather than marketing, and we do not send you anything else.

Job records and invoices are kept while you have an account, and afterwards for as long as we need them for tax and accounting. Two of the caches are transient by design: an Actions cache entry unread for seven days and a sticky disk unattached for seven days are deleted automatically, and the documentation says so on the page that sells them.

The Docker layer cache is different: nothing deletes its layers by age. Its layers are built from your source, so they can contain it. They are kept until your organisation’s layer cache reaches 10 GiB, and then we delete the layers that no cache tag of yours still points to and that no push has written for seven days. Until then nothing is deleted at all. A layer a tag still points to is kept however old it is, and each branch that writes the cache has tags of its own, which outlive the branch. If you want layers gone sooner, ask us, as clause 8 says. The documentation says the same, and when a push writes a layer.

A job record includes the test names and failure output we read from any JUnit XML your build writes to disk — the name of each test, the suite it belongs to, and the assertion message or stack trace of any that failed. That is your source code, so it is worth saying exactly what happens to it: it is stored against the job it came from, and it is deleted after 90 days — the same period as the build output it was read from, because keeping the failing assertion after deleting the log it came out of would be deleting the copy and keeping the extract. We do not keep the XML file itself, only the counts and the cases parsed out of it, and only up to a per-job limit we publish in the documentation.

A job record also includes the build output itself. While a job runs we collect its log from inside the machine, because GitHub serves a job’s log only once the job has finished and we would otherwise have nothing to show you on the page you are watching. That is whatever your build prints, so the same applies to it as to the test output above: it is stored against the job it came from, and it is deleted on the same clock. We keep a bounded amount of it — the beginning and the end, with the middle dropped and the gap marked in the text where it happened, so a truncated log says so rather than pretending to be whole. Once GitHub has the completed log we serve theirs instead, because it is the complete one.

Build output and test results are deleted after 90 days. That is the same period GitHub keeps Actions logs for by default, so a log disappears from here at about the time it disappears from GitHub. It is deleted by something that runs on its own; it does not wait for you to ask. A job whose log has aged out still says so — it is recorded as deleted for age rather than quietly becoming a job we never watched, and a job whose test cases have aged out still shows that its tests ran and how many failed. It no longer names them.

The rest of the job record is kept longer. How long a job ran, which machine size it used and what it cost are what an invoice is argued from, and an invoice can be queried long after 90 days. Those are not your build output and they are not deleted with it.

The output of a Terraform plan or apply is kept until you delete it. It goes when you delete its run or the workspace it ran in, through the API; nothing deletes it by age.

Deleting something does not reach our backups at once. A deleted log or test result can survive in an encrypted backup for up to eight more days. The same is true of anything else deleted from our databases, a Terraform run or workspace included. We keep those backups so that we can recover from a failure, and a backup that ages out is deleted with everything in it.

The other retention periods are still being set, including how long we keep email you send us. They will be stated here as specific numbers before this policy comes into force, rather than left as “as long as necessary”, which tells you nothing. Until then the honest answer is the one above: apart from build output, nothing deletes a job record automatically today, so a job record and everything else filed against it is kept until you ask us to delete it or close the account.

A copy of what we hold about you, a correction, or deletion. Write to legal@runners.io and we will answer. Where we cannot delete something — an invoice we are required to keep, for instance — we will tell you which record and why rather than refusing in general terms.

You can disconnect us from your repositories at any time from your GitHub settings, without asking us.

If personal data is exposed in a way that puts you at risk, we will tell the people affected and say what happened, what we know, and what we have done. The notification obligations that apply to us as a matter of law will be stated here alongside the entity details.

We will email existing customers before a change that affects them takes effect, and this page will carry the date it came into force.