browser-flowでデプロイすることは、「新しいビルドを出荷する」ことではありません。これは、どのFlow digestがどのfrontでliveになっているかを記録することです。つまり、fleetについての宣言的で可逆な事実です。digestはすでに不変なFlowSpecを識別しているため、デプロイで何かを再ビルドすることはなく、ロールバックは以前のdigestへ向き先を戻すだけで、環境間のpromotionはテスト済みのdigestを単に移動するだけです。このページでは、FlowとPackの公開、Launcherでの公開、ロールバック、promotion、そしてUI canvasとGit上のYAMLを完全に同期させる方法を説明します。
このページはデプロイモデル（digest、front、ロールバック）について説明します。ホスト型サービス自体のインフラ、つまりECS、RDS、@jinbatrail/serviceそのものを出荷するデプロイパイプラインを実際に立ち上げるには、下の2つのランブックを参照してください。このページではそれらを重複して説明しません。

AWSでのセルフホスティング

インフラ全体のランブックです。ECSサービス、RDS Postgres、ALB、KMS、そしてそれらをつなぐ環境変数を扱います。

CI/CDパイプライン

mainへのマージやバージョンタグが、stagingとproductionのECSサービスをどのようにビルドし、ゲートし、rollするかを説明します。

​
公開してから公開面に出す

コントロールプレーンでは、「SDKをデプロイする」は2つの別々の動きになります。
  1. PackをplaneのRegistryへ公開する。versionedでdigest固定されます。
  2. そのFlowを、使いたいLauncher（“fronts”）で公開面に出す。
browserflow pack publish --registry https://plane.acme.dev   # versioned, digest-pinned
browserflow deploy daily-price-watch --as rest --as mcp       # expose on REST + MCP
最初のコマンドは、daily-price-watchを含むPackをアップロードします（このページで継続して使う例では、ブラウザーTool search-price@1.2.0がtransformに入力を渡し、条件に応じてsecret webhookへhttp.postを発火します）。公開はcontent-addressedなので、RegistryはPackをそのname@versionの下に保存し、密かに変わることが決してないdigestに固定します。 2つ目のコマンドは、daily-price-watch FlowをREST LauncherとMCP Launcherという2つのfrontで同時に公開します。同じFlow、同じdigestに、POST /flows/daily-price-watch/runsとして、そしてMCPツールとして、同時に到達できます。frontの全体（CLI、REST、MCP、cron、CI、container、embedded）についてはLauncherを参照してください。
Packを公開することとFlowをデプロイすることは、意図的に別の手順です。公開はあるversionをRegistryで利用可能にします。デプロイは特定のdigestをfrontでliveにします。公開しても公開面に出さないことができ、再公開せずにfrontの向き先を変えることもできます。

​
デプロイは宣言的な記録

デプロイはコードを移動しません。bindingを記録します。
フィールド意味例
FlowどのFlowが公開されるかdaily-price-watch
Digestどの不変なFlowSpecがliveかsha256:7f3a…
Frontどこで公開されるかrest, mcp
bindingがdigestを指し、そのdigestがFlowSpecのidentityそのものなので、live versionは曖昧になりません。各デプロイ（ホスト型サービスではautomation.published）を含むすべてのprivileged actionは、actor、timestamp、関係するdigestとともに監査ログへ書き込まれます。そのため、デプロイ履歴自体がcontent-addressedなtrailになります。
Flowの結果は、それをどのfrontが呼び出したかには決して依存しません。daily-price-watchをRESTとMCPの両方として公開しても、2つの異なる挙動は生まれません。同じdigestへ解決され、同じRiderで実行され、同じ結果を返します。frontはtransportであり、digestが真実です。

​
ロールバック

ロールバックはデプロイの逆操作であり、同じくらい軽量です。frontを以前のdigestへ向け直します。
1

以前のdigestを特定する

各デプロイは、どのdigestがliveだったかを記録しています。daily-price-watchの以前のknown-goodなdigestはすでにRegistry内にあり、すでに不変です。再ビルドするものはありません。
2

frontをそのdigestへ向け直す

