ByMorning

ByMorning

プロジェクトの状況。 ByMorning は MIT License のもと、現状のまま提供されています。開発元の会社は事業を終了しているため、ベンダー、サポート、SLA、メンテナンスの保証はなく、問題の確認やリリースの公開を行う義務を負う者もいません。このプロジェクトはコミュニティによってメンテナンスされています。フォーク、プルリクエストの作成、独自のビルドの実行を行ってください。脆弱性を報告する前に、SECURITY.md をお読みください。

ByMorning はセルフホスト可能な AI ゲートウェイです。自社のクラウドアカウント内で、自社が承認したモデルに対し、自社の権限、予算、監査のもとで、従業員、コーディングエージェント、内部システムを接続します。ドキュメント： https://bymorning.ai/docs。

インストール

各リリースイメージは、このリポジトリのリリースワークフローによってキーなしで署名され、署名済みの証拠（SBOM、スキャン、来歴）とともに ghcr.io/bymorning/bymorning に公開されます。これらはGitHub リリースで確認できます。

場所	用途
1 台のマシンで試す場合	Docker Compose による評価。本番環境向けではありません。
AWS または AWS GovCloud (US)	Terraform モジュール。Terraform Registry では bymorning/bymorning/aws としても公開されています。
Azure (AKS)	Azure インストーラー：Terraform と Kubernetes マニフェストを使用します。
任意の Kubernetes クラスター	Helm チャート。データベース、オブジェクトストレージ、キーは独自に用意してください。

コーディングエージェントを接続する

• モデル。 Claude Code、Codex、Cursor、VS Code Copilot、OpenCode、Gemini CLI を、サービスアカウントキーを使って、インストール環境の OpenAI、Anthropic、Google 互換エンドポイントに接続します。すべての呼び出しに、支出上限、ルーティング、使用量が適用されます。コーディングエージェントを接続するをご覧ください。
• ツール。 https://<your host>/mcp をリモート MCP サーバーとしてエージェントに追加します。エージェントは OAuth でワークスペースのメンバーとしてサインインし、ワークスペースの権限のもと、そのメンバーが使用できるツールを取得します。エージェントから ByMorning のツールを使用するをご覧ください。server.json は、MCP Registry 向けに io.github.bymorning/bymorning として記述されています。

開発

Bun と Node 22 以降を使って開発するには、リポジトリのルートで次を実行します。

bun install --frozen-lockfile
bun run dev

http://localhost:3000 を開くと、ローカルでのサインイン後、ワークスペースに直接進みます。開発ホストは、PGlite を使用して .bymorning/local/pglite に Postgres 互換のデータを永続化します。データベースに Docker は不要です。dev は API のウォッチャーをポート 3210 で実行し、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）、それらに付随する設定、ならびにデータベース、Cookie、オリジンの設定が必要です。詳しくは app/host/README.md を参照してください。開発ビルドには、PGlite、ファイルシステムストレージ、ローカル暗号化機能、Docker Code Interpreter が追加され、設定は不要です。

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

インストール文書と読み込み可能なプラグインパッケージを含む、dist/ ディレクトリ全体を配布してください。Docker イメージは Node で本番バンドルを実行します。コンパイル済みのアプリケーション実行ファイルはビルドされません。

データベース

Drizzle が Core の設定を使用するよう、データベースに関する操作はすべて packages/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、およびダイジェストを固定したイメージをお使いのレジストリにミラーリングします。

リリース

リリースは、ダイジェストで固定された linux/amd64 OCI tarball を含む単一の Gateway イメージと、署名済みの証拠（SBOM、脆弱性およびライセンスのレポート、スキャン、SLSA provenance、SHA256SUMS）で構成されます。インストーラーに依存せず、すべてのインストーラーが同じ tarball を配布し、同じダイジェストを検証します。

リリース署名は鍵を使用しません。 保管やローテーションが必要な署名鍵はありません。full-gate ワークフローは、独自の GitHub Actions ID を使用して Sigstore で証拠に署名します。署名証明書にはワークフローの実行が記載され、署名は公開透明性ログに記録されます。署名がリリース署名として認められるのは、その ID が、このリポジトリで v* タグ上から実行された full-gate.yml である場合のみです（script/release/signing.ts）。インストーラーのエクスポート処理はそれ以外を拒否し、リリースをパッケージ化する前に cosign ですべての署名を検証します。release/signer.txt に記載された ID と発行者を使って、誰でもリリースを確認できます。また、タグからリリースを再ビルドしてダイジェストを比較することもできます。ビルドは再現可能です。

リリースの作成手順：

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（IDと発行者）、ephemeral（使い捨てキー。実行ごとに異なります）、またはunsignedです。

   v*タグでは、実行の最後のジョブpublishが両方のイメージを、バージョンタグを付けて ghcr.io/bymorning/bymorningとghcr.io/bymorning/bymorning-code-interpreterにプッシュし、 プッシュした各イメージのダイジェストがマニフェストと一致することを確認して、同じIDでキーレス署名します。また、両方のイメージにSBOMを添付し、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
   

   2つの証跡フォルダーには同じ名前のファイル（SHA256SUMS、signer.txtなど）が含まれ、リリースアセット名は一意である必要があるため、証跡は1つのアーカイブにまとめて配布します。検証手順については、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リリースに添付します。まず 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 を指定してディスパッチすると、前述のリリースビルドになります。それ以外の ref では、署名パスを検証する目的でのみキーレス署名を行い、エクスポート時に結果が拒否されます。それ以外の実行では <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 シークレットとして指定します。Setup に表示されるコールバック URL を IdP に登録し、issuer、client ID、client secret、許可するメールドメインを入力してください。接続を後から変更するには、Settings → Security（Auth Provider）を使用します。

WEB_COOKIE_KEY は 32 バイトの base64url 値である必要があります。商用 SST ステージでは、共有 Router URL が信頼されたアプリケーションのオリジンとなり、静的フロントエンドを提供すると同時に、/auth、/api、/system を Server に転送します。Terraform でインストールする場合、組み込み UI は Gateway から提供され、Gateway が HTTPS オリジンになります。ローカル開発では、設定済みの APP_ORIGIN を使用します。Vite は同じルート群をローカル API に転送します。ローカルのログインプロバイダーと永続化される Cookie キーは、bun dev によって自動的に設定されます。

認可コードグラントに準拠した IdP であれば、どれでも利用できます。各 Auth Provider には固有のリダイレクト URI ${APP_ORIGIN}/auth/callback/<providerID> があり、保存前に Setup に表示されます。プロバイダー接続は Setup で一度登録してください。以降の変更には Settings → Security（Auth Provider）を使用します。

Integration の OAuth コールバックでは、プロセス内で一度だけ使用できるランデブーを使用します。max: 1 により通常時に複数タスク間でルーティングされるのを防ぎますが、再起動やローリング置換をまたいで保留中のフローを維持することはできません。デプロイまたは再起動のたびに、保留中の Integration OAuth 認証試行はすべて無効になり、影響を受けたユーザーは再試行が必要です。運用時はアクティブなリクエストをドレインし、旧タスクと新タスクが同時に稼働する状態を避けてください。レプリカ数を増やすには、共有コールバックストレージが必要です。

貢献

CONTRIBUTING.md を参照してください。脆弱性は SECURITY.md の説明に従い、非公開で報告してください。参加にあたっては 行動規範 が適用されます。

ライセンス

ByMorning は MIT License の下で公開されています。サードパーティの素材については THIRD_PARTY_NOTICES.md に記載されています。このライセンスはコードを対象とするものであり、ByMorning の名称やロゴの権利を許諾するものではありません。