A subprocessor is a third party we use to provide Denly that may process personal data on our behalf. This page lists every one currently in use, what each does for us, what it receives, and where it operates. It is referenced from our Privacy policy and our Data Processing Addendum, and it is kept in sync with the code: this table is generated from the same list the service itself uses, not retyped by hand.
| Subprocessor | Role | Data received | Region |
|---|---|---|---|
| Supabase | Authentication (Supabase Auth) and the control database (Postgres, PostgREST, Realtime). | Account identity (email, sign-in provider), org/project/task metadata, task activity (encrypted under E2E when enabled), audit log, notification records. | The region selected when the Supabase project was created (operator-configured at setup). |
| Google Cloud Platform | Hosting (Cloud Run), structured request/query logs (Cloud Logging), the cost-baseline dashboard (Cloud Monitoring), secrets (Secret Manager), and release artifacts (Cloud Storage). | Request metadata (IP, timing, request id, sampled query shape – never query values, see docs/data-map.md), release binaries, encrypted secrets. | us-central1 (Iowa) by default; operator-configured via GCP_REGION at deploy time. |
| GitHub | Code host, via a scoped GitHub App installation you authorize. Used to open pull requests, read repository metadata, and (if you use the optional skill library) sync community skills. | Repository names, branch/commit/PR metadata. Never your source code contents through us – your runner talks to GitHub directly for the actual code. | GitHub's own infrastructure (primarily United States). |
| GitLab optional | Optional second code host, for organizations that connect GitLab instead of (or alongside) GitHub. Same nature as the GitHub relationship above. | Repository names, branch/commit/MR metadata, for connected projects only. | GitLab.com's own infrastructure, or a self-managed GitLab instance you point us at. |
| Polar | Merchant of record. Handles checkout, payment, tax, and provides subscription status back to us. | Subscription/plan status and the purchaser's user id. We do not receive or store card details – Polar handles that directly. | Polar's own infrastructure, with payments and payouts processed via Stripe. |
| Brevo | Transactional email: invites, digests, and notification delivery. | Recipient email address and name, and the notification content being sent (e.g. an invite link, a task's title). | EU (Brevo is a French company; primary processing in the EU). |
| Slack optional | Optional per-workspace integration: outbound activity notifications to a channel you choose, and inbound webhook events if you wire one up. | Whatever your configured notification includes (typically task title, stage, and a dashboard link) – only for workspaces that connect it. | Slack's own infrastructure (primarily United States). |
| Sentry optional | Optional error-monitoring, for diagnostics. Off by default on this deployment – active only if the operator sets SENTRY_DSN. | Stack traces and request context at the moment of an unhandled error. Never task content. | Operator-configured (depends on the Sentry project's own region setting). |
We may add or change subprocessors as the Service evolves. Material additions will be reflected here with an updated effective date. If you want to be notified of changes rather than checking this page, contact us at legal@denly.dev.
If you have a reasonable, documented objection to a new subprocessor on data-protection grounds, contact us before the change takes effect. We will work with you in good faith to address it; if we cannot, you may terminate the affected service as described in our Terms of service.