1.Scope of this notice
This notice covers the running of the Runjet Service and the running of this site. It concerns a visitor to runjet.dev, a Customer who has registered a Workspace, and every person who holds an Account in one. Capitalised words have the meaning the Terms of Service at runjet.dev/terms give them.
Where the Terms describe how the Service behaves — what the Service sees, how long it keeps run output, when a Workspace is deleted — what they say governs, and this document points at them rather than writing it a second time. If the two ever diverge, that is a bug to report, not a matter of interpretation.
2.Controller and processor
The controller is Tomáš Jablonický, a sole trader registered in the Czech Trade Licensing Register (živnostenský rejstřík), Company ID (IČO) 87666570, Czech Republic. The Provider has not appointed a data protection officer and is not required to under Article 37 of the Regulation. The address for anything concerning personal data is hello@runjet.dev.
For some data the Provider is the controller and for other data the processor, and that difference decides who to ask. Controller for the data the Service needs in order to work at all: Accounts, sign-ins, the billing address, the audit log, registrations. Processor for everything the Customer puts into the Service — job names, command text, Agent names and tags — and for everything the Customer’s runs print.
There the Provider acts on the Customer’s instructions and has no way of knowing whose data ended up in that content. A person who finds their data in it therefore goes to the Customer; the section Data processing agreement describes what the Provider will do for the Customer in such a case.
3.What is processed
For every Account the Service holds an email address, the name given when the invitation was accepted, a hash of the password, and records of sessions. The name given is usually a person’s real name, because that is what the field is for.
For a Workspace the Service holds its name and display name, the billing email, the declared legal form and a registration number if one was entered. For an individual and for a sole trader both of those are data about a particular person, and the display name is usually their own. The Provider does not verify a registration number against any register. At registration the Workspace also records the version of the Terms of Service the registering person agreed to, and when.
The registration form creates a record before anyone has finished it. That record holds the email address, the name given, the chosen workspace name, the declared legal form, a registration number, and the IP address the form was submitted from. A registration whose confirmation link ran out after 48 hours is deleted thirty days after the link ran out, and so is one that failed or found its name taken. A completed registration is not deleted: it also carries the version and time of agreement to the Terms, and how long to keep it has not been decided yet.
The audit log records who did what in a Workspace. Every row carries the email address of the person who acted and the IP address they acted from. Failed sign-ins are recorded too, including the address as it was typed into the form — so it may be the address of somebody who never had any interest in the Service and whom somebody entered by mistake.
For every Agent the Service holds its name, version, protocol, operating system and architecture, the name of the account it runs jobs under, and the IP address it reports in from. An Agent’s name is typed by the admin who enrols it and is commonly the name of the machine. The Service does not see the host name, its local addresses, hardware addresses or kernel version, and the Agent does not send them.
Anything can end up in the content a Customer puts into the Service: a job name, command text, a tag, the name of an API token. An API token additionally remembers the email address of whoever created it, and that stays in it after the Account in question is gone. Run output is whatever the command printed, and over that the Provider has no control at all.
For every email sent, the Service keeps a record with the recipient’s address, the subject and the template used; that includes the confirmation of the contract, which carries the Terms of Service as a PDF. So as not to flood an address, the Service also holds, for one day, the address and time of each registration confirmation email, and sends no more than five of them to one address in a day.
The Service’s request log records the method, path, status code, byte count and duration of every request. No line of it holds an email address; where a user has to be identified, their internal identifier is used. Only the lines about a sign-in, a failed sign-in, a request refused for exceeding a rate limit and a refused Agent enrolment hold an IP address.
The Provider holds no payment details. The card, the billing address and the tax identification number are held by Stripe; all the Service keeps of it are the customer and subscription identifiers.
4.Legal bases
Account, Workspace and billing data are processed so that the Provider can perform the contract with the Customer, under Article 6(1)(b) of the Regulation. Without them there is nobody to provide the Service to and nobody to bill. The data from the registration form rests on the same basis, as steps taken before entering into a contract.
The audit log, the limits on sign-in attempts and on registration confirmation emails, the record of emails sent and the request logs rest on legitimate interest under Article 6(1)(f). The interest is threefold: a Customer must be able to find out who did what in their Workspace, the Provider must be able to show that a notice or a confirmation went out, and it must be able to defend the Service and the recipients of its emails against abuse. Processing on this basis can be objected to, as the section Your rights says.
The content a Customer puts into the Service is not processed by the Provider on a basis of its own. It is processed on the Customer’s instructions, as a processor, and the legal basis for that processing is the Customer’s. The exception is reading a Workspace’s data to investigate abuse or a security incident, which the Terms of Service allow the Provider: for that the Provider is controller and relies on legitimate interest under Article 6(1)(f), namely defending the Service, its Customers and third parties. It reads only as much as the investigation needs, and that processing can be objected to like any other on this basis. Reading to provide support the Customer asked for is the Customer’s instruction and not an exception.
Accounting records are kept because the law requires it, under Article 6(1)(c). They are issued by Stripe on the Provider’s behalf. On the same basis the Provider sends the confirmation of the contract with the Terms of Service as a PDF, which the Civil Code requires towards a consumer.
Consent under Article 6(1)(a) applies to one place only, the optional category in the cookie banner. What is behind that category is described in the section Cookies on this site. Consent can be withdrawn at any time in the banner, which the Cookies link in the site’s footer opens again; withdrawing it does not affect the lawfulness of processing before it.
5.How long data is kept
The periods tied to the life of a Workspace are described in the Terms of Service and are the same periods: a suspended Workspace stays readable for thirty days, then it is deleted, and thirty days after deletion it is purged. Purging drops the Workspace’s database with everything that was in it.
Run rows are kept for as long as the Workspace exists, on every Plan. Output text is kept for the window of the Plan and then swept; a shorter window never reaches back over text written under a longer one.
The audit log is not swept for as long as the Workspace exists. That is deliberate rather than an oversight: a record that can be shortened does not answer the question it exists for.
A session expires thirty days after signing in, and using it does not extend that; the record of an expired session is deleted within the hour.
The record of emails sent is kept for one year, the record of registration confirmation emails for one day, and the request log for thirty days. A registration that was not completed, failed or found its name taken is deleted thirty days after its confirmation link ran out. A completed registration is not deleted for now and no retention period has been set for it; that is an open question rather than a chosen policy, and this paragraph states it because it is information you are entitled to.
7.Sub-processors
Stripe handles payments and invoicing. It holds the payment details, the billing address and the tax identification number, and issues documents on the Provider’s behalf.
Cloudflare hosts this site and the manual at docs.runjet.dev, serves the dashboard at app.runjet.dev, holds DNS for the whole runjet.dev domain, and stands in front of the API at api.runjet.dev as an intermediary. It therefore sees the IP address and the requests of the site’s visitors and of the dashboard’s and the API’s users. The Provider relies for this on legitimate interest in delivering and protecting the site and the Service, under Article 6(1)(f).
GitHub hosts the repository the Software is downloaded from. No customer data is held there.
This list does not name a hosting provider or an email sender, because neither has been chosen and the Service is not deployed. They will be added here before the Service starts running. Until then this list is incomplete, and that is said here precisely so that it cannot be taken for a complete one.
The Provider uses no analytics, no error reporting and no session replay.
8.Transfers outside the European Union
Stripe, Cloudflare and GitHub are US companies, and processing by them may mean personal data is transferred outside the European Union.
Where the Service’s databases will be stored has not been decided, and it is that decision which determines whether, and how far, any transfer outside the Union takes place. This section will be completed together with the previous one, and before the Service starts running.
9.Your rights
The Regulation gives you the right of access to data concerning you, and the rights to rectification, erasure, restriction of processing, portability, and to object to processing founded on legitimate interest. The Provider does not use the data for profiling or automated decision-making. You have these rights regardless of what the product can do.
That last sentence is here because for some rights there is currently a gap between the right and a button. A data export is something a Workspace admin can do and it is an export of the whole Workspace; an individual Account has no way to download only its own data. On their own behalf, anyone can change their name and their password.
Deleting an Account, which an admin can do, today means the Account stops being usable. The email address and the name in it remain, as do the rows in the audit log carrying the same address, and the record of emails sent remains until it expires after a year. Complete removal happens only when the whole Workspace is purged.
To exercise a right the product cannot serve on its own, write to hello@runjet.dev and the Provider will carry it out by hand. That is a more honest answer than a button promising more than there is behind it.
10.How to exercise them
Write to hello@runjet.dev. It is read by one person, the same one who builds and runs the Service.
The Provider answers without undue delay and at the latest within one month of receiving the request. Where a request is complex, or where there are several, the period may be extended by two further months; the Provider will tell you of the extension and its reason within a month of receiving the request.
The Provider may ask you to establish your identity where there is reasonable doubt about who made the request. That is a protection of your data rather than an obstacle: handing the contents of an Account to somebody merely claiming to hold it is a worse mistake than delaying one request.
Where a request concerns content a Customer put into the Service, the Provider passes it to the Customer and tells you so. For that content the Provider is a processor and may not deal with it other than on instruction.
11.Data processing agreement
For a Customer who is not a consumer, this section is the data processing agreement under Article 28 of the Regulation and forms part of the Terms of Service.
The subject matter of the processing is the provision of the Service described in the Terms, and it lasts for as long as the Workspace exists. The nature of the processing is storage, transmission to the Customer’s Agents, display in the application, and export. What is processed is the data the Customer puts into the Service and whatever the Customer’s runs print. The data subjects are the people whose data appears in that content; who they are is known to the Customer and not to the Provider.
The Provider processes that data only on the Customer’s documented instructions. The instruction is the use of the Service in accordance with the Terms; any other instruction is given by email to hello@runjet.dev. Where the Provider considers an instruction to infringe the Regulation, it will say so to the Customer. The exception is investigating abuse or a security incident, which the Terms allow: there the Provider reads a Workspace’s data for a purpose of its own, is controller for it, and the section Legal bases gives the basis.
Persons who come into contact with the data are bound by confidentiality. The Service is run by one person, so that person is the Provider.
The Provider takes measures to secure the data under Article 32. What the Service does towards that is described in the Terms of Service: every Workspace is its own database, passwords are stored as hashes, connections are encrypted, the Service never holds the values of secrets, and commands for Agents are signed with the Workspace’s key.
The Provider may engage a further processor only by imposing the same obligations on it. Who that is today is listed in the section Sub-processors, and that same section says why the list is not yet complete. The Provider will tell the Customer in advance of a change in the sub-processors engaged, and the Customer may object to it.
The Provider assists the Customer in responding to requests from data subjects and in meeting the obligations under Articles 32 to 36, to the extent appropriate to the nature of the processing and the data available to it.
When provision of the Service ends, the Provider removes the data in the manner and within the periods described by the section The life of a Workspace in the Terms. The Customer takes its own export while the Workspace is still readable; after deletion that is no longer possible.
The Provider will make available to the Customer the information needed to demonstrate compliance with these obligations, and will allow an audit. Given the size of the operation, an audit is conducted by providing information and answering questions; an inspection on site is arranged in advance.
12.Personal data breaches
Where the Provider becomes aware of a personal data breach, it notifies the supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the risk is high, the Provider also informs the people affected.
For content the Provider processes as a processor, it is the Customer who notifies, as controller. The Provider will tell the Customer of a breach without undue delay so that they can.
The promise in the first paragraph is about notification and not about detection, and here that difference matters. The Service has no mechanism today that would notice a breach by itself and raise an alarm: the limit on sign-in attempts is held in the memory of the process, is empty after a restart and informs nobody, and failed sign-ins do reach the audit log but nothing evaluates them. Noticing therefore depends today on somebody looking.
13.Complaint to the supervisory authority
If you consider that the Provider is handling your data contrary to the Regulation, you can complain to the Office for Personal Data Protection (Úřad pro ochranu osobních údajů), Pplk. Sochora 727/27, 170 00 Prague 7, uoou.gov.cz.
That is a different authority from the Czech Trade Inspection Authority, which the Terms of Service name for consumer disputes. Personal data is dealt with by the Office for Personal Data Protection and consumer disputes by the Czech Trade Inspection Authority, and a complaint filed with the wrong one is delayed until it reaches the right one.
You can complain without having come to the Provider first. You are welcome to, and it is usually quicker.
14.Contact
hello@runjet.dev. On matters of personal data it is the same address as for everything else; the Service is run by one person, and a second mailbox would only be a second place to write to and get no answer.
The controller is Tomáš Jablonický, Company ID (IČO) 87666570, a sole trader registered in the Czech Trade Licensing Register. The imprint at runjet.dev/imprint says the same.
Questions about this document? hello@runjet.dev