すべてのサービスはURLです。プロキシがその仕組みです。
1つのコンテナがすべてのHoody KitサービスをそれぞれのHTTPS URLで公開し、独自にバインドしたものにはhttp-PORTスラグが割り当てられます。ポート、認証、TLS、実際のクライアントIPはすべてURLレイヤーで解決されます。
プロキシはベアメタル上で実行されます。Hoodyが見るのは管理APIコールのみ — コンテナのトラフィックはサーバーの外に出ません。
*.containers.hoody.com — wildcard TLS · no Certificate Transparency log exposure
1つの文法、多くのパターン
すべてのKitサービスは同じプロキシを通じて解決されますが、URLスラグが何であるかを示します。同じ文法、サービスごとに異なる形。
| サービス | URLスラグ | 備考 |
|---|---|---|
| ワークスペース | workspace-N | 他のサービスURL上の合成レイヤー |
| ターミナル | terminal-N | インスタンスごとのシェル; display-Nにマップ |
| ディスプレイ | display-N | インスタンスごとのGUI / X11デスクトップ |
| ブラウザー | browser-N | リモートChromeインスタンス |
| Code | code-N | インデックスあたりのVS Codeインスタンス |
| Files | files | シングルトン — インスタンスインデックスなし |
| SQLite | sqlite-N | データベースサービスごとに1スラグ |
| Exec | exec-N | スクリプトをAPIとして |
| エージェント | agent-N | エージェントごとのLLMインスタンス |
| cURL | curl-N | アウトバウンドHTTPプロキシ |
| デーモン | hoody-daemon-N | プロセスマネージャー |
| Cron | — （現在はcURL経由） | プレースホルダーサービス; スケジューリングはcURLに存在 |
| 通知 | n-N · notification-server-N | ブラウザーブリッジ + API |
| Pipe | — （他のサービス経由） | プレースホルダーサービス; ストリーミングはFiles/Terminal/Execに分散 |
プロジェクト24進数 × コンテナ24進数 = 2^192ペアの組み合わせ。ブルートフォース不可能。
任意のポートでサーバーを実行するとURLが割り当てられます。
http-PORTプレフィックスはプロキシをコンテナの内部ポートにルーティングします。nginxのサーバーブロックも、IngressのYAMLも不要です。
# listening sockets
$ ss -ltnp
https://PROJECT_ID-CONTAINER_ID-http-4000.SERVER.containers.hoody.com
https://PROJECT_ID-CONTAINER_ID-http-5173.SERVER.containers.hoody.com
https://PROJECT_ID-CONTAINER_ID-http-7070.SERVER.containers.hoody.com
— Hoodyキットポートはプラットフォーム自身のサービス用に予約済みです。それ以外はすべてあなたのもの。アプリ側では任意のポートにバインドして、http-PORTで公開してください。
— アプリはlocalhostではなく0.0.0.0にバインドする必要があります — ソケットはプロキシコンテナから到達可能である必要があります。
— HTTP/1.1、HTTP/2、HTTP/3、WebSocketをエンドツーエンドでプロキシします。任意のユーザーUDPはルーティングされません — 生のUDPが必要な場合は専用のIPv4を使用してください。
認証はアプリケーションミドルウェアではなくJSONポリシーです。
プロキシはリクエストがコンテナに到達する前に、JWTクレーム、パスワードハッシュ、IP CIDRレンジ、Bearerトークンを検証します。アプリはシンプルなままです。
{
"enable_proxy": true,
"default": "deny",
"groups": {
"dashboard": {
"type": "jwt",
"algorithm": "HS256",
"source": "header",
"key": "Authorization",
"secret": "<hmac-secret>",
"claims": { "role": ["admin", "viewer"] }
},
"office-only": {
"type": "ip",
"cidrs": ["203.0.113.0/24"]
}
},
"permissions": {
"dashboard": { "http": [4000, 5173] },
"office-only": { "ssh": true, "terminal": true }
}
}JWT
HS256 · RS256 · ES256 · ヘッダー / Cookie / クエリ · クレーム検証
パスワード
HTTP Basic · SHA-256 + ソルト · URLに埋め込み可能
IP
IPv4 CIDRマッチ · ソケットレベルでの実際のクライアントIP
Bearerトークン
グループごとに複数トークン · APIフレンドリー
コンテナレベルの権限はプロジェクトレベルの権限を置き換えます — マージはされません。継承に依存する場合は、両方のスコープを明示的に設定してください。
暗号URL上に覚えやすいURLを追加
APIコール1回でcrypto URLをapi.mycompany.comに変換できます。Let's Encryptは30〜60秒でプロビジョニングされ、90日ごとに更新されます。
https://67e89abc…-890abcdef…-http-4000.node-us.containers.hoody.com
https://api.mycompany.com
エイリアスの命名: 3〜61文字、小文字英数字とハイフン、文字または数字で始まり終わること。自動生成エイリアスは48文字の16進数。
本来組み合わせて使うもの
プロキシは多くのチームがゼロから組み立てるスタック（リバースプロキシ + 証明書マネージャー + VPNまたはトンネル + アプリごとの認証 + 監査ログ）を置き換えます。セルフホスト列が失敗する公理 — URL as route、URL as auth scope、URL as embeddable — はプロキシがネイティブに提供するものです。
| 懸念事項 | Hoody Proxy | セルフホスト相当 |
|---|---|---|
| ワイルドカードHTTPS | ネイティブでサポート — ネイティブ | certbot + 更新cron + 証明書ローテーション |
| 内部ポートへのルーティング | ネイティブでサポート — ネイティブ | サービスごとのnginxサーバーブロック |
| 実際のクライアントIP | ネイティブでサポート — ネイティブ | アプリごとにX-Forwarded-Forを解析 |
| JWT · Basic · IP · トークン認証 | ネイティブでサポート — ネイティブ | アプリごとのミドルウェア + セッションライブラリ |
| カスタムドメイン + TLS | ネイティブでサポート — ネイティブ | Cloudflare / DNS-01 / nginxリロード |
| 集中型リクエスト監査 | ネイティブでサポート — ネイティブ | nginxログ + ログシッパー + インデックス |
| iframeに埋め込み可能なURL | ネイティブでサポート — ネイティブ | アプリごとに手動でCORS / CSP / TLS |
| ハードウェア上で実行 | ネイティブでサポート — ネイティブ | どちらにしても自分で実行 |
Kubernetesのingressコントローラー、OktaへのSSOのためのCloudflare Tunnels、L3プライベートアクセスのためのTailscaleを既に使用している場合、それらのツールは特定のニッチでより優れています。プロキシはURLアドレス可能なコンテナサービスを主要な抽象として望む場合に価値を発揮します。
URL優先モデルが容易にする6つのワークフロー
チームがHoody Proxyで実際に展開しているパターンから。
リバースプロキシなしでAPIを展開
0.0.0.0:4000にバインドするとhttp-4000.SERVER.containers.hoody.comが割り当てられます。nginx、証明書、DNSの手間は不要。
自動TLS付きカスタムドメイン
POST /api/v1/proxy-aliasesを実行し、CNAMEを設定すると、最初のリクエストで30〜60秒でLet's Encryptがプロビジョニングされます。
エイリアススワップによるブルー/グリーン
api.company.comをコンテナBに向けてテストし、エイリアスを戻します。設定のリロードなし、ダウンタイムなし。
AIエージェントにコンテナを割り当てる
エージェントにJWTを渡し、プロキシがリクエストごとに検証し、エージェントはHTTPS経由でファイルの書き込み、コマンドの実行、SQLiteのクエリを行います。
マルチテナントSaaSサブドメイン
テナントごとに1つのコンテナ; TENANT.yourapp.comをエイリアス設定。テナント分離はURLレイヤーで強制。
即時失効
Control PlanへのDELETEコール1回でURLは1秒以内に無効化されます。キャッシュポイズニングなし。
最初のURLはAPIコール1回先にあります。
プロジェクトを作成し、コンテナを作成すると、すべてのサービスがすでにオンラインになっています。最初に立ち上げるインフラは不要です。
関連情報 — /platform/control-planeでプロキシエイリアス、権限、ログAPI。