Skip to main content
The rules come from 0353. Your deployment chooses its regions; Stackra keeps each tenant inside the one it picked.

​
Regions

  • A deployment declares its regions as short keys in its runway configuration, each with its cloud (AWS or GCP) and cloud region (0354). Each region of a product gets its own cloud account.
  • A tenant picks its region at sign-up, and it never changes. Moving region is an export and an import into a new tenant.
  • Each region runs its own stack with its own database, storage and identity provider instance. Regions are never active-active.

​
What never crosses a region

  • Tenant data. No tenant row or file is replicated or copied to another region. The single exception is an item a user explicitly shares with another tenant, which is audited and checked against the sending entity’s transfer rules.
  • Backups. Point-in-time recovery, snapshots and object replication stay in the tenant’s jurisdiction: a second account, zone or region of the same jurisdiction, never another (0186, as amended). @stackra/infra-aws refuses an environment whose backups or replicated files would leave the foundation’s region (0402 decision 1).
  • Sign-in. Authentication always runs in the tenant’s region.
  • Misrouted calls. RegionGuardDriver (@stackra/tenancy) is the first step of every request and job: a call for a tenant placed in another region than the deployment’s fails loudly instead of reading or writing out of region. It fails closed when a tenant has no placement.
Cross-region operator views, such as audit, query each region and copy nothing centrally.

​
Backups and recovery

These are design targets your deployment configures and drills; they are not a service level. Whole-region loss is the deployment’s choice, stated in its SLA.

​
Logs and telemetry

Logs, traces and metrics leave every service as OpenTelemetry (OTLP) to the destination your deployment configures. They carry no personal data; the designed retention is 30 days hot and 13 months in object storage (0184). Put the destination and its storage in the same jurisdiction as the region if your contracts require it; Stackra does not pin it.

​
Vendors without a region

A vendor that carries no tenant records of substance (email delivery, crash reports, product analytics without personal data) may serve every region from one jurisdiction and must appear on the sub-processor list. AI processing is routed per tenant region under the rule the product sets. Every new vendor is checked against these rules.

​
The login directory

Before sign-in, one directory routes a person to their region. It holds only keyed hashes (HMAC-SHA-256 of the normalised email or phone) mapped to region keys, never a readable identifier, so it is replicated everywhere and survives the loss of any region (0451).

​
The package registry

The Stackra registry holds no tenant data. For a Pro licence it keeps an opaque reference to the customer account, token hashes and daily download counts per licence; it stores no IP address. It runs on Cloudflare and is not tied to any of your regions.

​
Not finished

TenantPlacement (where each tenant lives) and LoginDirectoryStore (the directory writer’s store) ship with in-memory drivers only. They are fine for tests and a single process; a production deployment with more than one instance needs persistent drivers, which are tracked in STA-1473. Until they ship, the region guard is only as reliable as the placement driver your host binds.
  • Where the region keys are declared (runway or tenancy configuration) and the lint that checks a region value against them are open (0353 open question 1).
  • Figentra’s own regions and per-plan choices are Figentra OS decisions, not Stackra’s.