TapfleetSubprocessors
Last updated: [date]
These are the third parties Tapfleet, operated by [Company Legal Name], uses to run the Service and that may process customer personal data on our behalf. This page is the list referred to in Annex III of the DPA, and it is kept current: a subprocessor is not put into the production path before it appears here.
1. Current subprocessors
| Subprocessor | Role | Location | Data it can see |
|---|---|---|---|
| Hetzner Online GmbH | Control plane and panel compute, PostgreSQL database, object storage for builds and artifacts, and the Android device hosts | Falkenstein, Germany (EU) | Everything the platform stores: app builds, screenshots, video, logs, hierarchy dumps, run and test metadata, account and audit records |
| MacStadium (Orka) | macOS hosts for the iOS device pool — ephemeral virtual machines that run the runner, Maestro and the customer's app build | Dublin, Ireland (EU) | The app build, and whatever appears on screen during a run, before the artifacts are uploaded. Machines are reset between jobs |
| GitHub, Inc. | Source hosting for our own code, and the GitHub App integration that posts checks on customer pull requests | Per GitHub's hosting | For customer checks only: pull-request metadata, diffs and check-run status, on the repositories the customer explicitly installs the App on |
| BrowserStack | Broker for rented real devices, used only when an organisation opts in and supplies its own BrowserStack account | Per BrowserStack's own regions | The app build and on-device session activity for brokered runs only. BrowserStack re-signs the build on its side |
| Slack Technologies | Delivery of run and failure notifications to a channel the organisation configures | Per Slack's hosting | Only the notification payload — run status, top failure, report link. Secrets are masked before any outbound message |
| PagerDuty, Inc. | Critical-issue alerting for organisations that configure it | Per PagerDuty's hosting | Only the alert payload — issue title, severity, project |
Notes on scope:
- Hetzner and MacStadium are the only subprocessors in the path of every run. The rest are conditional: GitHub only for repositories you install the App on, BrowserStack only when you opt into brokered devices, Slack and PagerDuty only when you configure them.
- Region is pinned per organisation and defaults to the EU. There is no cross-region replication of customer data.
- A runner you host yourself never leaves your own network. We see only the results and artifacts it uploads.
2. Not our subprocessors
Some services process your data because you connected them and instructed us to route to them. They act as your own processors under your own agreements, and we are not a party to those contracts:
| Service | Why it is yours, not ours |
|---|---|
| Your model provider (Anthropic, OpenAI, or another) | The Service is bring-your-own-key. A model call happens only when your organisation has stored its own key, is authorised by that key, and is billed to your own provider account. What may be sent is bounded by your model data policy (hierarchy, screenshots, logs — screenshots and logs off by default). With no key stored, no call to an external model provider is made at all |
| Your own agent endpoint | We deliver signed failure bundles to an HTTP endpoint you operate and configure |
| Slack, PagerDuty, Jira, GitLab, and other channels you connect | Where you configure the destination with your own credentials, the delivery is on your instruction. Slack and PagerDuty also appear in section 1 because we operate the delivery path |
| BrowserStack, where you supply your own account | The device rental is on your own contract with them |
| Your CI system, your repositories and your ticket system | We read them only through connectors you configure and only within the scope you grant |
3. Change notice
Before a new subprocessor starts processing customer personal data, we will:
- add it to the table in section 1 with its role, location and data categories, and move the "Last updated" date;
- notify customers at least 30 days in advance, at the notice address on the account;
- give the customer that notice period to object on reasonable data protection grounds, under section 7 of the DPA. If we cannot offer an alternative, the customer may terminate the affected part of the Service without penalty for the unused prepaid term.
An emergency replacement — where a subprocessor fails and the Service cannot run without a substitute — is made with as much notice as circumstances allow, and the objection right still applies afterwards.
To be notified of changes to this page, contact [Contact Email].
4. Internal source
This page is the customer-facing view of the vendor register in docs/compliance/vendor-management.md, which also records each vendor's owner, review cadence and the evidence held for it. The two are diffed for consistency at each review; where they disagree, the vendor register is corrected and this page is republished.