ByMorning

ByMorning

项目状态。 ByMorning 按照MIT License以现状提供。开发它的公司已关闭，因此没有供应商、支持、SLA 或维护承诺，也没有人有义务审核问题或发布版本。该项目由社区维护：你可以创建分支、提交拉取请求，并自行构建。报告漏洞前，请阅读 SECURITY.md。

ByMorning 是一个可自托管的 AI 网关。它在你自己的云账户中，根据你的权限、预算和审计要求，将你的人员、编码 Agent 和内部系统连接到你批准使用的模型。文档：https://bymorning.ai/docs。

安装

每个发布镜像均由此代码库的发布工作流以无密钥方式签名，并发布到 ghcr.io/bymorning/bymorning，签名证据（SBOM、扫描结果、来源证明）则发布在 GitHub 发布页面。

适用场景	用途
一台机器上试用	Docker Compose 评估版。不适用于生产环境。
AWS 或 AWS GovCloud (US)	Terraform 模块，也可在 Terraform Registry 上通过 bymorning/bymorning/aws 获取。
Azure (AKS)	Azure 安装程序：Terraform 和 Kubernetes 清单。
任意 Kubernetes 集群	Helm chart，需使用你自己的数据库、对象存储和密钥。

连接编码 Agent

• 模型。 使用服务账户密钥，将 Claude Code、Codex、Cursor、VS Code Copilot、OpenCode 或 Gemini CLI 指向你安装实例的兼容 OpenAI、Anthropic 和 Google 的端点。每次调用均适用支出限额、路由和用量统计。请参阅连接编码 Agent。
• 工具。 将 https://<your host>/mcp 添加到 Agent，作为远程 MCP 服务。Agent 以 OAuth 方式登录，身份为 Workspace 成员，并获得该成员有权使用的工具，且受 Workspace 权限约束。请参阅在 Agent 中使用 ByMorning 的工具。server.json 将其描述为 MCP Registry 中的 io.github.bymorning/bymorning。

开发

要进行开发，请使用 Bun 和 Node 22+，并在代码库根目录运行：

bun install --frozen-lockfile
bun run dev

打开 http://localhost:3000；本地登录会直接进入工作区。开发主机使用 PGlite 将与 Postgres 兼容的数据持久化在 .bymorning/local/pglite 下；数据库无需 Docker。dev 会同时运行监听 API 变化的进程和 Vite；API 会在启动时运行迁移。需要使用 Code Interpreter 时，请使用 bun run --cwd app/host setup 构建执行镜像。本地开发无需 SST 或 AWS 凭据；SST 仍是受支持的 AWS 部署工具，Azure 安装程序则通过 Terraform 部署到 AKS。

要配置应用的两个端口：

PORT=4001 WEB_PORT=4000 bun run dev

PORT 控制 API；WEB_PORT 控制 Vite 和默认登录回调源。bun run local 则是一个打包的一体化开发主机。有关部署约定、开发默认设置、Vite 参数和数据库所有权，请参阅主机指南。

应用包

一个主机程序 app/host 为所有部署提供服务。根目录中的 Dockerfile 发布的就是它的生产构建：

bun run --cwd app/host build
node app/host/dist/bymorning.mjs

它需要部署所选的存储和密钥选择器（STORAGE_PROVIDER、CIPHER_BACKEND）、相应的配套配置，以及 app/host/README.md 中说明的数据库、Cookie 和源站设置。开发构建额外包含 PGlite、文件系统存储、本地加密模块和 Docker Code Interpreter，无需设置任何配置：

bun run --cwd app/host build:dev
node app/host/dist/bymorning.mjs

分发完整的 dist/ 目录，包括安装文档和可加载的插件包。Docker 镜像使用 Node 运行生产包；不会构建已编译的应用程序可执行文件。

数据库

从 packages/core 运行所有数据库操作，以便 Drizzle 使用 Core 配置。sst shell 会提供所选阶段关联的 Database 资源：

cd packages/core

bunx sst shell --stage <stage> -- bun db generate --name <migration_name>
bunx sst shell --stage <stage> -- bun db migrate
bunx sst shell --stage <stage> -- bun db studio
bunx sst shell --stage <stage> -- bun db:check

更改 Core 架构后生成迁移，然后在应用迁移前检查生成的 SQL 和快照。绝不要编辑、替换或删除已应用到任何阶段的迁移。后续更改应通过新的向前迁移完成。

部署依赖迁移的代码前，先应用迁移。SST 部署会在更新 Server 前运行迁移 Lambda；如果迁移失败，部署会停止。

