feat: upgrade to PostgreSQL mode (Neon) + serve static landing page

- Serve static/index.html at root instead of 302 redirect
- Update README for PostgreSQL mode with Neon DATABASE_URL
- Secrets configured: DATABASE_URL, CLAUDE_SESSION_KEYS

Dockerfile

@@ -4,6 +4,7 @@ FROM nginx:1.27-alpine
 
 COPY --from=upstream /claude2api /usr/local/bin/claude2api
 COPY nginx.conf /etc/nginx/conf.d/default.conf
+COPY static/index.html /usr/share/nginx/html/index.html
 COPY entrypoint.sh /entrypoint.sh
 
 EXPOSE 7860

README.md

@@ -8,235 +8,47 @@ app_port: 7860
 pinned: false
 ---
 
-# Claude2API — Hugging Face Space 说明
+# Claude2API — Hugging Face Space
 
 当前 Space：<https://ohmyapi-c2api.hf.space>
 
-这是一个围绕 `pushzx/claude2api:latest` 的 Hugging Face Docker Space 包装层。目标很克制：
-
-- 让根路径 `/` 直接进入真实可用的管理登录页 `/admin/login`
-- 保持 `/admin`、`/health`、`/v1/*` 等能力继续由上游 `claude2api` 提供
-- wrapper 只处理入口体验与反代，不在外层伪造持久化配置语义
+围绕 `pushzx/claude2api:latest` 的 Hugging Face Docker Space 包装层。
 
 ## 当前部署状态
 
