ここまでのすべては、インフラなしで動作します。サービスは、エンジンをチーム向けの「workflows as a service」に変える任意のコントロールプレーンです。デプロイ、レプリケーション、スケジューリング、マネージドシークレット、RBAC、可観測性を提供します。これはオープンコア（Apache-2.0のエンジンに対して、サービスは薄く置き換え可能な階層）であり、オプトインです。導入してもFlowの実行方法は一切変わりません（原則 T6）。

デプロイ

Pack公開とFlow露出の宣言的モデル

レプリケーション

content-addressedなRegistryミラーリング

スケジューリング

cronとイベントで実行、Journal付き

シークレット

実行時にワーカー上でのみ解決

アクセス制御

owner / memberのRBACとAPIキー

可観測性

Journal上に構築されたRun Inspector

​
  1. アーキテクチャ

コントロールプレーンがFlowを自分で実行することはありません。Flowをスケジューリングし、観測します。実行は常に実行の同じRiderであり、プレーンのStore、Secrets、Registryを指すbuildRunDepsを持つワーカー上で動きます。サービスはコーディネーターであり、新しいエンジンではありません。
スタック: API（@browserflow/web-api）にはHono on Bun、UI（apps/web）にはNext.js、メタデータにはSQLite（PlaneStoreインターフェイス経由。同じインターフェイスの背後でPostgresに差し替え可能）を使います。すべてインターフェイスの背後で置き換えられます。

​
  1. デプロイ - FlowとPackの公開

「Deploy SDKs」は、PackをプレーンのRegistryに公開し、そのFlowを必要なLauncherで公開する操作になります。
1

Packを公開する

browserflow pack publish --registry https://plane.acme.dev   # versioned, digest-pinned
2

Flowを公開する

browserflow deploy daily-price-watch --as rest --as mcp       # expose on REST + MCP
デプロイは宣言的で、元に戻せます。どのFlow digestがどのfrontでliveなのかを記録します。ロールバックは以前のdigestへ向け直すだけです。digestはすでに不変のFlowSpecを識別しているため、再ビルドは不要です。環境間の昇格（dev → staging → prod）はdigestを移動させるので、テストしたものと出荷されるものは完全に同じです。

​
  1. レプリケーション

「Services to replicate them」。Registryは他のRegistryとの間でPackをミラーできます。そのため、ある環境で作成されたPackを、別の環境に固定済みかつ検証済みの形で表示できます。レプリケーションはcontent-addressedなので、安全で、冪等で、差分的です。 
browserflow registry mirror \
  --from https://hub.acme.dev \
  --to   ./on-prem-registry \
  --packs "@acme/*" \
  --mode pull            # pull | push | sync
モード:
  • pull - 一致するPackをリモートからローカルRegistryへ取得します。
  • push - ローカルPackをリモートへ公開します。
  • sync - 双方向です。新しいdigestが勝ち、競合は表面化します（同じname@versionの下に異なる2つのbodyがある場合はハードな競合であり、黙って上書きされることはありません。semverとdigestの不変性がそれを禁じます）。
  • scheduled - ウォームミラー / DRレプリカのために、上記のいずれかをcronで実行します。
すべてのアーティファクトがdigestを持つため、レプリケーションは到着時に検証します。主張されたdigestへハッシュされないPackは、解決または実行される前に拒否されます。トランスポートは差し替え可能です（HTTPS registry、OCI registry、オブジェクトストレージ、またはエアギャップ向けのファイルバンドル。Launchers §4）。検証は、バイト列がどの経路で届いても同じです。
任意の署名: 公開者はPackManifestに署名できます。Registryは、ミラーを受け入れる前に、信頼されたキーによる有効な署名を要求できます。署名はdigestの上に載ります。完全性はdigestから、真正性は署名から得られます。

​
  1. スケジューリング

プレーンのスケジューラーは、cron式とイベント（webhook、キューメッセージ、上流Flowの完了）でFlowを実行します。スケジュールされた各実行はJournalを持つ通常のRunなので、失敗したスケジュールや実行されなかったスケジュールも、他と同じように検査可能でリプレイ可能です。スケジュール自体も宣言的なレコード（Flowにdigest固定）なので、記録上のスケジュールはコンソール内だけではなく、バージョン管理に存在します。

​
  1. シークレット

プレーンは、シークレットをFlowSpec、Journal、ログのいずれにも保存せずに仲介します（フリート全体での境界不変条件）。Flowの作成者はsecret.WEBHOOK_URLを参照します。プレーンのSecrets providerは、値をワーカー上で、実行時に解決し、secrets capabilityを宣言した手順にだけ注入します。バックエンドは差し替え可能です（プレーン自身の暗号化ストア、Vault、クラウドシークレットマネージャー）。ローテーションは透過的です。シークレットはすべての実行で再解決され、埋め込まれることはありません。

​
  1. アクセス制御、APIキー、MCP

