Vendor list
Sub-processors
Last updated: May 26, 2026
This page lists every third-party service that processes Brevlex customer or end-user data on our behalf. It is the single source of truth for our sub-processor list and is updated whenever a sub-processor is added or removed. District procurement teams can link directly to this page from a signed DPA.
If you need a written notice when this list changes, contact support@brevlex.com.
Current sub-processors
AWS Bedrock (Anthropic Claude)
- Purpose
- AI-generated example sentences and mnemonics
- Data category
- Word, learner interests, and learning context (no email, name, or account ID)
- Location
- United States (AWS us-east-1)
Google OAuth
- Purpose
- Optional "Sign in with Google" identity provider
- Data category
- Name, email, and Google account ID at sign-in (only if user selects Google sign-in)
- Location
- United States (global service)
PostHog
- Purpose
- Product analytics — page views and study events
- Data category
- User ID, email (on identify), event metadata. Identify events NOT fired on student (kid-session) routes.
- Location
- United States (app.posthog.com, US cloud)
Sentry
- Purpose
- Error and exception tracking (client, server, edge)
- Data category
- Stack traces, request context, signed-in user ID and email
- Location
- United States (sentry.io US cloud)
Brevo (Sendinblue)
- Purpose
- Transactional email — verification, password reset, invites (primary)
- Data category
- Recipient email, name, and token URLs
- Location
- European Union (France)
SMTP fallback provider
- Purpose
- Transactional email fallback when Brevo is unavailable
- Data category
- Recipient email, name, and token URLs (same as Brevo)
- Location
- Varies by configured SMTP host
Let's Encrypt (ISRG)
- Purpose
- TLS certificate issuance (ACME)
- Data category
- Domain names only
- Location
- United States
DigitalOcean
- Purpose
- VPS hosting (application servers, PostgreSQL, Redis)
- Data category
- All application data at rest and in transit
- Location
- United States (NYC region)
| Name | Purpose | Data category | Location |
|---|---|---|---|
| AWS Bedrock (Anthropic Claude) | AI-generated example sentences and mnemonics | Word, learner interests, and learning context (no email, name, or account ID) | United States (AWS us-east-1) |
| Google OAuth | Optional "Sign in with Google" identity provider | Name, email, and Google account ID at sign-in (only if user selects Google sign-in) | United States (global service) |
| PostHog | Product analytics — page views and study events | User ID, email (on identify), event metadata. Identify events NOT fired on student (kid-session) routes. | United States (app.posthog.com, US cloud) |
| Sentry | Error and exception tracking (client, server, edge) | Stack traces, request context, signed-in user ID and email | United States (sentry.io US cloud) |
| Brevo (Sendinblue) | Transactional email — verification, password reset, invites (primary) | Recipient email, name, and token URLs | European Union (France) |
| SMTP fallback provider | Transactional email fallback when Brevo is unavailable | Recipient email, name, and token URLs (same as Brevo) | Varies by configured SMTP host |
| Let's Encrypt (ISRG) | TLS certificate issuance (ACME) | Domain names only | United States |
| DigitalOcean | VPS hosting (application servers, PostgreSQL, Redis) | All application data at rest and in transit | United States (NYC region) |
Planned / Pilot Sub-processors (not yet active)
The following sub-processors are not currently processing production traffic. They are forward-looking commitments for district SSO and roster-sync integrations and will only be enabled per-district during onboarding once a signed DPA is in place.
- Microsoft Azure AD — SSO for districts using Microsoft 365. Pilot only — activated per-district during onboarding.
- Clever — SIS roster sync. Pilot only — activated per-district during onboarding.
- ClassLink — SIS roster sync. Pilot only — activated per-district during onboarding.
Encryption posture
We document our encryption configuration honestly so district procurement teams can evaluate it without ambiguity. The summary below reflects the production deployment as of the date above; the full attestation covers verification commands, compensating controls, and remediation plans.
- In transit:TLS 1.2+ on all surfaces, terminated at Caddy with Let's Encrypt certificates.
- Passwords: bcrypt (12 rounds for adult accounts).
- 2FA secrets: AES-256-GCM at the application layer, key held in a server-side environment variable.
- PostgreSQL at rest:data lives on the DigitalOcean droplet's local disk (ext4), which is not encrypted at rest by default. No Postgres TDE or whole-database encryption is enabled.
- DigitalOcean Block Storage Volumes: provide AES-256 encryption at rest in the storage cluster. Brevlex does not currently use a Block Storage Volume for the database; migrating to one is on the remediation list.
- Database backups:
pg_dumpoutput is stored on the same droplet disk and is not GPG-wrapped today. Encrypting backup output and moving to an encrypted off-site destination is planned.
The full write-up — production storage topology, verification commands, compliance positioning, and remediation priority order — lives in our internal Encryption-at-Rest Attestation document. District security teams can request the current copy from support@brevlex.com.
Infrastructure not listed here
PostgreSQL and Redis run on the same DigitalOcean VPS that hosts the application — they are not separate third-party services. We do not use managed database services (RDS, ElastiCache, Upstash) or third-party CDN proxies on the apex domain.
Related documents
- Privacy Policy — what data we collect and how we use it.
- Terms of Service — the agreement that governs your use of Brevlex.
- Brevlex for Districts — compliance posture and how to request a DPA.