PostgreSQL 迁移仅支持向前执行，位于 packages/core/src/database/migration/。当前开发基线是一次破坏性重置；必须重置基于先前迁移历史创建的数据库。

Terraform（Azure）

Azure 安装通过 Terraform 和 Kubernetes 清单进行部署。请遵循 Azure 安装指南：AKS、Key Vault、Blob 存储、PostgreSQL，以及镜像摘要固定并镜像到你自己的注册表中的镜像。

发布

一个发布版本包含一个 Gateway 镜像，以摘要固定的 linux/amd64 OCI tarball 形式交付，另附签名证据（SBOM、漏洞和许可证报告、扫描结果、SLSA 来源证明、SHA256SUMS）。该发布与安装程序无关：每个安装程序都交付同一个 tarball，并验证同一个摘要。

发布签名采用无密钥方式。 无需存储或轮换签名密钥。full-gate 工作流使用其自身的 GitHub Actions 身份，通过 Sigstore 为证据签名：签名证书会标明工作流运行，签名则记录在公开的透明日志中。只有当该身份是此仓库在 v* 标签上运行的 full-gate.yml 时，签名才是发布签名（script/release/signing.ts）；安装程序导出会拒绝其他签名，并在打包发布版本前使用 cosign 验证每个签名。任何人都可以使用 release/signer.txt 中的身份和颁发者信息检查发布版本，也可以从对应标签重新构建发布版本并比较摘要：构建具有可复现性。

发布步骤：

1. 在根目录的 package.json、app/host/package.json、server.json 和 charts/bymorning/Chart.yaml 中设置版本（version 和 appVersion，以及其 Artifact Hub 注释中的镜像）。运行 sh script/release/versions.sh 和 sh charts/bymorning/test.sh，检查版本是否一致。在 CHANGELOG.md 中为该版本添加日期，然后合并到 dev。

2. 为该提交创建 v<version> 标签并推送。标签必须与 package.json 中的版本一致。

3. 在该标签上触发签名构建，然后下载其 release 工件：

   git tag v<version> && git push origin v<version>
   gh workflow run full-gate.yml --ref v<version> -f sign=true
   gh run download <run id> -n release -D release
   

   该工作流会构建两个镜像，运行镜像安全、镜像启动、kind 和浏览器测试套件，并对证据进行签名。 工件包含 release/bymorning-<commit>.tar（Gateway）和 release/bymorning-code-interpreter-<commit>.tar （代码执行镜像；两者均被 gitignore 忽略）、release/manifest.json、release/signer.txt、 release/trusted_root.json（Sigstore 信任根，用于离线验证），以及位于 release/<version>/gateway/ 和 release/<version>/execution/ 中的证据。清单中每个工件的 signing 字段都记录了 签名者：keyless（身份和签发者）、ephemeral（临时密钥，每次运行都会更换）或 unsigned。

   对于 v* 标签，工作流的最后一个任务 publish 会将两个镜像分别推送到 ghcr.io/bymorning/bymorning 和 ghcr.io/bymorning/bymorning-code-interpreter，并使用版本标签； 然后检查每个已推送摘要是否与清单一致，使用相同身份进行无密钥签名，并将 SBOM 附加到两个镜像，将 provenance 附加到 Gateway（script/release/publish.sh）。首次推送可能会将软件包创建为私有（1.3.2 首次发布时为公开）：请在组织的 Packages 设置中确认每个软件包均为公开。如果某个软件包名称此前已被另一个仓库使用，请先删除旧软件包；新仓库无法写入该软件包（permission_denied: write_package）。

4. 提交 release/manifest.json、release/signer.txt、release/trusted_root.json 和 release/<version>/，并 发布 GitHub Release：

   git add release && git commit -m "release: <version>"
   tar -czf bymorning-<version>-evidence.tar.gz release     # tarballs are gitignored; the archive keeps release/'s layout
   gh release create v<version> --notes-file <changelog excerpt> \
     release/bymorning-*<commit>.tar bymorning-<version>-evidence.tar.gz release/manifest.json release/signer.txt
   

   两个证据文件夹包含同名文件（SHA256SUMS、signer.txt 等），而发布资产名称必须唯一，因此证据会打包为一个归档文件。v1.3.1 的发布说明展示了验证步骤。

5. 将 AWS 模块镜像到 Terraform Registry：运行 sh script/release/terraform-module.sh <directory>，将其导出到 bymorning/terraform-aws-bymorning 的克隆仓库中，提交并创建相同的 v<version> 标签；Registry 会自动获取该标签。 不要在提交前于导出目录中运行 terraform init（脚本会写入 .gitignore 作为防护）。 将 server.json 发布到 MCP Registry：运行 mcp-publisher validate，然后以 bymorning 组织成员身份运行 mcp-publisher login github，再运行 mcp-publisher publish。

