AnyRun (the Platform) runs on a small number of service providers. A sub-processor is one that handles personal information on our behalf: hosting the database, storing photos, moving money, delivering email. This page lists every provider, what it does for us, what data it touches, and where it runs. It sits alongside the Privacy Policy, which explains what we collect and why; this page explains who else touches it.

We don’t sell personal information, to anyone on this list or off it. The recipients here stand in four different relationships to us:

• Suppliers we engage. Supabase and Cloudflare run the database, the site, the photo storage and the mail. Contract terms require them to protect the data and use it only to deliver their service to us. Resend sits in this group as a second email service.
• Payment networks. When an organiser takes payments, the organiser (not AnyRun) is the merchant with Stripe or PayPal, and both also process transaction data under their own terms, for fraud screening and the anti-money-laundering checks the law requires of them. A payment network handles this data on its own account as well as for us.
• Measurement, behind your consent. Google and Microsoft receive no measurement data until you accept analytics, and if you decline, their tags are not loaded at all. Google is on this list in a second role as well: it receives a wallet pass when you tap "Add to Google Wallet", whatever you chose on the analytics banner, and its entry below sets out every field the pass carries.
• Requests your own browser makes, and registers we query. Map tiles come to you straight from OpenStreetMap, so they see your IP address and we do not see that request. The Australian Business Register and the ACNC charity register get a business number from our server and nothing about you.

This page is part of a contract. The Organiser Agreement says the list published here forms part of that agreement, so an organiser trusting us with their entrants' details is entitled to a complete list.

10 recipients. For each: who they are, what they do for the Platform, the data categories they handle, and where the processing happens.

• Supabase: primary database and sign-in. Hosts the Postgres database everything else depends on: accounts and authentication, entries, results, consent records and organiser data. Data categories: all personal information the Platform stores, with sensitive information such as emergency contacts encrypted at the field level before it ever reaches the database. Location: Sydney, Australia (AWS ap-southeast-2). The database’s home region is Australia. Where another recipient on this page holds information outside Australia, its own entry says so.
• Cloudflare: application edge, bot detection, media storage, photo AI, and email. The application itself runs on Cloudflare Workers, event photos are stored in R2, and Workers AI runs the vision model that reads printed bib numbers for bib matching (no face recognition) and outbound email is sent through Cloudflare's own sending service. Cloudflare also filters automated traffic for us, which it does partly at its edge and partly with a small script it adds to every page (see the Cookie Policy); that script reports browser signals to Cloudflare and nothing from it reaches our own systems. Data categories: traffic to the site passes through Cloudflare's edge; browser and connection signals are assessed for bot detection; event photos are stored and analysed inside Cloudflare's network; every email we send carries your address and the message itself. Location: a global edge network, including the United States and other regions; photo inference runs inside that network. Event media at rest is held in Cloudflare's Oceania region. That region is a placement preference we set when the store is created, so Cloudflare may put an object elsewhere in the Asia-Pacific region (see where your data lives).
• Stripe: card payments, when enabled. Where an organiser takes card payments, Stripe processes them and settles to the organiser's own account there. Your card number travels from your browser to Stripe directly and does not touch our servers. The one payment that runs the other way is an organiser buying credits from AnyRun: for that purchase, AnyRun is the merchant. Data categories: payment card details (held by Stripe), transaction amounts, payer name and email. Location: United States.
• PayPal: payments, when enabled. The alternative payment rail, for events where the organiser has switched it on; payments run through the organiser's own PayPal account. Data categories: the account details PayPal shares with a merchant, and transaction amounts. Location: United States.
• Resend: a second email service. Our mail is sent through Cloudflare (above), and Resend is connected as a second sending service. Data categories: when it sends a message, the recipient's email address and the content of that message. Location: United States.
• Google: measurement tags, and wallet passes. Measurement: our Google Tag Manager container, and the Analytics and Ads tags inside it, load only after you accept analytics; before that, nothing is requested from Google at all (see the Cookie Policy). With that consent Google signals is on, so Google may join a signed-in visitor's sessions across devices and report aggregated demographics and interests to us. Wallet: tapping "Add to Google Wallet" sends that pass to Google in the United States so it can display it, and nothing is sent unless you tap it. A wallet pass cannot be kept in Australia: Google issues and stores it on its own network, and the pass carries only what it needs to display. A race pass carries your name, your distance and bib number, the event's name, start time and venue, a link to your race page, the invoice number of the order that paid for your entry when it has one, and up to two race-day notes the organiser publishes (bag drop, parking). A crew pass carries your name, your role, your shift date and window, where to report, the event's name and venue, a link to your shift page, and up to two briefing notes. It also carries the coordinator's published name and email address. On both, the QR code holds one internal reference number and nothing else (no name, no email) and neither pass carries your email address, your phone number, your date of birth or your emergency contacts. And afterwards: a pass you saved is kept true. A bib change sends Google the corrected version; an entry that is cancelled, refunded or transferred triggers an update marking the saved pass expired, with one line saying why; and a reinstatement reverses that. Those updates carry the fields already listed and nothing new, and there are none at all for an unsaved pass. Data categories: analytics identifiers and page events after consent; the pass fields listed above when you tap the control, and the same fields again on each later correction. Location: United States and Google's global network.
• Microsoft: Clarity heatmaps and session replay, after consent. Loads only if you accept analytics, and only on public pages: it stays off your account and off an organiser console. Text inputs are masked. Data categories: pseudonymous interaction telemetry; clicks, scrolls, page paths. Location: United States.
• OpenStreetMap: the map tiles on event and course pages. This one is not a provider we hand your data to. Map tiles are fetched by your browser, directly from OpenStreetMap, which means OpenStreetMap sees your IP address and which map squares you looked at, and we do not see that request. It is not gated behind the consent banner: the map is part of the page you asked for. Data categories: your IP address and the tiles requested. Location: the OpenStreetMap Foundation's tile servers (Europe).
• Australian Business Register: ABN checks. When an organiser or sponsor gives us an ABN, our server asks the ABR whether it is real and who it belongs to. The request carries the business number being checked and nothing about you. Data categories: an ABN, and the business details the register returns. Location: Australia.
• data.gov.au and the ACNC Charity Register: charity checks. To verify the reduced community rate, our server queries the public charity register on data.gov.au: a business or charity number goes out, a registration status comes back, and no participant data is involved. Data categories: an ABN or charity number. Location: Australia.