ホスト型サービスのRBACは、意図的に小さくしています。org membershipは、ownerまたはmemberのちょうど2つのロールのいずれかです。
ロールできることできないこと
ownerAPIキーの発行/取り消し、メンバー管理、スケジュールの作成/削除、オーサリングの操作（Recordingの開始、手順の編集、公開）—
memberオートメーション、Run、ライブビューの読み取り上記の変更操作すべて
orgの最後のownerを降格または削除しようとすると、409 last_ownerで拒否されます。すべてのorgは常に少なくとも1人のownerを保持します。これはUIで隠しているだけではなく、サーバー側で強制されます。
完全なcapability表はアクセス制御を参照してください。 プログラムからのアクセス（REST run gatewayとMCPのどちらも）は、セッションCookieではなくAPIキーを経由します。
  • jbt_live_<rand>またはjbt_test_<rand>として発行されます。永続化されるのはsha256ハッシュだけで、平文は作成時に一度だけ表示されます。
  • **test**キーは、secret型の入力を持たない任意のオートメーションを実行できますが、シークレットを宣言しているオートメーションでは拒否されます（403 test_key_forbidden）。漏えいしたtest keyが本番認証情報に到達することはありません。シークレットを参照してください。
  • 任意のscopes allowlistにより、キーを特定のオートメーション（名前で指定）に制限できます。org境界だけでなく、さらに細かく最小権限を適用できます。スコープなし（デフォルト）は、org内のすべての公開済みオートメーションに到達できます。これはscopesが存在する前から変わりません。
ScopesはPOST /v1/run/:flowとPOST /mcpに同じように適用されます。スコープ外のオートメーションは/v1/runで403になり、MCPサーバーのtools/listにも表示されません。アクセス制御を参照してください。
**POST /mcp**は、ホスト型のModel Context Protocolエンドポイントです。同じBearerキーで認証します。各リクエストは、新しいステートレスなMCPサーバー（Streamable HTTP仕様に従い、sessionIdGenerator: undefined）を構築し、呼び出し元が公開済みでMCP有効にしているオートメーションごとに1つのToolを公開します。オートメーションのownerは、RESTの公開状態に触れずに、単一のオートメーションをMCPから隠せます（mcp_enabled: false）。デフォルトの同期ディスパッチモードでは、MCPからトリガーされたRunも、/v1/run/:flowが使う同じRunスコープのライブビューハブに登録されます。そのため、/api/automations/:id/run-liveはRESTやPlaygroundのRunとまったく同じように中継します。可観測性を参照してください。

​
  1. 可観測性 - Run Inspector

UIは何よりも、Journalの上に構築されたRun Inspectorです。
  • Timeline / DAG - グラフ、どの手順が実行されたか、どの手順がスキップされたか、何が並列実行されたか、どこに時間がかかったかを確認できます。
  • Step detail - 入力（シークレットはマスク）、出力、リトライ、解決されたToolバージョンとそのcontract digestを確認できます。
  • Live view - 読み取るJournalがまだ存在しない段階でも、同期ディスパッチされたRunのブラウザータブをCDPスクリーンキャスト越しにリアルタイムで見られます。
  • Time-travel - Journalをエントリごとにステップ実行します。ブラウザーToolでは、記録されたセッションのDOMリプレイをスクラブできます。
  • Replay - Toolアップグレードを昇格する前にFlowがまだ同じように振る舞うことを確認するため、UIから直接Journal（--verify）を使って再実行します。
InspectorはCLIと同じJournalを読むため、「UIで見えるもの」と「browserflow inspectが出力するもの」は同じデータです。第2の信頼できる情報源はありません。

​
  1. UIでの編集 ↔ Git内のYAML

UIキャンバスとYAMLは、1つのFlowSpecの2つの面です（原則 T1）。キャンバスでFlowを編集すると、正規化されたYAMLが出力されます。YAMLをインポートすると、キャンバスがレンダリングされます。チームは、エンジニアにGitでFlowを保守させ、非エンジニアにUIで調整させることができます。そしてdigestが、どのバージョンがliveなのかを全員に正確に示します。「コンソール」と「リポジトリ」の間にドリフトはありません。

​
  1. オープンコアの境界

階層内容ライセンス
Engine + SDK + std packs + CLI作成、コンパイル、実行、リプレイ、pack、launch - 完全にセルフホスト可能Apache-2.0
Serviceホスト型Registry、scheduler、secrets broker、RBAC、run inspector、replicationオープンコア。セルフホストまたはマネージド
EnterpriseSSO、細粒度RBAC、audit export、private browser pools、on-prem support商用
境界線は、再現性やポータビリティに不可欠なものがサービスの背後に置かれないように引かれています。無料のエンジンで構築され、検証されたFlowは、有料サービスでも同一に動作します。サービスが追加するのは調整であり、capabilityではありません。

​
次のステップ

CLIとDeveloper Experience

Flowの作成、実行、公開、検査のためのコマンドラインサーフェスです。

実行

コントロールプレーンがスケジューリングし、観測するRiderです。置き換えることはありません。

Launcher

ローカル、コンテナ、クラウド、オンプレミスにまたがって、FlowをREST、MCPなどとして公開します。

ToolsとPacks

content-addressedなPackと、Registryの背後にあるレプリケーションモデルです。