Skip to main content

Network & Infrastructure

This page describes where Breeze runs, how its components connect, and how network access is restricted.

Hosting topology​

The browser talks to two independent hosts: Vercel for static assets and the Azure backend for all data API traffic. Vercel never sees customer data; all reads and writes go directly from the user's browser to the Azure-hosted API in Norway East.

Backend (Azure App Service)​

The Breeze API runs on Microsoft Azure App Service in the Norway East region. The application runs in a containerized environment and is deployed through an automated CI/CD pipeline. The platform scales automatically based on load.

The App Service is the only network entry point to customer data. It is not directly accessible at the operating-system level; access for operations and incident response is mediated through Azure's authenticated administrative tooling.

Database (MongoDB Atlas)​

The primary database is a MongoDB Atlas cluster running on Microsoft Azure in the Norway East region. Key controls:

  • Replication — 3-node replica set with automatic failover. A node failure does not interrupt service.
  • Encryption at rest — AES-256, integrated with the cloud provider's KMS.
  • Encryption in transit — TLS enforced for all client connections; the application driver does not permit plaintext connections.
  • Private network connectivity — the Azure App Service connects to the Atlas cluster over an Azure VNet peering link. Database traffic stays on a private virtual network and the cluster is not reachable from the public internet.
  • Authentication — SCRAM with strong, rotated credentials stored as backend secrets.
  • Atlas audit logging — enabled at the cluster layer.

Frontend (Vercel)​

The Breeze customer-facing UI is a Next.js application hosted on Vercel. Important security characteristics:

  • No customer data is processed or stored on Vercel. The frontend is a client-side rendering layer. After the static assets and JavaScript bundle are delivered to the user's browser, all subsequent data requests go directly from the user's browser to the Azure-hosted backend API — Vercel does not see, proxy, or cache that traffic.
  • HTTPS only — Vercel-managed TLS certificates with automatic renewal.
  • CDN edge — static assets are served from Vercel's CDN; no customer data passes through this layer.

Object storage (Azure Blob Storage)​

Generated artifacts such as credential images, mobile-credential payloads, and PDF exports are stored in Azure Blob Storage in Norway East. Storage accounts are configured with:

  • AES-256 encryption at rest (default).
  • TLS-only access.
  • Access mediated by the backend; the frontend does not hold storage credentials.

Cache​

Redis (Azure Cache for Redis, Norway East) is used for the token cache, rate-limit counters, and short-lived session metadata. Connection enforced over TLS.

Network controls​

  • TLS 1.2+ is required on every external endpoint.
  • HTTPS redirection is enforced for all backend traffic.
  • CORS is configured with an explicit allowlist of permitted origins in production.
  • VNet peering between the App Service and the Atlas cluster keeps database traffic on a private virtual network with no public ingress.
  • Outbound traffic from the backend is restricted to the operational sub-processors documented in Sub-processors.

For details on customer-managed connectivity to on-premise SQL data sources via the Breeze Access Management Router, see Integrations › AMR › Connectivity › SQL Security & Networking.