Sub-processor catalog
Authoritative list of every third-party processor that may receive customer data. Referenced from the Article 28 DPA template of Iru, the company that builds and operates Hyrax; the customer-facing DPA bundle cites this page for sub-processor disclosure.
Active processors
| Processor | Data shared | DPA / basis | Notes |
|---|---|---|---|
| AWS | Hosting substrate for all customer code, data, operational logs, transactional email, and AI model inference | AWS DPA (account-wide) | All inference runs on Amazon Bedrock managed by Hyrax. We record request metadata and token counts only — no prompt or completion content is written to our logs. Model-provider retention and training terms are governed by AWS's service terms. |
| GitHub | Org/repo connection metadata, install metadata, and webhook deliveries (push payloads include commit metadata + diffs visible to the GitHub App's installed repositories) | GitHub DPA | GitHub is used to connect your organization and repositories. Tokens are short-lived and repo-scoped, never stored long-term. |
| WorkOS | Login identity — email address, and (for social login) the provider account identifier | WorkOS DPA | Authentication provider for customer sign-in (GitHub, Google, or email one-time code). |
| Stripe | Card-on-file, invoice records, and subscription / usage events for billing | Stripe DPA (via Iru's existing Stripe contract) | A Stripe customer record is created lazily the first time your workspace touches a billing feature — subscribing to a paid plan, opening the billing portal, or enabling on-demand overage (or when Hyrax grants your workspace a trial) — never at sign-up. |
| PostHog | Product-usage and job-lifecycle events (workspace id, user id, job id, workflow, outcome). No customer code, no AI model content, no secrets. | PostHog DPA (cloud) | Session replay masks every input and all rendered text by default. |
| Linear | Observation titles, descriptions, file paths, and severity labels — only when the customer configures the integration | Linear DPA (customer is controller of their Linear workspace) | Disable the integration in workspace settings to stop emitting. |
| Loops.so | Account-owner contact details for lifecycle email — email address, display name, plan tier, workspace name, and last-active date. No source code, no AI model content, no secrets. | Loops.so DPA (agreed 2026-06-25, https://loops.so/dpa) | Lifecycle email. Rolling out in phases — currently only the account-created welcome email; later lifecycle events (audit summaries, plan-cap nudges) would add per-event properties such as repo names and finding counts, and each expansion is a reviewed change. When fully enabled, lifecycle email will be opt-out. |
| Resend | Contact details of consented recipients for outreach email — email address and (where captured at signup) name, as the recipient of the message. Recipients span the GTM feed's allowlisted contact lanes: workspace owners, signed-up prospects, and logged-in workspace members (D1 amendments #2/#3 — every lane rides the account-scoped consent basis; internal-domain addresses never cross). No source code, no AI model content, no secrets. | Resend DPA | Delivery provider for Hyrax's outreach email (for example, onboarding follow-ups), sent from a dedicated sending domain (gtm.hyrax.dev) separate from the app's transactional email. |
Advertising and analytics tags
The production web app loads a single Google Tag Manager container, which fans out to advertising and analytics destinations — currently Google Ads only. It sends a page-visit beacon per session and a one-time sign-up conversion event, carrying cookies, device identifiers, and the address of the page that fired them (which can include your workspace and repository names in the URL) — no page content, source code, or AI model content. Google Ads receives that data as an independent controller under its own terms, not as an Article 28 sub-processor, which is why it is disclosed here rather than in the table above.
A second, server-side copy of the sign-up conversion. Alongside the browser tag, our servers are configured to send Google Ads a daily batch confirming which sign-ups arrived through a Google ad click. Each entry carries only four values: the ad-click identifier Google itself appended to the landing address when you arrived, the time of the sign-up, an identifier we derive from those two so the same sign-up is not counted twice, and a fixed marker saying the sign-up happened on the web. It carries no email address, no name, no IP address, no browser or device details, and no page address — and, unlike the browser tag, nothing that identifies a workspace or repository. Sign-ups from the EEA, the UK, Switzerland and the other listed European countries are left out. A sign-up is not included in the batch at all when the sign-up request came from the European Economic Area, the United Kingdom, Switzerland, or one of the other European countries on our list of sign-up countries — or when its country could not be determined — because this server-side copy has no way yet to carry a consent choice. To make that decision, the sign-up record now keeps the two-letter country code our content-delivery network assigned to the sign-up request; the IP address it was derived from is not stored with it, and the country code is never included in anything sent to Google. Google receives the batch as an independent controller on the same terms as the browser tag. It is configured for the production environment only; our development and staging environments send nothing to Google. These batches were initially sent in a verification mode in which Google checked each one and stored nothing; that period has ended and Google now records them. We disclosed this flow from the moment it was configured rather than from the moment recording began, because the batch was transmitted either way.
Removed destinations. Reddit Ads and the Meta (Facebook) Pixel were previously in this container and are no longer present (verified against the served container on 2026-09-09). The server-side copy of the sign-up conversion that had been sent to Reddit when a sign-up arrived through a Reddit ad click — carrying only the ad-click identifier Reddit itself appended to the landing URL, never an email, IP address, or browser details — was removed from the application on 2026-09-09. The two browser tags' domains came out of the site's Content-Security-Policy in the same change; the server-side copy never needed one, because it was sent from our servers rather than from your browser. Nothing reaches Reddit or Meta from the app today. The app refuses to load the container at all on any page whose address carries a credential, so those URLs are never sent. The container is configured outside the application, so this list is maintained by hand rather than derived from our code. It is reviewed on the cadence below, and a destination on a domain we have not already allowed cannot send anything from your browser until that domain is added to the site's Content-Security-Policy, which requires a code change and a deploy. ⚠️ That policy governs what your browser may contact, and nothing our own servers send — which is why every server-side copy is disclosed here individually rather than covered by it. Our application servers are bounded by a separate control: their outbound internet connections pass through a network firewall that denies everything by default and permits only an explicit list of destinations. Adding one requires a code change, review by a second engineer, written approval, and a deploy. ⚠️ Its limits are worth stating plainly: it covers internet egress from those servers — not traffic that stays inside our cloud provider's network, and not every system we run. So it narrows what can reach an undisclosed destination unnoticed; it does not by itself make the list above complete. That list is maintained by hand and reviewed on the cadence below.
Review cadence
This catalog is reviewed on every new outbound integration, quarterly by the Hyrax team, and on every DPA renewal.
Cross-references
- Security — what data we keep, how it's protected, and how to delete it.