Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
#3,139 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 5 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
领域
cloud, frontend

调研方向

首先跟踪现有的区域选择器、创建/引导流程、项目卡片,以及 issue 中引用的 getApiEndpoint/getProjectEndpoint 辅助函数。在选择方案之前,检查提议的运行时区域目录 /console/regions 以及 issue #12964 中的后端依赖。完成的标准是:自托管多区域运营者可以加载不断变化的区域数据、选择区域、在项目列表中看到该区域,并使用已配置的区域端点。

由索引模型根据 Issue 内容生成。

描述

🔖 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?
主要语言
Svelte
星标
393
派生
261
平均合并
26 分钟
30 天内合并 PR
4

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

相似的 Issue

更多 Cloud Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。