Last updated: 26 October 2026
Velstrian Tenderworks operates from the United Kingdom and processes personal data primarily in Europe. This page discloses the specific regions where each class of data is stored and processed, so you can make an informed procurement decision.
1. Primary storage and processing
| Service | Purpose | Region |
|---|---|---|
| Supabase (Postgres + Auth + Storage) | Primary database, authentication, report PDFs | AWS eu-west-1 (Ireland) |
| Railway (FastAPI compute) | Backend API, PDF generation | Google Cloud europe-west4 (Amsterdam, Netherlands). Compute only, no primary data store. |
| Vercel (Next.js) | Frontend hosting, server-side routes | Function region lhr1 (London, UK). Requests from the UK enter and execute in London. No primary data store. Until 19 August 2026 this ran in iad1 (Washington DC, USA); that transfer no longer occurs. |
| Cloudflare (DNS, DDoS, WAF) | Edge security and DNS resolution | Global edge; no persistent storage |
2. Third-party sub-processor regions
| Sub-processor | Purpose | Region | Transfer mechanism |
|---|---|---|---|
| Stripe Payments Europe, Ltd | Billing, VAT handling, card vaulting | EU (Dublin) with limited US fallback | SCCs + EU-US DPF |
| Brevo | Transactional and lifecycle email | Region being confirmed | SCCs + UK IDTA |
| Sentry GmbH | Error telemetry (scrubbed) | EU region | SCCs |
| PostHog | Product analytics (consented) | eu.posthog.com (Frankfurt) | SCCs |
| Google (Gemini API) | AI generation across Velstrian Bid and the assistant surfaces | Not region-pinned by the API used | SCCs + UK IDTA |
| Anthropic | AI generation (tender pre-reads, assistant intent) | United States | SCCs + UK IDTA |
3. International transfers
Where a sub-processor operates outside the UK/EEA, we rely on the UK International Data Transfer Agreement (IDTA) or EU Standard Contractual Clauses (SCCs) plus any additional safeguards required by the relevant supervisory authority. A full list of transfer mechanisms is maintained in our Data Processing Agreement.
The transfer that used to sit on the primary processing path has been removed. Until 19 August 2026 our application front end and its server-side route handlers ran on Vercel in the iad1 (Washington DC, USA) function region, so the code handling form submissions and authenticated session data executed in the United States. That is no longer the case. The function region is now lhr1 (London, UK), verified on 19 August 2026 by reading the second :: segment of X-Vercel-Id on cache-MISS responses across six invocations, and corroborated by Vercel’s own deployment record. Requests from the UK now enter AND execute in London. This paragraph is kept rather than deleted so a reader who relied on the earlier disclosure can see exactly what changed and when. Your primary data at rest is unaffected and remains in AWS eu-west-1 (Ireland), as set out in section 1.
4. Region-pinning for enterprise customers
All customer data today is stored in AWS eu-west-1 (Ireland), as set out in section 1. No customer data is stored in a UK region. We do not currently offer region-pinning, and no UK-resident storage option is available on any plan at present.
Customers with a regulatory requirement to store data exclusively in the UK rather than the EEA should contact [email protected] before contracting. A UK storage region would be a future change requiring engineering work and a separate written agreement; it is not something we can enable on an existing account, and nothing on this page should be read as a commitment that it is available today.
5. Changes to residency
Any change that would move your data into a different region will be disclosed here and emailed to account holders at least 30 days in advance.