Privacy Policy.
The boundary, written down.

1. Who we are

The controller of the personal data described in this policy is Registered company name — to be completed , Legal form — to be completed , of Registered office address — to be completed , tax identification number CIF/NIF — to be completed , registered at Commercial registry entry — to be completed .

Privacy enquiries and data subject requests: Privacy contact email — to be completed , or by post to the registered address above.

We have not appointed a Data Protection Officer, and Article 37 GDPR does not require one for this processing: the account service carries out no regular and systematic monitoring of data subjects on a large scale, and processes no special category or criminal-offence data. Privacy enquiries are handled at the address above.

In this policy, RERUN means the desktop application and the account service described below.

2. Two planes: the account service and your Mac

RERUN is deliberately split into two systems that do not exchange test data. Reading the rest of this policy is much easier once the split is clear.

The account service (control plane)

This website and its API. It is a Laravel application operated by us. It exists to answer four questions and nothing else: who you are, which organization you belong to, whether your licence is valid, and which devices are activated against it. We are the controller for the personal data it holds.

The desktop application (data plane)

The RERUN application runs on the customer's Mac. Recordings, flows, session state, cookies imported by the customer, screenshots, DOM snapshots and run evidence are created and stored there, in a project store and evidence directory on that machine. RERUN has no hosted execution backend, and the account service has no API through which any of it could be sent to us.

For everything processed inside the desktop application, the customer is the controller of their own data. We are not a processor for it, because we never receive it and have no means of accessing it. What that data contains, who may run tests against which systems, and how the resulting evidence is stored, backed up or shared, are decisions the customer makes on their own equipment.

Two honest caveats, both of which appear in the product's own documentation. "Local-first" describes RERUN's control plane, not an air-gapped browser: the embedded browser and the Playwright runner still contact the application you are testing and its dependencies, exactly as a tester's own browser would. And if you enable an AI step, your chosen model provider receives a bounded, redacted payload — see section 7.

3. What the account service collects

The following is the complete category list held by the account service. It is drawn from the service's own database schema, not from a marketing summary.

Account and identity

• Your name and email address.
• Your password, stored only as a cryptographic hash. We never hold it in a form we could read.
• Email verification state and the timestamp of verification.
• A session cookie, a CSRF token cookie and — only if you tick "Keep me signed in on this device" — a persistent authentication cookie. These are strictly necessary for the portal to work. The account service sets no analytics, advertising or profiling cookies, and loads no third-party scripts.

Organization, plan and entitlement

• Organization name and identifier, and your role within it (owner or member).
• Plan, licence status, seat limit and devices per seat.
• Trial start and end dates, subscription period end and any grace period end.
• An organization licence key, held as a hash plus an encrypted-at-rest copy.

Billing

• The Stripe customer, checkout session, subscription, price, invoice, dispute and refund identifiers associated with your organization, and the state they project onto your licence.
• The payment method brand and the last four digits of the card, as returned to us by Stripe.
• We never receive or store full card numbers. Card details are entered directly into Stripe-hosted Checkout and the Stripe Customer Portal and are held by Stripe, not by us. Billing address and any tax identifiers you enter are collected by Stripe in that hosted flow.

Devices and licences

• For each activated installation: a device name you choose, the platform, the application version, the device's public key and a hash of it, and the activation, last-seen and revocation timestamps.
• For each issued licence lease: an identifier, status, a hash of the signed claims, and the issue, refresh, expiry and revocation timestamps.
• Short-lived, single-use nonces used to prove device identity during activation and lease refresh.

The device public key identifies an installation. It is not a hardware fingerprint of the machine and it carries nothing about what is on it.

Team invitations

• The email address you invite, the role offered, who sent the invitation, and its expiry, acceptance or cancellation state. Invitations expire after seven days.

Audit and security records

• Audit events recording account, membership, device and billing changes: the organization, the acting user, the action, the subject and bounded metadata about the change.
• Ordinary server and application logs generated by operating a web service, including request metadata, error traces and the IP address used for rate limiting on login, registration, activation and device-proof endpoints.

Release metadata

• Application version, platform, architecture, download location, checksum and signature for published builds. This is product metadata, not personal data, but it is listed because a licensed organization's entitlement is checked when a signed update is requested.