-当前线上状态已经收敛为 **public Space + simple mode**。
-
-- Space 类型：**public Space**
-- 运行模式：**simple mode**
-- 当前不启用 DB-backed 持久化
-- 当前已从 Space Secrets 中移除：`DB_HOST`、`DB_PORT`、`DB_USER`、`DB_PASS`、`DB_NAME`、`PGSSLMODE`
-- 当前根路径 `/` 会直接 `302` 到 `/admin/login`
-
-这样收敛的原因很明确：simple mode 已经稳定可用，而当前上游镜像的 DB-only 路径对 Neon / Supabase 这类强制 TLS 的托管 PostgreSQL 仍未验证通过，不能在这里把它写成现成功能。
-
-## 当前访问行为
-
-public Space 的含义是：**入口默认公开**，不是 **Secrets 自动公开**。
-
-当前线上已验证：
-
-- `/` → `302 /admin/login`
-- `/admin/login` 可正常打开
-- `/health` 返回 `200`
-- `/v1/messages` 未带正确 token 时返回 `401 Invalid API key`
-- 带正确 app token 时，`claude-sonnet-4-6` 已成功完成实际调用
-- `/v1/models` 可在带 token 的情况下返回模型列表
-
-## public Space 的风险边界
-
-public Space 不会因为是 public 就把 Hugging Face Secrets 直接暴露出来，但它会让你的入口地址处于公网可探测状态。
-
-这意味着：
-
-- `https://ohmyapi-c2api.hf.space/` 这类地址任何人都能访问与探测
-- Hugging Face Space Secrets **不会**被页面或公开 API 直接回显
-- 真正更常见的泄露面是：把 token / session 写进仓库文件、前端页面、日志、导出的配置或本机历史文件
-- public Space 是否安全，关键不在于“是否 public”，而在于：
-  - app 自身接口是否强制鉴权
-  - `CLAUDE_API_KEY` / `CLAUDE_SESSION_KEYS` 是否只保留在服务端运行时环境
-  - 仓库与页面输出里是否完全不出现真实 secret
-
-换句话说，public Space **不会自动泄露 session**，但如果 app token 泄露、接口未加保护，别人就能直接消费你的服务。
-
-## 为什么 Hugging Face 环境变量能直接生效
-
-因为当前 Space 使用的是 **Docker SDK**。
-
-Hugging Face 对 Docker Space 的处理方式不是“把变量写进仓库文件”，而是在容器启动时把 Space Settings 里的：
-
-- **Variables**
-- **Secrets**
-
-直接注入成容器进程的真实运行时环境变量。
-
-对这个仓库来说，等价于容器启动时直接拿到了例如：
-
-```env
-ADMIN_USER=admin
-LISTEN_ADDR=:7860
-CLAUDE_API_KEY=...
-ADMIN_PASS=...
-CLAUDE_SESSION_KEYS=...
-```
-
-因此，只要上游 `claude2api` 在启动时通过 `os.Getenv(...)` 或等价方式读取配置，它就会直接生效，不需要额外写入 `.env`、`config.yaml` 或其它文件。
-
-### 当前已确认的 Space Variables
-
-当前公开可读到的 Variables 是：
-
-```env
-LISTEN_ADDR=:7860
-ADMIN_USER=admin
-```
-
-Secrets 不会被 Hugging Face API 直接回显，但从线上行为可以确认至少存在并已生效：
-
-- `CLAUDE_API_KEY`
-- `CLAUDE_SESSION_KEYS`
-- `ADMIN_PASS`
-
-## 当前 wrapper 做了什么
-
-当前 `Dockerfile` 不是直接把上游镜像原样暴露到 `:7860`，而是：
-
-- 前置一个很薄的 nginx
-- nginx 监听 `:7860`
-- 上游 `claude2api` 在容器内监听 `127.0.0.1:8080`
-- `/` 与 `/index.html` 直接跳转到 `/admin/login`
-- 其余路径继续透传到上游
-
-这样做的原因很简单：
-
-- 旧版 root path 会显示 `404 page not found`
-- 现在用户访问根路径时，会直接进入真实可用的登录入口
-- 同时不需要去改上游镜像源码
-
-## 当前为什么不启用 PostgreSQL 持久化
-
-### 结论
-
-**按当前已验证状态，不能认为这个 Space 已经配置并启用了 PostgreSQL 持久化存储。**
-
-更准确地说：当前线上已经明确收敛为 **simple mode only**，不是“正在尝试 DB-only 但尚未成功”。
-
-### 原因
-
-1. 只要存在 `CLAUDE_SESSION_KEYS`，上游就可以走 simple mode，并且当前已验证可稳定提供 API 能力。
-2. 当前 Hugging Face Space runtime 已确认 `storage.current = None` 且 `storage.requested = None`，因此容器内本地 PostgreSQL 不能视为正式持久化层。
-3. 对当前上游镜像的排查显示，DB-only 路径很可能会把 PostgreSQL DSN 拼成：
-
-   ```text
-   host=%s port=%s user=%s password=%s dbname=%s sslmode=disable
-   ```
-
-   这会与 Neon / Supabase 这类强制 TLS 的托管 PostgreSQL 冲突。
-4. 因此，即使文档里存在“可���接外部数据库”的描述，也不能把它等同于“当前镜像已支持外部托管 PG 持久化”。
-
-### 为什么 local PostgreSQL 不能当成 HF 持久化
-
-如果你打算在 Hugging Face Space 容器里直接放一个“本地 PostgreSQL”，要先明确一件事：**默认情况下，这不等于可靠持久化。**
-
-原因是：
-
-1. Docker Space 默认使用的是容器自身的可写层，而不是天然持久卷。
-2. 如果没有单独申请 Hugging Face persistent storage，并把数据库目录明确挂到持久路径，本地 PG 数据在 restart / rebuild / redeploy 后都可能丢失。
-3. 当前这个 Space 没有启用 persistent storage，因此“容器内本地 PG”不能当成正式配置持久化方案。
-
-因此：
-
-- 本地 PG 更适合临时调试，不适合承担当前 Space 的正式配置持久化
-- 真正需要稳定持久化时，应优先使用外部 PostgreSQL，或者先补齐 HF persistent storage，再验证上游是否支持对应的数据目录语义
-
-## 当前推荐的线上配置思路
-
-如果你只是想把 Space 稳定跑起来，当前推荐就是保持 simple mode：
-
-### 必要 Secrets
-
-- `CLAUDE_SESSION_KEYS`
-- `CLAUDE_API_KEY`
-- `ADMIN_PASS`
-
-### 当前 Variables
-
-```env
-LISTEN_ADDR=:7860
-ADMIN_USER=admin
-```
-
-### 当前不启用的配置
-
-以下 DB 相关项当前视为**暂不启用**，不要再把它们当成线上必需配置：
-
-- `DB_HOST`
-- `DB_PORT`
-- `DB_USER`
-- `DB_PASS`
-- `DB_NAME`
-- `PGSSLMODE`
-
-## 当前已验证可调用的模型
-
-带正确 app token 时，以下模型已通过真实 `/v1/messages` 请求验证，可以正常返回结果：
-
-- `claude-sonnet-4-5`
-- `claude-haiku-4-5`
-- `claude-sonnet-4-6`
-- `claude-haiku-4-6`
-- `claude-3-5-sonnet-20241022`
-- `claude-3-5-haiku-20241022`
-- `claude-3-sonnet-20240229`
-- `claude-3-haiku-20240307`
-
-以下模型虽然会出现在 `/v1/models` 列表里，但当前实测返回的是 `403 model_not_available`：
-
-- `claude-opus-4-5`
-- `claude-opus-4-6`
-- `claude-3-opus-20240229`
-
-这也说明一件事：**`/v1/models` 返回的是“当前镜像声明支持的模型列表”，真正能否调用仍然取决于当前 session / account 的实际可用性。**
-
-## 关于 admin password / auth token 持久化的当前结论
-
-目前已做过的验证结论是：
-
-- `api_key` 可以在当前运行期通过管理接口更新，并立即影响鉴权结果
-- 但容器重启后，会回退到启动时环境变量 / HF Secrets 的值
-- `admin_pass` 目前看**不能**通过现有 settings 路径真正更新并持久生效
-
-所以当前更准确的理解是：
+- **运行模式**：PostgreSQL 模式（Neon 托管数据库）
+- **数据库**：通过 `DATABASE_URL` 连接 Neon PostgreSQL（强制 TLS）
+- **功能**：完整账号管理、健康检测、模型映射、限速、API Key 管理
 
