← Back to Brewyard

Data flow

Last updated: 2026-06-01. Owner: Cagdas Arda.

This page is the canonical reference for what data moves where inside Brewyard. It is intended for two audiences: customers (and counsel) doing a sub-processor / DPIA review before signing up, and reviewers from the Anthropic Partner Network assessing whether Brewyard's BYO-key architecture matches Anthropic's expectations for a non-reseller technology partner.

The load-bearing fact

The Anthropic API call leaves Brewyard infrastructure with the user's own key in the header, and is governed by the user's direct relationship with Anthropic. Brewyard is the operator-agent of the user, not a reseller. The thick edge in the diagram below (Runtime → Anthropic) is the one to verify.

1. Architectural diagram (Mermaid source)

The diagram below shows how your data moves through Brewyard, and where it does not go.

User browser

Brewyard edge

WAF · TLS termination

Brewyard application — Azure UK South

Web app

Next.js

API

FastAPI

Postgres

Users, workspaces, audit trail · UK South

Azure Key Vault

RBAC-scoped, audited · holds your Anthropic key

Per-user TeamForge runtime

Isolated container per workspace · scale to zero · private file mount

Anthropic API — api.anthropic.com

Called directly with the user's own key. Brewyard is the operator-agent of the user, not a reseller.

Supporting services — out of the prompt path

PostHog Cloud EU

Opt-in product analytics · no PII

Resend

Transactional email

Stripe

Payments · card data never touches Brewyard

2. Narration of each edge

  1. 2.1User browser → Edge (HTTPS)

    • Data: Session cookie (HttpOnly, Secure, SameSite=Lax), form bodies (signup, key paste, setup wizard inputs), navigation requests.
    • No card data, ever. Card data only goes to Stripe via the redirect flow.

  2. 2.2Edge → Next.js BFF

    • TLS termination at Azure Front Door / Cloudflare; mTLS inside the Container Apps environment.
    • Cloudflare and Front Door act as WAF / DDoS / rate-limit front-line.

  3. 2.3Next.js BFF → FastAPI (server actions only)

    • The BFF holds the access token and the refresh token in HttpOnly cookies. The browser never sees an API token directly.
    • Each call to FastAPI carries a short-lived Bearer JWT, scoped to a single user/org.

  4. 2.4FastAPI → Postgres

    • Data: account fields (email, hashed password, locale, region, 18+ confirmation), workspace metadata (name, language, monthly budget, team config), subscription state, usage events, vault_refs rows (pointers, not secret values), audit_logs.
    • Tenant isolation enforced at row level via org_id filters on every query.

  5. 2.5FastAPI → Azure Key Vault

    • Data going in: the user's pasted Anthropic API key, only on submit/rotate.
    • Data coming out: the secret itself is not read into the API process during normal request handling. The GET status endpoint serves from the masked_suffix column on vault_refs and does not round-trip Key Vault.
    • The only paths that read the full secret are: (a) the per-user runtime via its own managed identity, scoped to its own org's secret name; (b) one-off ops procedures, which are logged.
    • Every write/delete records an audit_logs row (anthropic_key.connect, .rotate, .delete).

  6. 2.6FastAPI → Per-user runtime spinup

    • POST /api/runtime/start invokes the Container Apps revision template for that user.
    • Scale-to-zero default; on inactivity > 15 minutes the revision spins down.
    • One revision per active user session. Per-runtime managed identity has read access to only the anthropic-key-<org_uuid> secret for that user's org. No runtime can read another user's secret.

  7. 2.7Per-user runtime → Key Vault

    • Runtime starts, resolves its managed identity, then reads the single Anthropic key secret it is permitted to read.
    • The secret value lives in container memory for the lifetime of the runtime. It is not persisted to the Azure Files mount, not written to logs, and not transmitted anywhere except the Anthropic API.

  8. 2.8Per-user runtime → Azure Files mount

    • Data: the user's TeamForge prompts/, config/, state/ directory.
    • Path-scoped to /data/<user_id>/. Mount is per-revision, per-user.

  9. 2.9Per-user runtime → Anthropic API (the load-bearing edge)

    • HTTP request to api.anthropic.com.
    • Header: Authorization: Bearer <user's own sk-ant-...>
    • Body: the user's prompts, agent role definitions, prior turn history.
    • Response: model output, returned directly to the user's runtime, which renders into the dashboard the user is viewing.
    • Important: this call is made on behalf of the user, with the user's own credentials, against the user's own Anthropic account. The user is Anthropic's direct customer for this call. Brewyard's role is operator-agent of the user — analogous to how a hosted CI runner makes API calls using customer-supplied secrets.

  10. 2.10Browser → PostHog Cloud EU

    • Only after explicit opt-in via cookie banner.
    • Event payloads: signup, plan_selected, prompt_sent (with hashed workspace id and bucketed prompt length, never the prompt body), churn. K-anonymity threshold 5 enforced server-side before any aggregation appears in the admin panel.

  11. 2.11API → Resend

    • Data: recipient email address, template id, template variables (e.g. user's first name, a one-time verification link).
    • No marketing-style emails — Resend handles transactional only.

  12. 2.12Web → Stripe (post-MVP)

    • Customer is redirected to Stripe Checkout; card data never touches Brewyard infrastructure (PCI-DSS SAQ A scope).

3. Data residency summary

See also