Pluralize
Toggle menu

Sub-processors

Last updated: 2026-04-27

This page lists the third parties Pluralize relies on to deliver the Service ("sub-processors"). It is published under Article 28(2) GDPR and as required by Section 6 of our Data Processing Agreement. It is the single source of truth — if a sub-processor is not on this list, we are not using it for tenant personal data.

Current sub-processors

| Sub-processor | Role | Region | Data processed | DPA | | --- | --- | --- | --- | --- | | Vercel Inc. | Application hosting, serverless functions, edge network, Vercel Blob storage for tenant file uploads | United States, with edge presence in the EEA | All HTTP traffic to pluralize.app and to Apps; uploaded files; runtime logs | vercel.com/legal/dpa | | Neon Inc. (Postgres via the Vercel Marketplace) | Managed Postgres database storing developer accounts, app metadata, tenant accounts, sessions, subscription state and app.db.collection records | United States and EU regions; production database is provisioned in the EU (Frankfurt) | Developer and tenant identifiers, password hashes, app data records, session metadata | neon.tech/legal/dpa | | Stripe Payments Europe, Ltd. (with Stripe, Inc. as group sub-processor) | Payment processing via Stripe Connect, Customer Portal, Stripe-hosted Checkout, webhook delivery for subscription state | Ireland (EU) for European customers; United States for US customers | Tenant email and billing identifiers, charge metadata, payment method tokens (Stripe holds card numbers itself as an independent controller) | stripe.com/legal/dpa | | Resend, Inc. | Transactional email delivery (verification, password reset, billing receipts, security notifications) | United States | Recipient email address, message content, delivery status | resend.com/legal/dpa |

We treat each entry above as the minimum scope of data sent to that provider. We do not send tenant data to providers not listed here.

Sub-processors of sub-processors

Each provider above maintains its own list of further sub-processors. By authorising the providers above you also authorise their published sub-processors as of the date of this page. Their lists:

What we do not use

For clarity, the following are explicitly not sub-processors of Pluralize today. If you see a request that suggests they are, please report it.

  • Anthropic — Pluralize itself does not call any LLM provider. Some Apps built on Pluralize choose to call Anthropic on their own; in that case Anthropic is a sub-processor of the App's developer, not of Pluralize.
  • Google Analytics, Plausible, PostHog, Hotjar, Meta Pixel or any other analytics or advertising provider on pluralize.app.
  • AWS, GCP, Azure directly — we use them only indirectly through the providers above.
  • Slack, Notion, Linear, Intercom — used internally by the operator for business administration but never with tenant personal data.

International transfers

The providers above are established in the United States or the European Economic Area. Where personal data is transferred outside the EEA we rely on the EU Standard Contractual Clauses (Decision 2021/914), with Module 3 (processor-to-sub-processor) between Pluralize and the relevant provider. Where the provider is certified, we additionally rely on the EU–US Data Privacy Framework.

Notification of changes

Under Section 6 of the DPA we will publish any intended addition or replacement of a sub-processor on this page at least 30 days before the change takes effect. Developers can object on data-protection grounds by emailing hello@pluralize.app within that window. If we cannot accommodate an objection, the developer may terminate the affected service for convenience and receive a pro-rata refund of prepaid fees.

To be notified of changes by email, sign up by sending the word "subprocessors" in the subject line to hello@pluralize.app from the email associated with your account.

How we choose sub-processors

We deliberately keep the list short. Adding a sub-processor means adding a party that sees tenant data and a contract we have to monitor, so the bar is high. Before onboarding a new provider we evaluate:

  • Necessity — does the provider unlock something we genuinely cannot build, buy or self-host with reasonable effort?
  • Data minimisation — can we send the provider only pseudonymous or partial data, rather than the full tenant record?
  • Legal posture — is there a published DPA, current SCCs (or DPF certification), a security page that maps to a recognised framework (SOC 2, ISO 27001), and a clear sub-processor list of their own?
  • Region — is EU-region processing offered? If not, what supplementary measures (encryption, pseudonymisation) close the gap?
  • Operational maturity — do they have a public status page, a documented incident response process, and a track record of breach notifications?

A provider that does not meet these expectations does not get added, even if it is technically convenient. This is how the list stays at four.

How tenant data flows

The diagram below describes, at a high level, where tenant personal data travels in normal operation:

  1. A tenant's browser hits an endpoint of the App, which forwards the call to Pluralize via the SDK.
  2. Pluralize, running on Vercel functions, validates the session and reads from / writes to Neon Postgres in the EU.
  3. For file uploads, the file is streamed to Vercel Blob.
  4. For billing, the tenant is redirected to Stripe's hosted Checkout or Customer Portal; Stripe then notifies Pluralize via webhook.
  5. For transactional email (verification, password reset, billing receipt), Pluralize hands the message to Resend for delivery.

No tenant data leaves this set of providers. We do not sync to internal CRMs, analytics warehouses or marketing tools.

History

| Date | Change | | --- | --- | | 2026-04-27 | Initial publication: Vercel, Neon, Stripe, Resend |

Questions? Email hello@pluralize.app — we'll route to the right person.