-- Hugging Face Secrets / Variables = **启动配置源**
-- 上游 admin UI 的部分设置 = **运行期状态修改**
-- 两者目前**不是**一个可自动回写、可稳定持久继承的统一配置层
+## 访问入口
 
-## 当前仓库文件职责
+| 路径 | 说明 |
+|---|---|
+| `/` | 静态落地页，引导进入管理面板 |
+| `/admin` | 上游管理面板（账号/代理/模型映射/metrics） |
+| `/health` | 健康检查 |
+| `/v1/messages` | Anthropic 兼容 API |
+| `/v1/models` | 模型列表 |
 
-- `Dockerfile`：构建 HF Space 容器
-- `nginx.conf`：把根路径重定向到 `/admin/login`，并透传其他请求
-- `entrypoint.sh`：同时启动前置 nginx 和上游 `claude2api`
-- `.env.example`：本地 / VPS 运行示例，不代表 HF Secrets 会被运行时回写
-- `docker-compose.yml`：本地 / VPS 参考，不会直接在 HF Space 中运行
+## HF Space Secrets
 
-## 最小验收命令
+| 变量 | 用途 |
+|---|---|
+| `DATABASE_URL` | Neon PostgreSQL 完整 DSN |
+| `CLAUDE_SESSION_KEYS` | 逗号分隔的 Session Keys（启动时导入） |
+| `CLAUDE_API_KEY` | API 访问密钥 |
+| `ADMIN_PASS` | 管理面板密码 |
 
-```bash
-curl -I https://ohmyapi-c2api.hf.space/
-curl https://ohmyapi-c2api.hf.space/health
+## HF Space Variables
 
-curl https://ohmyapi-c2api.hf.space/v1/models \
-  -H "Authorization: Bearer $CLAUDE_API_KEY"
+| 变量 | 值 |
+|---|---|
+| `LISTEN_ADDR` | `:7860` |
+| `ADMIN_USER` | `admin` |
 
-curl https://ohmyapi-c2api.hf.space/v1/messages \
-  -H "Content-Type: application/json" \
-  -H "Authorization: Bearer $CLAUDE_API_KEY" \
-  -d '{
-    "model": "claude-sonnet-4-6",
-    "max_tokens": 32,
-    "messages": [{"role": "user", "content": "Reply with exactly: ok"}]
-  }'
-```
+## wrapper 职责
 
-如果最后一条返回正常消息体，就说明当前公开 Space、app token、以及 Claude session 这三层链路都已经打通。
+- `Dockerfile`：构建容器（nginx + claude2api 二进制）
+- `nginx.conf`：根路径 serve 静态落地页，其余透传上游
+- `entrypoint.sh`：同时启动 nginx 和 claude2api
+- `static/index.html`：落地页

nginx.conf

@@ -12,11 +12,13 @@ server {
     client_max_body_size 50m;
 
     location = / {
-        return 302 https://$host/admin/login;
+        root /usr/share/nginx/html;
+        try_files /index.html =404;
     }
 
     location = /index.html {
-        return 302 https://$host/admin/login;
+        root /usr/share/nginx/html;
+        try_files /index.html =404;
     }
 
     location = /favicon.ico {