A payment provider is switched off until an organiser configures it, and no data flows to it before then. Nothing reaches Google for a wallet pass unless you tap the control on your race page or your shift page, and the later corrections in that entry apply to a pass you already saved. Decline the analytics banner and the measurement tags are not requested.

The primary database lives in Sydney and stays there. But some recipients on the list process limited information outside Australia: Cloudflare's edge spans the world, event media is held in Cloudflare's Oceania region as a placement preference and can sit elsewhere in the Asia-Pacific region, the payment providers and the measurement tools operate from the United States, a wallet pass you choose to save goes to Google in the United States, and the map tiles your browser fetches come from Europe. (The two registers we query, the ABR and the ACNC charity register, are Australian.) Each overseas one is a cross-border disclosure under Australian privacy law. Australian Privacy Principle 8 sets the rule: before personal information goes to an overseas recipient, we must take reasonable steps to ensure the recipient handles it consistently with those Principles.

The reasonable steps we take:

• We choose providers with strong, published security and privacy practices: every company we engage maintains its own public security documentation and certifications.
• Each company we engage is bound by contract terms requiring it to protect the data. The infrastructure providers may use it only to deliver their service to us; the payment providers' own fraud and anti-money-laundering uses are the ones described above, nothing broader. The one recipient we hold no contract with is OpenStreetMap, because we send it nothing: your browser fetches the tiles itself, and this page tells you so.
• Each receives only what its job requires. The data categories above are listed per provider, and each transfer carries only its own.

This page is the announcement channel. Before a new sub-processor starts handling personal information, we add it here (same four facts) with reasonable notice on this page. Removing a provider, or narrowing what one receives, can happen at once. Additions and expansions get the notice.

A material change to this list also bumps this document's version (currently 2026-09) and the effective date at the top of this page. Questions about any provider here: support@anyrun.net.

What happens when one of these providers fails, and what happens if something goes wrong. The controls are summarised at /trust, including backups and how a breach is notified. Our business continuity plan and incident response plan are available on request at support@anyrun.net.

No recipient has been added, and no listed recipient has had its scope widened, since this list took effect on 9 September 2026. Every change from that date is listed here, newest first, with the date it takes effect.