4. What the account service never receives

The account service has no endpoint capable of accepting any of the following, and stores none of it:

• URLs of the applications you test, or any part of your browsing history.
• Recorded flows, steps, selectors or assertions.
• DOM snapshots and page content.
• Screenshots and video.
• Cookies, imported cookie exports, local storage, or any browser session or credential.
• Run evidence, results, dossiers or reports.
• AI prompts, model responses and AI provider API keys.

This is a structural property of the system, not a policy promise we could quietly change: those values live in the desktop application's local data plane, and the account service exposes no route through which they could arrive.

5. Why we are allowed to process it

• Performance of a contract (Art. 6(1)(b) GDPR). Creating and maintaining your account and organization, verifying your email address, running the evaluation period, taking payment for the annual licence, issuing and refreshing signed device entitlements, managing Team seats and invitations, and providing support.
• Legitimate interests (Art. 6(1)(f) GDPR). Keeping the service secure and available, and preventing abuse: rate limiting authentication and activation endpoints, detecting licence sharing beyond the purchased seats, keeping audit records of owner and billing actions, and maintaining server logs. Our interest is in operating a licensing service that is not trivially defrauded; the processing is limited to metadata about accounts, devices and requests, and never extends to the content of your testing. You may object at any time under section 10.
• Legal obligation (Art. 6(1)(c) GDPR). Retaining invoices, billing records and tax documentation. Spanish commercial and tax law require it — principally article 30 of the Código de Comercio for accounting books and supporting documents, and article 66 of the Ley General Tributaria for the period during which the tax authority may review a filing — so those records are kept for the statutory retention period for accounting records.
• Consent (Art. 6(1)(a) GDPR). We do not currently send marketing email; the only messages the service sends are transactional — email verification, Team invitations and billing notices. If optional communications are introduced, they will be sent only on the basis of consent you have given and can withdraw at any time. No marketing, newsletter or profiling processing is in use today, which is why none is described here.

6. Who else processes it for us

These are the processors used for the account service. Each acts on our documented instructions under a data processing agreement.

• Payments, tax calculation and billing portal. Stripe Payments Europe, Ltd., processing in Ireland (EU).
• Hosting of the licence control plane. DigitalOcean, LLC, processing in Frankfurt, Germany (EU).
• Transactional email delivery. Provider — to be selected

Two things about that list are worth stating outright. Card details are entered directly into Stripe-hosted Checkout and the Stripe Customer Portal and are held by Stripe, never by us. And the account service, its database and its backups run on DigitalOcean infrastructure in Frankfurt, Germany (EU).

The list is complete. No analytics, advertising, error-monitoring, log-aggregation, support-desk, CDN or third-party backup provider processes personal data for the account service. If one is ever added, this section changes before it starts processing.

We do not sell personal data, and we do not disclose it to third parties for their own purposes. We may disclose data where we are legally required to do so, in which case we will notify you unless the law forbids it.

7. AI providers, when you choose to use one

AI is off unless a flow contains an explicit AI step. Deterministic recording, replay and evidence never make a model request. If you add an AI step and configure a provider, the request goes from your Mac directly to the provider, under your own account and your own API key or CLI session. It does not pass through us. We are not the controller or the processor for it, and we never see the key, the prompt or the response.

For the commercial paths, an AI step is an assertion only: one structured decision over a bounded, redacted payload. What leaves the machine is limited to:

• the redacted instruction for that step;
• a sanitized URL and page title;
• bounded visible text from the page;
• candidate DOM element metadata;
• the flag store: false, asking the provider not to retain the request.

No screenshot is sent on the commercial paths. The Claude harness uses the same text-only boundary as OpenAI BYOK, in assertion-only, no-tools mode. Each AI step writes a local egress receipt recording the provider, the model, the field categories sent, the redaction policy applied and the latency, so the customer can audit what left the machine.

Two limits worth stating plainly. Development-only Codex and custom executors can receive a DOM-masked screenshot, and disclose that in the egress receipt; they are disabled in commercial builds. And store: false is a request to the provider — the provider's own terms, retention and any abuse-monitoring window govern what actually happens to that payload. Before enabling an AI step, review the terms of the provider account you are using, because it is your contract with them, not ours.

