使用 GitHub Actions 部署
先确定访问域名，再选一种登录方式，填对应变量并运行一次 Deploy。 应用始终部署到 Cloudflare Workers；AUTH_PROVIDER 只决定管理员怎样登录，不是选择云服务商。
1. Fork、确定域名并准备 Token
Fork EdgeSSH，启用 Actions。在仓库 设置（Settings）→ 机密和变量（Secrets and variables）→ Actions 中保存 CLOUDFLARE_API_TOKEN Secret。
多数用户建议准备一个由同一 Cloudflare 账户管理的自定义域名，例如 ssh.example.com，并将主机名保存为 CUSTOM_DOMAIN Variable。只填主机名，不带 https://、路径或通配符。Action 会自动绑定 Worker，Cloudflare 负责 DNS 与证书。
不打算使用自定义域名时，可将 CUSTOM_DOMAIN 留空，Action 会使用 workers.dev 地址；不要把 *.workers.dev 填进该变量。Token 权限见创建 API Token。账户 ID、D1 ID 和加密密钥通常不需要填写。
2. 二选一填写配置
方案 A：Cloudflare Access
适合已经启用 Zero Trust 的用户。先完成 Cloudflare Zero Trust 的组织开通与团队域设置，再填写：
| 名称 | 保存位置 | 值 |
|---|---|---|
AUTH_PROVIDER | Variable | cloudflare（不填也默认此模式） |
CLOUDFLARE_API_TOKEN | Secret | 含 Access/IdP 管理权限的 Cloudflare Token |
CUSTOM_DOMAIN | Variable | 推荐填写实际主机名，如 ssh.example.com；使用 workers.dev 时留空 |
ADMIN_EMAIL | Variable | 你的管理员邮箱；也可在 Run workflow 输入 |
Action 自动创建/复用 Access 应用、明确邮箱 Allow 策略与 OTP，获取 Team Domain 和 AUD，并写入 Worker Secrets。不需要手工复制这些参数。
方案 B：原生 GitHub OAuth
不需要开通 Cloudflare Zero Trust，也不需要 Access/IdP 权限。 这不是在 Access 中添加 GitHub 身份提供程序，而是直接由 EdgeSSH 验证 GitHub 登录。
| 名称 | 保存位置 | 值 |
|---|---|---|
AUTH_PROVIDER | Variable | github |
CLOUDFLARE_API_TOKEN | Secret | Workers/D1 部署 Token |
CUSTOM_DOMAIN | Variable | 推荐填写实际主机名，如 ssh.example.com；使用 workers.dev 时留空 |
GH_CLIENT_ID | Variable | GitHub OAuth App 的 Client ID |
GH_CLIENT_SECRET | Secret | 同一 OAuth App 的 Client Secret |
GH_ADMIN | Variable | 唯一允许登录的个人 GitHub 用户名 |
GH_ADMIN_ID | Variable | 通常不填；仅显式更换管理员时填写数字用户 ID |
第一次使用建议直接按 GitHub OAuth 五步教程操作，其中逐项说明了个人 OAuth App 页面、Fork 的 Variables/Secrets 页签、预期结果与出错阶段。回调地址为 https://你的入口/auth/callback。GitHub 模式不填管理员邮箱，也不填任何 Access 参数。
不要混淆 Variable 与 Secret
API Token、Client Secret 和加密密钥不能放普通 Variable。其他模式遗留的变量不参与认证；工作流只验证当前模式必需的值。
旧版的 GITHUB_CLIENT_ID、GITHUB_CLIENT_SECRET、GITHUB_ADMIN、GITHUB_ADMIN_ID 必须迁移到对应的 GH_* 名称；GITHUB_ 是 GitHub 保留前缀，不能用于 Actions 配置。
3. 运行 Deploy
进入 Actions → Deploy → 运行工作流（Run workflow），选择 main。Cloudflare 模式可在邮箱框输入管理员邮箱；GitHub 模式留空。
工作流依次执行：
- 配置格式校验、类型检查、测试、构建和 dry-run。
- 发现账户；有
CUSTOM_DOMAIN时绑定自定义域名，否则获取workers.dev子域。多账户 Token 才需额外指定CLOUDFLARE_ACCOUNT_ID。 - 只配置所选认证方式，按名称或显式 ID 复用 D1。
- 沿用旧库唯一资料所有者 ID，新库使用固定管理员 ID。
- 首次生成加密密钥，后续保留原值；执行数据库迁移。
- 通过标准输入同步所需 Secret 并部署，检查当前模式必需的 Secret 是否存在。
- GitHub 模式实际检查
/auth/login能签发 Cookie 并返回正确的 GitHub 302，以及未登录的/api/auth/me返回 401；失败则停止，不把上传成功当作登录可用。 - 在运行摘要给出访问地址；GitHub 模式另给出 OAuth 回调地址，随后必须完成一次真实授权。
填写 CUSTOM_DOMAIN 后，以 https://你的自定义域名 作为唯一正式入口并关闭备用 workers.dev 入口。只有留空时，才默认访问 https://edgessh.<你的 Workers 子域>.workers.dev。
4. 登录与验收
- Cloudflare 模式：入口先跳 Access，只允许指定邮箱登录。
- GitHub 模式：首页点击「登录」前往 GitHub；只有
GH_ADMIN对应账号可以进入。 - 登录后检查主机列表，使用真实已授权目标验收 SSH、SFTP 与进程面板。
详见部署后验收。只看到网页，不代表登录与 SSH 已通过验收。
更新与切换
以后推送 main 或重跑 Deploy 即可，复用原 Worker、D1 和加密密钥。切换 AUTH_PROVIDER 后仍是一位管理员、同一份主机资料，不需要绑定两套账号。
旧版点击 GitHub 登录直接返回“服务暂时不可用”时，先同步含 2026-10-07 Base64 解码修复的最新 main 再运行 Deploy；不要只是重跑旧提交，也不要换密钥或扩大 Access 权限。见已有用户修复。
若旧域名还在 Access 网关后面，切换 GitHub 前先解除该域名的旧保护，避免双重登录；脚本不会擅自删除安全策略。完整步骤见切换登录方式。