TABLE OF CONTENTS
Regional hosting at a glance
Stack Internal uses independent regional sites. The United States is the default starting site. Additional geographic sites are introduced when customer provisioning, privacy, or data-sovereignty requirements justify them. A customer uses the regional site assigned during provisioning and receives the corresponding web, API, and MCP endpoints.
Customers choose a supported geography, not a specific Azure region. Stack Overflow manages the mapping from the customer-facing geography to the underlying cloud regions and deployment pair. Each site can authenticate and serve its customers without depending on a global tenant catalog, login page, or cross-region router for basic access.
Regional UI API and MCP URLs
The site model uses separate host names. The UI adds the provisioned workspace path; public APIs use versioned, customer-facing namespaces; and MCP clients connect to the MCP host for the same geography.
| Surface | US site | Regional pattern | EU example |
|---|---|---|---|
| UI | https://stackinternal.com/workspaces/{workspace-slug}/ | https://{region}.stackinternal.com/workspaces/{workspace-slug}/ | https://eu.stackinternal.com/workspaces/{workspace-slug}/ |
| API | https://api.stackinternal.com/ | https://api.{region}.stackinternal.com/ | https://api.eu.stackinternal.com/ |
| MCP | https://mcp.stackinternal.com/ | https://mcp.{region}.stackinternal.com/ | https://mcp.eu.stackinternal.com/ |
Data isolation and residency
Regional isolation
Each supported geography is a separate application supporting data-plane deployment. Regional sites do not rely on another region for basic login or tenant discovery. Service-to-service endpoints, identity issuers and audiences, event transport, capture storage, and operational workflows are configured from regional deployment metadata so requests and records stay in the intended cell.
Domain and product events use separate Event Hubs namespaces for each environment and region. The accepted architecture states that an event emitted in one region remains in that region. Current audit-export guidance also fails when a tenant is not found in the selected regional Tenant Management instance rather than searching another region.
Tenant isolation within a region
Stack Internal is multi-tenant by default. Within a regional site, services may share infrastructure and service databases. Tenant-owned PostgreSQL data is separated with row-level security or an equivalent database-enforced mechanism, and applications set tenant context from validated identity claims. This is designed to fail closed when tenant context is missing and to prevent an omitted application filter from returning another tenant's rows.
The repository evidence shows row-level security in Identity, Control Center, Content Ingestion, Chat, MCP settings, Node Extractor, Persona Resolution, Reporting, Scopes, and ChatOps persistence. This is tenant isolation within a regional cell; it is distinct from the physical isolation between regional sites.
What residency covers
The regional commitment described here applies to the Stack Internal regional application and supporting data plane provisioned for the tenant. Production LLM access is routed through platform-managed Azure Foundry deployments with separate United States and Canada and European Union and United Kingdom data-zone deployments.
Important qualification. External systems and integrations can have their own processing locations and subprocessor terms. For example, Slack originates callback traffic from its infrastructure even when the receiving tenant is provisioned in another geography. Contractual documents, the data-processing agreement, and the approved subprocessor list determine the legally binding residency scope for a specific customer.
High availability and disaster recovery posture
High availability and disaster recovery is the default posture for each supported regional site. It is a property of the regional multi-tenant stack, not a per-customer opt-in feature.
| Area | Customer-facing posture |
|---|---|
| Deployment | A regional deployment group has a companion deployment target, and services are designed to deploy to both halves of the HADR pair. |
| Failure domains | Independent regional sites avoid a global login or tenant-routing dependency that could block otherwise healthy regions. |
| Database access | Applications use the PostgreSQL primary virtual endpoint so the current primary is reached without embedding failover topology in application code. |
| Background work | Services running in both halves must prevent jobs that should run once from executing twice; the architecture leaves framework-specific implementation to each service. |
| Commitment | This guide does not define an SLA, recovery-time objective, recovery-point objective, backup retention period, or customer-initiated failover procedure. |