Redaction is applied before the payload is built: editable values are replaced, fill and select values are removed, and common bearer token, API key, JWT, email, secret-assignment and sensitive query-parameter patterns are stripped. This is defense in depth. It is not a guarantee that arbitrary page content contains nothing sensitive, and you should treat the decision to enable an AI step over a privileged session as a decision with real consequences.

8. International transfers

The processors named in section 6 are established in the European Economic Area and process this data there. Where one of them relies on onward transfers outside the EEA — a global payment processor supporting its own service, for example — that transfer is made under an adequacy decision or under the Standard Contractual Clauses (2021/914) incorporated into that processor's data processing agreement, with the supplementary measures the assessment of that transfer calls for. A copy of the safeguards relied on for a given processor can be requested from Privacy contact email — to be completed .

Concretely: the account service, its database and its backups are hosted by DigitalOcean in Frankfurt, Germany (EU), and the processing location of every other processor is stated next to it in section 6.

Note that this section covers only the account service. If you enable an AI step, the destination and legal basis of that transfer are determined by your own agreement with your model provider, not by us.

9. How long we keep it

The verifiable part first: run evidence, screenshots, DOM snapshots, flows and session data are not retained by us at all — at any duration — because we never receive them. Their lifetime is controlled entirely by the customer through the desktop application's own retention controls and the customer's own backup policy.

For the account service:

• Account and organization records: deleted within 30 days from termination, or on request if you close the account earlier.
• Billing, invoice and tax records: kept for the statutory retention period for accounting records, because the law requires it. This is the one category an erasure request cannot reach while the obligation lasts.
• Device activation and licence lease records: kept while the licence is live, so a revoked device cannot silently reclaim its slot, and deleted with the organization within 30 days from termination. Revoked leases keep only their identifier, claims hash and timestamps in the meantime.
• Audit events: kept for the life of the organization and deleted with it within 30 days from termination — except entries that evidence a billing transaction, which follow the billing retention above.
• Server and security logs: kept only for as long as they are useful for security, abuse prevention and troubleshooting, and rotated on the hosting platform's schedule. They are not kept as a permanent record and are not used for any other purpose.
• Team invitations: expire after seven days; cancelled and expired records are kept as part of the organization's membership history and deleted with it within 30 days from termination.
• Backups: database backups are taken and rotated by the hosting provider. An erasure request is executed in the live database straight away and works out of the backups as they rotate; we do not restore a backup in order to reinstate deleted personal data. No contractual backup frequency or restore-point commitment is offered.

Device nonces are short-lived by design and are discarded once they expire.

10. Your rights

Under the GDPR you have the right to:

• Access — obtain confirmation of whether we process your personal data and a copy of it.
• Rectification — have inaccurate data corrected and incomplete data completed.
• Erasure — have your data deleted where one of the grounds in Article 17 applies. Records we are legally required to keep, such as invoices, are the usual exception.
• Restriction — have processing limited while a dispute about accuracy or legitimate interests is resolved.
• Portability — receive the data you provided to us in a structured, commonly used, machine-readable format, and have it transmitted to another controller where technically feasible.
• Objection — object at any time to processing based on our legitimate interests, on grounds relating to your particular situation.
• Withdraw consent — where processing is based on consent, withdraw it at any time, without affecting the lawfulness of processing before withdrawal.

Some of these you can exercise yourself, immediately, from your account: you can correct your name and email, deactivate a device, cancel a pending invitation, remove a Team member, and manage or cancel your subscription through the Stripe Customer Portal.

For anything else, write to Privacy contact email — to be completed from the address on your account, or by post to the registered address in section 1. We will respond within one month of receiving your request, extendable by two further months where the request is complex, in which case we will tell you within the first month. We may ask you for information needed to confirm your identity, and for nothing beyond that.

If you are a member of an organization licensed by your employer, note that the organization owner can see the account and device records belonging to that organization, and can remove you from it.

11. Security: what is implemented, and what is not

We describe only controls that exist. RERUN holds no compliance certification, and we make no claim to one.

Implemented in the desktop application

