Subprocessors and data flows

Last updated: 2026-10-22

This document describes the key subprocessors used by Patcherly and how data flows through the system. It supports our Privacy Policy and Data Processing Agreement (DPA).

Subprocessors (key list)

We will inform you of any new or replacement subprocessor with reasonable notice, as set out in our Data Processing Agreement.

Data used for AI

• What is sent to AI providers: For each analysis, error messages, stack traces, and limited code/file context (e.g. relevant lines) are sent to the configured AI provider (e.g. OpenAI, Anthropic, SpaceXSI / xAI) through Patcherly’s platform. The system can use your own API key (BYOK) or the platform key. This matches the Privacy Policy description of analysis and AI processing.
• Sanitisation and limits: Official connector software applies best-effort pattern redaction to file or code excerpts and to log lines / tracebacks before transmission, using the same general approach as for excerpts (see Privacy Policy). That reduces many common accidental secret shapes but is not exhaustive; secure logging on your side remains essential.
• What we do not send to AI providers: We do not send your full codebase, bulk log files, or complete file contents - only limited excerpts and error context for the analysis request. Bring-your-own-key (BYOK) credentials you configure for your organisation are stored in the platform and used only to call the provider on your behalf; they are not included in the analysis content as payload data.
• Per-organisation patch-efficacy (Patcherly only, not third-party model training): We may record whether a suggested fix succeeded, failed, or was rolled back on every plan. On paid plans (Core and Pro, the “patch memory” feature), that operational signal - scoped to your organisation’s account - is fed back into future AI analysis so we do not keep proposing fixes that did not work for you. Your code is not used to train OpenAI, Anthropic, SpaceXSI / xAI, or any other foundation model; this learning happens inside Patcherly only and is described in the Privacy Policy.

Data flow summary

1. Detection: Patcherly-provided connector software installed on your targets reads logs or output from your environment and transmits error and context data to Patcherly over encrypted connections. Operational error and workflow data are stored in the operational data store; account, organisation, and target metadata are held in Patcherly’s primary account systems (see Privacy Policy for separation).
2. Analysis: When analysis is requested, Patcherly sends only the necessary error and code context to the chosen AI provider, as described under “Data used for AI” and the Privacy Policy.
3. Billing: Stripe receives billing-related data (customer ID, subscription, payment method metadata) from the platform; the platform does not send full error or code content to Stripe.
4. Optional chat notifications: When a workspace connects Slack, Discord, Microsoft Teams, or an other-webhook URL, Patcherly sends configured notification text to the chosen channel or endpoint; OAuth tokens for connected platforms are stored encrypted in our primary account systems. We do not receive chat message history from those platforms.
5. Optional Sign in with GitHub or Google: When you choose those providers, Patcherly redirects you to the provider, exchanges a one-time authorization code, and stores only a linked provider identity (provider name, provider user id, verified email, link time). Scopes for Google Sign-In are limited to openid email profile; for GitHub, read:user user:email. We do not store GitHub or Google access or refresh tokens for dashboard Sign-In, and we do not use Sign-In to read repository contents, Gmail, Drive, or Analytics. See the Privacy Policy §2A.
6. Optional GitHub App (Repo Pull Requests): When a workspace installs the Patcherly GitHub App and enables PR delivery on a site, Patcherly uses short-lived installation tokens to open pull requests on the linked repository and receives GitHub webhooks to update PR/error status. This is separate from Sign-In and does not use Sign-In OAuth scopes. See the Privacy Policy.
7. Optional hosted MCP: When you connect an AI assistant or IDE, you approve scopes in the Patcherly dashboard; Patcherly issues its own OAuth tokens for the MCP client. Tools may access workspace data already available to your account under those scopes. Tokens can be revoked under Profile → MCP. This flow does not use Google Sign-In scopes.
8. Optional Patcherly Mobile push: When you use the mobile app and enable events under push preferences, Patcherly stores Expo push device tokens in primary account systems and sends notification title/body/data via Expo Push to Apple APNs and Google FCM. Session cookies stay in the mobile WebView; we do not use a separate native JWT for dashboard API calls. Tokens are removed on sign-out, unregister, or account deletion.
9. Backups: Patcherly-side: Disaster-recovery backups of our own service data may be stored locally or offloaded; they are protected with encryption in transit and at rest where applicable, and optional application-level GPG encryption of backup files may be enabled by Patcherly Staff. These are not copies of your full source tree or of connector pre-apply snapshots. Patcherly Staff can perform a crisis restore from those backups, which replaces Patcherly service data—this is an internal recovery action, not customer self-service. Customer-side: File snapshots the connector takes immediately before applying a patch are created and stored only on your environment; Patcherly does not receive, access, transmit, or retain them. On WordPress, you may delete that on-server folder yourself, or enable Cleanup on uninstall in the plugin so it is removed when you delete the connector.

Contact

For questions about subprocessors or data flows: [email protected]. For general support: [email protected].