Omnigentのデプロイ:ワンクリックプラットフォームからセルフホストまで
Omnigent は、オープンソースの AI エージェント フレームワークおよびメタハーネスです。Claude Code、Codex、Cursor、Pi、およびカスタム エージェントを調整し、書き換えることなくハーネスを交換し、ポリシーとサンドボックスを適用し、任意のデバイスからリアルタイムでコラボレーションします。
ひと目でわかる
- これは何?
- OmnigentのREADMEはデプロイメニューです。RenderとRailwayのワンクリックデプロイ、Docker compose、Fly.io、Modal、Cloudflareなどをカバーし、Postgres/SQLiteデータベースの選択、サーバー/ランナーの実行モデル、3つの認証モードについて説明します。
- 誰に向いている?
- OmnigentのデプロイREADMEは、ターゲットプラットフォームごとにサーバーを整理しています。RenderとRailwayのワンクリックボタン、Fly.io、Hugging Face Spaces、Modalのより手間のかかるパス、Cloudflare Containersのサーバーレスオプション、その他のホスト向けの共通Dockerイメージがあります。
- 商用利用できる?
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている?
- 主に Python です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月14日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
omnigent: デプロイREADMEの内容
リポジトリのデプロイREADMEは、Omnigentサーバーをさまざまなプラットフォームで実行するためのメニューです。まず、RenderとRailwayでのワンクリックデプロイが紹介されています。これはローカルツールを必要とせず、マネージドPostgresデータベースを自動的にプロビジョニングし、組み込みのaccounts認証プロバイダをデフォルトにします。初回起動時に管理者アカウントが作成され、パスワードはサービスのログに表示されます。それ以外にも、Fly.io、Hugging Face Spaces、Modal、D1とR2を備えたCloudflare Containers、ローカルサーバーを公開するCloudflareクイックトンネル、プライベートアクセスのためのTailscale、Databricks Apps、Docker対応ホスト向けの共通Dockerイメージが文書化されています。また、サーバーのデプロイ先ではなくサンドボックスプロバイダのガイドであるエントリについても明記されています。
omnigent: PostgresとSQLiteのデータベースバックエンド
サーバーは2つのデータベースバックエンドをサポートしており、どちらも同じスキーマとマイグレーションを持つファーストクラスのものとして説明されています。選択はDATABASE_URLで行います。Postgresはデフォルトかつ本番用の答えであり、複数のサーバーインスタンスで必要で、RenderとRailwayでは自動プロビジョニングされます。他のプラットフォームでは自分で用意します。READMEはNeonを提案し、postgres://またはpostgresql://のURLが機能し、エントリポイントがpsycopg3方言に自動的に正規化することに言及しています。SQLiteはデモと単一インスタンスのデプロイ向けのゼロ依存のライトティアで、.dbファイルはプラットフォームの永続ディスクに置かれます。READMEはその制限について警告しています。Hugging Faceの無料Spaceはディスクが一時的なため再起動でSQLiteがリセットされ、Modalのボリュームのセマンティクスはライブ.dbファイルには適していません。また、リモートPostgresへの初回起動ではネットワーク経由でマイグレーションが実行され、Neonでは約1分かかること、サーバーのワーキングセットはおよそ512MBから1GBであることも述べられています。
omnigent: HTTP/2プロキシの要件
READMEの特徴的な部分として、HTTP/1.1でWeb UIを配信すると見かけ上フリーズする理由が説明されています。開いている各セッションは長時間存続するストリーミングHTTPレスポンスを保持し、HTTP/1.1ブラウザはオリジンごとの同時接続数を約6に制限します。複数のウィンドウを開くとプールは保持されたストリームでいっぱいになり、他のすべてのリクエストはその上限の後ろでキューに入るため、サーバーはアイドル状態なのにUIがフリーズしたように見えます。修正方法はHTTP/2で配信することです。HTTP/2はすべてのストリームを1つの接続で多重化します。バンドルされているCaddyオーバーレイ(docker-compose.https.yaml)がこれを提供し、ワンクリックプラットフォームとマネージドDatabricksはエッジでTLSを終端しHTTP/2をサポートします。ギャップは生の:8000 HTTP/1.1ポートをブラウザに直接公開する場合だけで、READMEは単一ウィンドウでは問題ないと述べています。
omnigent: サーバーとランナーの実行モデル
OmnigentはWebSocketトンネルで接続された2つの部分で実行されます。サーバーはデプロイされるFastAPIアプリで、HTTPとSSEルート、ターミナルアタッチ用WebSocket、永続化、Web UIを処理します。ランナー(ホストと呼ばれる)はユーザーのマシン上で実行されるPythonサブプロセスで、WS /v1/runner/tunnel経由でダイヤルインし、LLMループとツールをローカルで実行し、イベントをストリーミングして戻します。デプロイオプションはサーバーのみを対象としており、ランナーは各ユーザーがomnigent run ... --server <url>やomnigent claude --server <url>などのコマンドで起動します。この分離により、サーバーイメージは小さく、tmuxもハーネスSDKもLLM APIキーも含まれておらず、サーバー内でエージェントコードは実行されません。
omnigent: ラップトップの接続またはクラウドサンドボックスでのホスト実行
サーバーが起動したら、ユーザーはomnigent login https://your-hostでサインインします。このコマンドはサーバーの認証モードを自動的に検出し、組み込みのaccounts、OIDC、ヘッダー認証プロキシ、Databricksホスト型サーバーに対応します。次にomnigent host https://your-hostでマシンをホストとして登録するか、omnigent run path/to/agent.yaml --server https://your-hostで1回限りの実行をサーバーに向けます。ラップトップの代わりにクラウドホストを使用する場合、READMEはModal、Daytona、Islo、E2BでのCLI起動サンドボックスと、host_type managedでセッションを作成するとサーバーがサンドボックスをプロビジョニングし、ホストを起動してセッションを実行するサーバー管理ホストをカバーしています。サンドボックスはclaude、codex、pi、kiro-cliのハーネスCLIを含むプリベイクされたホストイメージから起動し、カスタムホストイメージのビルドと使用も文書化されています。
omnigent: 認証モードとREADMEの警告
認証は単一のOMNIGENT_AUTH_ENABLEDスイッチで制御されます。フレームワークのデフォルトである素のローカルサーバーではオフになり、シングルユーザーのheaderモードになりますが、コンテナ化されたデプロイではネットワークに公開されるインスタンスは認証されるべきなので1に設定されます。スイッチがオンの場合、OMNIGENT_OIDC_*変数を指定するとOIDCが選択され、それ以外の場合は組み込みのaccountsフローが使用され、OMNIGENT_AUTH_PROVIDERでモードを明示的に固定できます。accountsモードはデプロイのデフォルトで、最初のユーザーが管理者になるブートストラップとUIベースの招待があります。OIDCは既存のアイデンティティプロバイダを持つチーム向けで、HTTPSが必要です。headerモードはデフォルトで信頼されたSSOプロキシからX-Forwarded-Emailを読み取ります。READMEは、プロキシがクライアント提供のアイデンティティヘッダーのコピーを除去しない場合、誰でも誰かに成りすますことができると強く警告し、ほぼすべてのユーザーにaccountsまたはOIDCを推奨しています。
実際の構成では、サーバーの公開とランナーの接続を別々に扱う必要があります。まず accounts か OIDC を選び、OMNIGENT_AUTH_ENABLED と OMNIGENT_AUTH_PROVIDER の値を確認します。header を選ぶ場合は X-Forwarded-Email を外部から注入できないプロキシ構成が前提です。複数セッションをブラウザで開く運用では HTTP/2 を通し、docker-compose.https.yaml の Caddy 経路を使えるかを確認します。SQLite は単一インスタンスのデモには合いますが、Hugging Face の一時ディスクや Modal のボリュームでは保存状態が期待どおり残らないと README が警告しています。
編集部の結論
OmnigentのデプロイREADMEは、ターゲットプラットフォームごとにサーバーを整理しています。RenderとRailwayのワンクリックボタン、Fly.io、Hugging Face Spaces、Modalのより手間のかかるパス、Cloudflare Containersのサーバーレスオプション、その他のホスト向けの共通Dockerイメージがあります。また、PostgresとSQLiteのデータベースバックエンド、多数の同時セッションに対するHTTP/2プロキシの要件、accounts、OIDC、headerの各認証モードについても説明しています。 実際の構成では、サーバーの公開とランナーの接続を別々に扱う必要があります。まず accounts か OIDC を選び、OMNIGENT_AUTH_ENABLED と OMNIGENT_AUTH_PROVIDER の値を確認します。header を選ぶ場合は X-Forwarded-Email を外部から注入できないプロキシ構成が前提です。複数セッションをブラウザで開く運用では HTTP/2 を通し、docker-compose.https.yaml の Caddy 経路を使えるかを確認します。SQLite は単一インスタンスのデモには合いますが、Hugging Face の一時ディスクや Modal のボリュームでは保存状態が期待どおり残らないと README が警告しています。
コミュニティノート