• Provider keys in operating system secure storage. An API key you configure is protected by Electron safeStorage and is never returned to the renderer process.
• Privacy mode, on by default. Input, textarea, select and editable regions are masked in stored screenshots; editable values are replaced in the DOM snapshot; fill and select values are removed from the stored result; and common bearer, API key, JWT, email, secret-assignment and sensitive query patterns are redacted from stored signals, including in nested frames.
• Owner-only file permissions. Run directories are created with 0700 and artifact files with 0600, where the platform supports it.
• Denied page permissions. Camera, microphone, geolocation and device permission requests from the page under test are rejected by the embedded browser.
• Trace capture off by default. A Playwright trace can preserve page state and authenticated session data, so it is never recorded unless the run is explicitly started with that option.
• Bounded cookie import. Session import reads only a file you explicitly select, is validated, capped at five domains and 500 cookies, and requires confirmation. RERUN does not read Chrome's profile, password store, history, cards or extensions.

Implemented in the account service

• Passwords stored as hashes; email verification through signed, throttled links.
• HTTPS-only canonical host enforcement, secure and HTTP-only session cookies, and CSRF protection on every state-changing route.
• Scoped API tokens for the desktop client and per-endpoint rate limiting on authentication, registration, activation and device-proof endpoints.
• Ed25519-signed, device-bound entitlements with bounded offline leases and revocation; the private signing key stays in the server secret store and never enters the desktop build.
• Card data handled only by Stripe-hosted Checkout and Portal.
• Verified Stripe webhook signatures with idempotent, replay-resistant projection.
• Audit records for owner, membership, device and billing actions.

Limitations we state rather than hide

• RERUN does not encrypt the evidence store. Evidence at rest relies on the operating system and on the customer's own full-disk encryption. Evidence encryption independent of the operating system is not a feature of the product.
• No compliance certification is claimed. Not ISO 27001, not SOC 2, not HIPAA, not any other.
• No air-gap, Zero Data Retention or tamper-proof artifact claim. The embedded browser and the Playwright runner reach the application under test over the network.
• Redaction is defense in depth, not a guarantee. It cannot prove that arbitrary page content contains nothing sensitive. Full traces, and runs with privacy mode disabled, should be treated as sensitive artifacts.
• Some capabilities are outside the scope of the product. Managed secret vaults, signed reports, scheduled runs, team sync and MDM packaging are not features of RERUN, and none of them is claimed here.
• Breach handling is a process, not a promise of invulnerability. Alerting on the control plane — webhook and mail failures, queue backlog, repeated activation throttles, licence-signing and health-check failures — escalates to the people who operate it, and a suspected personal data breach is assessed as soon as it is known. Where it is notifiable under Article 33, we notify the supervisory authority named in section 12 within 72 hours from becoming aware. Where the breach is likely to result in a high risk to you, we tell affected account holders by email without undue delay, describing what happened, which data was involved and what to do about it. We hold no incident-response retainer and no external forensics contract.

12. Complaints

If you believe we have handled your personal data unlawfully, we would rather hear it first — write to Privacy contact email — to be completed and we will investigate.

You also have the right to lodge a complaint with a supervisory authority at any time, without contacting us first. In Spain this is the Agencia Española de Protección de Datos (AEPD), C/ Jorge Juan 6, 28001 Madrid, www.aepd.es. You may also complain to the supervisory authority of your habitual residence or place of work.

The supervisory authority competent for our establishment, and our lead authority, is the Agencia Española de Protección de Datos (AEPD), www.aepd.es. We have no establishment in another Member State that would move that competence elsewhere.

13. Changes to this policy

We will update this policy when the product's data handling changes — for example if a processor is added or replaced, or if a new feature changes what the account service receives. The "last updated" date at the top always reflects the current version.

Where a change materially affects how we process your personal data, we will notify account holders by email at least 30 days before it takes effect — the same notice period the Terms of Service use for material changes.

Earlier versions are not archived on this site. If you need the version that was in force on a particular date, ask at Privacy contact email — to be completed and we will send you a copy.

14. Contact

Data protection and privacy: Privacy contact email — to be completed .

General and support enquiries: Support email — to be completed .

Postal: Registered company name — to be completed , Registered office address — to be completed .

This policy covers personal data only. The commercial terms of the licence — evaluation period, annual billing, renewal and cancellation — are set out in the Terms of Service.