6. 为该版本生成安全审查包，并将 PDF 附加到 GitHub Release。首先更新 docs/security/review/release.json（其中的 VERSION、日期、测试结果和扫描摘要均来自证据）：

   bunx playwright install chromium     # once
   bun run security:render -- --release release
   gh release upload v<version> build/security/<version>/bymorning-security-review-<version>.pdf
   

7. 根据清单打包 Azure 安装程序： bun installers/azure/export.ts --out <directory>（生成 bymorning-azure-<version>.zip）。它只能从发布构建或仅修改了 release/、CHANGELOG.md、docs/security/evidence/、docs/security/review/release.json 和软件包版本的后续提交中运行（--force 可覆盖此限制）；如果证据未由发布签名者签名或签名验证失败，则会拒绝打包（--allow-unsigned 会导出标记为“UNSIGNED REHEARSAL”的文件）；如果目标已固定的签名者发生变化（工作流或签发者不同），则会拒绝打包，除非使用 --rotate-signer；新的发布标签不视为变化。

对于你自己的构建，bun script/release.ts 需要安装带 buildx 的 Docker，以及 syft grype cosign gitleaks semgrep （brew install ...）。除非将 cosign 指向开发密钥（BYMORNING_COSIGN_KEY=<cosign.key>，记录为 ephemeral），否则生成的证据不会签名；此类构建绝不可交付。 full-gate 工作流（.github/workflows/full-gate.yml）会在每次合并到 dev 以及每晚运行时，使用临时密钥执行相同的构建和证据流水线；随后使用 AWS 和 Azure 环境启动 tarball，运行 Azure kind 端到端测试、浏览器套件和安装程序检查。在 v* 标签上以 sign=true 派发时，它就是上文所述的发布构建；在其他任何引用上派发时，它会以无密钥方式签名，但仅用于测试签名流程，导出操作会拒绝该结果。其他每次运行都会构建 <version>-ci.<run>，并将其证据标记为 ephemeral。

SST 身份验证配置

每个已部署的阶段都需要在 SST 中配置以下值；仓库不提供默认密钥：

bunx sst secret set WEB_COOKIE_KEY --stage <stage>

部署时的 OIDC 设置（AUTH_ISSUER、AUTH_CLIENT_ID、AUTH_CLIENT_SECRET、AUTH_PROVIDER、AUTH_EMAIL_DOMAINS）已弃用。请改为在运行时配置 SSO：部署后，使用安装设置令牌打开 Setup——该令牌绝不会写入日志；启动时会将其写入服务器的设置令牌文件（开发主机上的 <data directory>/setup-token，镜像中的 /tmp/bymorning/setup-token），也可以由操作员将其作为 SETUP_TOKEN 密钥提供——然后向 IdP 注册 Setup 显示的回调 URL，再输入颁发者、客户端 ID、客户端密钥和允许的电子邮件域名。之后可通过 Settings → Security（Auth Provider）更换连接。

WEB_COOKIE_KEY 必须是 32 字节的 base64url 值。在商业 SST 阶段，共享 Router URL 是受信任的应用来源，它会提供静态前端，并将 /auth、/api 和 /system 转发到 Server。 Terraform 安装会从 Gateway 提供嵌入式 UI，Gateway 即为 HTTPS 来源。本地开发使用其配置的 APP_ORIGIN； Vite 会将这些相同的路由族转发到本地 API。其本地登录提供程序和持久化 Cookie 密钥由 bun dev 自动配置。

任何符合 OIDC 规范的 IdP 都支持 authorization-code 授权类型。每个 Auth Provider 都有自己的重定向 URI：${APP_ORIGIN}/auth/callback/<providerID>，Setup 会在保存前显示该 URI。在 Setup 中输入一次提供程序连接信息；之后的更改请通过 Settings → Security（Auth Provider）进行。

集成 OAuth 回调使用进程本地的一次性会合机制。max: 1 可防止稳定运行期间的请求在多个任务间路由，但无法在重启或滚动替换后保留待处理流程：每次部署或重启都会使待处理的集成 OAuth 尝试失效，受影响的用户必须重试。运维时应排空活动请求并避免新旧任务重叠；增加副本数量则需要共享回调存储。

贡献

请参阅 CONTRIBUTING.md。请按照 SECURITY.md 中的说明私下报告漏洞。 参与项目须遵守 Code of Conduct。

许可证

ByMorning 基于 MIT License 发布。第三方材料的出处列于 THIRD_PARTY_NOTICES.md。许可证涵盖代码；不授予对 ByMorning 名称或徽标的权利。