以前のdigestをデプロイすると、front（rest、mcp、…）がその正確なFlowSpecへ再bindingされます。digestはすでにartifactをbyte-for-byteで識別しているため、compile stepは実行されません。
3

liveであることを確認する

新しいbindingは他のデプロイと同じように記録され、監査されます。digestは、UIにもCLIにも、どのversionが現在trafficを処理しているかを伝えます。
「以前のdigestへ向き先を戻す」ロールバックは、そのdigestのPackがまだRegistryに存在していることを前提にします。公開はdigest固定で不変なので、以前公開されたversionは上書きできません。同じname@versionの下に2つの異なるbodyがある場合はhard conflictであり、密かな置き換えにはなりません。したがってロールバックでは、以前実行したものを正確に再現します。

​
Promotion: dev → staging → prod

環境間のpromotionでは、stageごとに再ビルドするのではなくdigestを移動します。そのため、テストしたものがそのまま出荷されます。
矢印はビルドではなく、同じdigestがfrontからfrontへそのまま進むことを表します。3つの環境すべてでsha256:7f3a…は変わりません。
digestが一定なので、devで証明されたFlowSpecは、prodでserveされるものとbyte-for-byteで同じです。これは、再現性という原則のdeploy-timeでの姿です。ある場所で証明されたFlowは、そのFlowSpecとPackのdigestが同一であるため、別の場所でも再現されます。環境間でdigestを移動すること自体がcontent-addressedなので、安全で、冪等で、検証可能です。Registry間でPackをmirrorする方法（pull / push / sync / scheduled）についてはレプリケーションを参照してください。
promotionの前に、run inspector UIから直接browserflow replay --verifyを使って、記録済みFlowをそのJournalから再実行できます。これにより、digestを進める前にFlowがまだ同じように振る舞うことを確認できます。検証したものが、promotionするものです。

​
UIでの編集 ↔ Git上のYAML

UI canvasとYAMLは、1つのFlowSpecの2つの面です。同期から外れてドリフトする第2のsource of truthはありません。
  • canvasでFlowを編集すると、canonical YAMLがemitされます。
  • YAMLをimportすると、canvasがrenderされます。
  • digestは、どのversionがliveかを全員に正確に伝えます。
これにより、teamはartifactをforkすることなく責任を分担できます。engineerはGitでdaily-price-watchをmaintainし、non-engineerはUIで調整し、digestはどのversionがデプロイされているかを全員が読む共有座標になります。「console」と「repo」の間にドリフトはありません。どちらも同じcanonical FlowSpecを投影しているからです。
canonical YAMLはFlowSpecの決定論的なserializationです。canvasがemitする形式であり、canvasへimportし直される形式でもあります。canonicalであるため、同じFlowは常に同じ方法でserializeされます。これによりdigestが安定し、round-tripがlosslessになります。SDK & YAML authoringを参照してください。
canvasでの編集はcanonical YAMLをemitし、それがrepoに保存される形式です。そのYAMLをGitへ戻してreconcileすることは通常のversion-control flowです。変更されたFlowSpecは変更されたdigestなので、digestによりどんなdivergenceもすぐに見えるようになります。
いいえ。公開面に出すことは、明示的で宣言的な操作です。frontは、別のdigestをデプロイするまで、デプロイ済みのdigestにboundされたままです。YAMLまたはcanvasを編集すると新しいdigestが生成されます。そのdigestはデプロイしたときにだけliveになります。これこそが、ロールバックとpromotionを決定論的に保つ仕組みです。

レプリケーション

pull、push、sync、またはscheduled modeで、digest固定されたPackをRegistry間でmirrorします。到着時に検証されます。

Launcher

デプロイ済みFlowを公開できるfrontです。CLI、REST、MCP、cron、CI、container、embeddedがあります。

可観測性

Runをinspectし、Journalをtime-travelし、digestをpromotionする前に--verifyでreplayします。

コントロールプレーン

planeが第2のengineになることなく、Runをどのようにscheduleしobserveするかを説明します。

AWSでのセルフホスティング

ホスト型サービスを自分で立ち上げるためのインフラ全体のランブックです。

CI/CDパイプライン

サービスをstagingとproductionへ出荷するbuild → gate → rollパイプラインです。