🚀 Feature: Self-hosted multi-region console (region picker + runtime regions catalog)

Start by tracing the existing region picker, create/onboarding flows, project cards, and the getApiEndpoint/getProjectEndpoint helpers referenced in the issue. Review the proposed /console/regions runtime catalog and the backend dependency in issue #12964 before choosing an approach. Done means self-hosted multi-region operators can load changing region data, choose a region, see it in project lists, and use the configured regional endpoints.

🔖 Feature description

Console already has Cloud multi-region UX (region catalog, create/onboarding region, regional API endpoint helpers, org project region badges). Almost all of that is gated on Cloud (isCloud / PUBLIC_CONSOLE_MODE=cloud).

Self-hosted operators running a meta API plus regional APIs cannot use that UI today: no region picker, create/onboarding omits region, and there is no supported way to load a region catalog or map a project’s region to an API host without Cloud’s organizations.listRegions / Cloud subdomain conventions.

🎤 Pitch

Once the backend can run meta + regional stacks (https://github.com/appwrite/appwrite/issues/12964), the console must:

• Load a self-hosted region catalog at runtime (no rebuild when regions change)
• Let operators pick a region when creating projects (create modal + onboarding)
• Route SDK/API calls using an explicit optional hostname/endpoint per region
• Show region on org project lists

Without this, self-hosted multi-region only works via raw API and is unusable for normal console workflows.

👍 Solution / proposed scope

Discuss and (if accepted) implement:

1. isMultiRegion (or equivalent) — e.g. PUBLIC_APPWRITE_MULTI_REGION=true and/or a console variable from the API (_APP_SUPPORTS_MULTI_REGION), not Cloud-only.

2. Runtime region catalog — serve a static JSON file from the console nginx image, e.g. GET /console/regions, so Helm/compose can mount a ConfigMap/volume without rebuilding the SPA. Shape should mirror the API catalog idea ($id, name, availability flags) plus optional routing fields:

   • hostname → {page-protocol}//{hostname}/v1
   • endpoint → full API base (with or without /v1)
   • Example: { "$id": "fra", "name": "Frankfurt", "disabled": false, "available": true, "hostname": "fra.example.com" }
   • If neither hostname nor endpoint is set, keep existing Cloud subdomain behavior as fallback (or same-origin).

3. Create + onboarding — when multi-region is on, show the region picker and send region on project create. Prefer the self-hosted create modal, not the Cloud wizard (Cloud path can coalesce region to default).

4. Org UI — show region name on project cards when multi-region is enabled (same presentation as Cloud).

5. Align getApiEndpoint / getProjectEndpoint / copy-display URLs with the catalog overrides.

We prototyped this in a Helm/nginx setup (ConfigMap-mounted /console/regions). Happy to adjust to whatever maintainers prefer (API-served catalog vs static file) as long as it stays runtime-configurable and host-explicit.

Depends on / coordinated with backend multi-region: https://github.com/appwrite/appwrite/issues/12964

👀 Have you spent some time to check if this issue has been raised before?

• I checked; existing console region work targets Cloud subdomain routing / Cloud APIs, not self-hosted multi-region UX with a runtime catalog.

🏢 Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines (https://github.com/appwrite/console/blob/main/CONTRIBUTING.md) (open an issue explaining the idea before a PR; discuss fit with roadmap).