Loading secure project, delivery, and launch evidence surfaces.
Loading secure project, delivery, and launch evidence surfaces.
Monthly notes on nearshore engineering teams, CAD and documentation quality, delivery controls, and QENVEX launch updates.
Operational Subprocessors
QENVEX uses hosted providers for application delivery, authentication, data storage, transactional email, CRM handoff, and scheduling.
| Provider | Role | Data Context |
|---|---|---|
| Supabase | Hosted database, authentication, row-level security, and server-side data access. | Workspace profiles, leads, projects, tasks, files metadata, invoices, support, notifications, activity logs, and auth records. |
| Cloudflare | Application delivery, CDN, WAF, Turnstile, Worker deployment, and R2 object storage. | Request metadata, security signals, cached assets, and uploaded files when R2 buckets are configured. |
| Resend | Transactional email delivery for contact confirmations, internal alerts, quote requests, newsletter confirmations, and workspace notification emails. | Email addresses, names, workspace notification context, message context, and transactional email content needed for delivery. |
| HubSpot | CRM handoff for leads and future commercial follow-up workflows. | Lead contact details, company context, service interest, market, and form metadata when CRM sync is configured. |
| Cal.com | Scheduling entry point for sales or discovery calls when a booking username is configured. | Meeting booking details supplied by the prospect through the scheduling workflow. |
This page is an operational transparency baseline for provider usage, data context, and review scope during client onboarding.
Provider usage should remain visible, scoped, and reviewable as the platform moves from launch setup into production operation.
Provider usage is scoped to the data needed for authentication, workspace delivery, storage, email, CRM handoff, scheduling, and abuse prevention.
Service-role keys, provider tokens, Cloudflare tokens, and email/CRM credentials stay in server runtime or deployment secrets and are never exposed to browser clients.
Provider settings, Auth callbacks, R2 buckets, Worker bindings, WAF rules, email delivery, CRM handoff, and live smoke evidence must be captured in the launch evidence package.
Material provider or data-flow changes should be reviewed in the Trust Center, legal pages, subprocessor list, and launch evidence package before being treated as production-ready.
Contact QENVEX for the provider context relevant to your engagement.
Contact us