Jinba TrailのECS composition root（packages/service/src/deps.ts の buildServiceDeps）は、サービスが process.env を読み取る唯一 の場所です。それ以降の下流にはすべて注入されます。このページでは、そこが読み取るすべての変数（およびJinba TrailがラップするBrowserflowエンジンが読み取る変数）を、プレフィックスごとに列挙します。
2つのプレフィックス、2つのプロダクトがあります。JT_* / JINBA_* は Jinba Trail のホスト型ラッパー（@jinbatrail/service）を設定します。対象はorg、オートメーション、run gateway、live viewです。BROWSERFLOW_* / BF_* は下位の Browserflow オープンソースエンジンを設定します。対象はCLI（browserflow）とスタンドアロンREST Launcher（@browserflow/web-api）で、Jinba Trailはこれらを合成しますがforkはしません。Jinba Trail経由ではなくBrowserflowを直接セルフホストしている場合は、BROWSERFLOW_* / BF_* の行だけが該当します。
Dispatch とデータ 変数 目的 デフォルト 本番で必須 JT_RUN_DISPATCHトリガーされたオートメーションをrun gatewayがどうdispatchするか。sync（APIプロセス内で実行して結果を返す）または queue（SQSにenqueueし、workerサービスに実行させる）。queue が指定されてもqueueが設定されていない場合は、console warningを出して sync にフォールバックします。 syncNo — Jinba Trail自身のstagingは sync で実行されます。queue はscale-out pathです（docs/11 §7 を参照）。 JT_SQS_QUEUE_URLSQS run-dispatch queueのURL。JT_RUN_DISPATCH=queue を実際に有効にするには必須です。 unset JT_RUN_DISPATCH=queue の場合のみJT_DATABASE_URL / DATABASE_URLwrapper store（org、APIキー、オートメーション、run refs）用のPostgres connection string。両方が設定されている場合は JT_DATABASE_URL が優先されます。unsetの場合は JT_DATA_DIR 配下のon-disk SQLite fileにフォールバックします。これはsingle-nodeであり、ECS task restartをまたいでdurableではありません。unset（SQLite fallback） Yes — 本番では /ready gateがPostgres wrapper storeを要求します。BROWSERFLOW_DATABASE_URL / DATABASE_URLengine のplane store（runs、journals、deploys、schedules、secret refs）用のPostgres connection string。@browserflow/web-api の buildDeps が読み取ります。両方が設定されている場合は BROWSERFLOW_DATABASE_URL が優先されます。unsetの場合は BROWSERFLOW_DATA_DIR 配下のSQLiteになります。unset（SQLite fallback） Yes — multiReplicaGapsClosed readiness gateでカウントされます。JT_DATA_DIRPostgres URLが設定されていない場合に、on-disk SQLite wrapper storeを置くroot directory（<dir>/wrapper.sqlite）。 ./.jinbatrailNo BROWSERFLOW_DATA_DIRPostgres URLが設定されていない場合に、engineのSQLite-at-rest storeとEFS-mounted registryを置くroot directory。ECSではEFS mount（/data/registry）に固定されます。 ./.browserflow-planeNo（ECSでは常に設定されます） JT_REDIS_URL / REDIS_URLdistributed rate limiter、オーサリング live-view pub/sub relay（in-process busではなくreplica間にframeをfan outする）、schedule-firing lockで共有するRedis接続。両方が設定されている場合は JT_REDIS_URL が優先されます。unsetの場合、各replicaはin-process（非共有）のlimiter/busを使います。single replicaでは問題ありませんが、複数replicaでは静かに不整合になります。 unset API replicaを2つ以上実行する場合は Yes （multiReplicaGapsClosed でカウントされます）。 JT_REPLICA_COUNT情報用。意図したreplica countで、/ready readiness snapshotにだけ表示されます（何かの設定には使われません）。 1No
シークレットと暗号化 JINBA_MASTER_KEY / JINBA_KMS_KEY_ARN は、orgがオートメーション用に保存するすべてのシークレット（APIキー、webhook credentials、オーサリング中に使うlogin passwords）を保護します。このキーを失ったり、実デプロイでephemeralなdev defaultのままにしたりすることは、便利なデフォルトではなく重大なsecurity regressionです。
変数 目的 デフォルト 本番で必須 JINBA_MASTER_KEY保存される各secret envelopeをwrapする64-hex-character symmetric key（createMasterKeyKms）。JINBA_KMS_KEY_ARN が設定されていない場合に使われます。 unset ⇒ ephemeralなprocess-lifetime key（シークレットはrestart後に残らず、replica間でも共有されません） KMSを使わない場合は Yes （下記参照） JINBA_KMS_KEY_ARNAWS KMS CMKのARN。設定されている場合、これは JINBA_MASTER_KEY より優先されますDecrypt callで、JINBA_KMS_ENCRYPTED_MASTER_KEY からprocess-lifetimeのdata-master-keyを得ます。 unset 本番では推奨（Terraformで use_kms_envelope が有効な場合のdeployed default） JINBA_KMS_ENCRYPTED_MASTER_KEYAWS KMSで生成されたdata keyのBase64 ciphertext（aws kms generate-data-key --key-id <CMK> --key-spec AES_256）。JINBA_KMS_KEY_ARN が設定されている場合、boot時に一度だけ復号されます。 ""JINBA_KMS_KEY_ARN が設定されている場合のみAWS_REGIONKMS client（およびregionを必要とするE2B/SQS clients）に渡すregion。 SDK default どのAWS deploymentでもYes JT_SESSION_SECRETdashboard session cookieに署名するHMAC secret。 "jt-dev-session-secret"（checked-in dev constant）Yes — 本番でこれがまだdev defaultの場合、/ready gateはhard-failします（sessionSecretIsDevDefault）。JT_INTERNAL_TICK_SECRETPOST /internal/tick を認証する共有HMAC secret。これはEventBridge Schedulerから呼ばれるendpointで、期限が来たcron schedulesをrunsに変換します。このrouteは、これが設定されている場合にのみ mountされます。secretがなければ /internal/tick はなく、何もfireしません。x-jt-signature: hex(hmac-sha256(secret, rawBody)) でconstant timeに検証されます。unset（route unmounted） 本番でスケジュールされたオートメーションに依存する場合は Yes
セッションCookieとライブビュー（app.* / api.* のペア） JT_SESSION_COOKIE_DOMAIN と JT_ALLOWED_WS_ORIGINS は一緒に設定されます 。これはdashboard（app.*）とAPI/live-view WebSocket（api.*）が別originだからです。片方だけを設定すると、この対応が壊れます。app.* だけにscopeされたcookieは api.* のWebSocket upgradeに届かず、scope付きcookieなしで JT_ALLOWED_WS_ORIGINS を開くとdefense-in-depthとして弱くなります。両方ともTerraformの同じshared apex（var.domain_name）から設定されます。
変数 目的 デフォルト 本番で必須 JT_SESSION_COOKIE_DOMAINsession cookieの Domain attribute。shared apex（例: jinbatrail.indx.jp）に設定することで、app.* origin経由で設定されたcookieが api.* にも送られます。same-origin Next.js proxyはほとんどのrequestをforwardできますが、live-view WebSocket upgradeは直接 api.* に行くため、そこでcookieが必要です。また cookieSecure: true に切り替えます（configured DomainはTLSを含意するため、cookieは Secure としてmarkされます）。 unset（cookieは単一のserving originのみにscopeされます） dashboardとAPIが異なるsubdomainでserveされる場合は Yes （deployed topology） JT_ALLOWED_WS_ORIGINSlive-view WebSocket upgradeで受け入れる Origin headerのcomma-separated allow-list（例: https://jinbatrail.indx.jp,https://app.jinbatrail.indx.jp）。cookieの SameSite に加えたdefense-in-depthです。unset ⇒ Origin checkなし（local/same-origin devでは問題ありません）。 unset（empty list） 本番では Yes — GitHub #25
認証とネットワーク信頼 変数 目的 デフォルト 本番で必須 JT_ENVdev | staging | production | test | ci のいずれか（またはunset）。/ready におけるproduction/dev gateの分岐、dev-session default、cookie Secure を制御します。明示的に設定された値のうち dev/test/ci 以外は、実際にinternet-reachableなdeploymentとして扱われます 。Jinba Trail自身のstaging（jinbatrail.indx.jp）は production ではなく JT_ENV=staging で、productionと同じgateがかかります。unset（local devとして扱われます） Yes — すべての実deploymentで production（または staging）に設定してくださいJT_DEV_AUTHdeployed（non-dev）の JT_ENV で、zero-authかつauto-provisioningのdev sessionを再度有効にする明示的なescape hatch。JT_ENV がdeployed valueの場合だけ有効です。 unset（false） No — 本番ではunsetのままにしてください JT_DISABLE_DEV_SESSION強いlocal override。JT_ENV/JT_DEV_AUTH に関係なくdev sessionをoffにします。常に優先されます。 unset（false） Optional — prod-like local testingのbelt-and-suspenders JT_TRUSTED_PROXY_HOPSappの前段にあるtrusted reverse proxiesの数。pre-auth IP rate limiter用に、X-Forwarded-For chainの右側（spoof不可能な位置）からreal client IPを選ぶために使われます。invalid/non-positive valuesはdefaultにフォールバックします。 1（single ALB — deployed topology）trusted hopを追加した場合のみ調整してください（例: ALBの前段にCloudFrontを置く場合） JT_RATE_LIMIT_MAX / JT_RATE_LIMIT_WINDOW_MSrun gatewayのper-org rate limit（POST /v1/run/:flow は実際のChromium runを起動するため、unbounded gatewayはcost/DoS leverになります）。JT_RATE_LIMIT_MAX=0（またはnon-positive/invalid value）は完全にopt outします。 60 requests / 60000 msNo（妥当なdefaultが常に適用されます）。trafficに応じて調整してください JT_IP_RATE_LIMIT_MAX / JT_IP_RATE_LIMIT_WINDOW_MS/v1/run と /api/session に対するpre-auth、IP-scoped rate limit（GitHub #19）。JT_IP_RATE_LIMIT_MAX=0 はopt outします。120 requests / 60000 msNo（妥当なdefaultが常に適用されます）
ブラウザー実行バックエンド 選択はprecedence-orderedかつpureです（packages/service/src/browser/select.ts の selectBrowserCapability）。解決できたもののうち、最初 のものが採用されます。
変数 目的 デフォルト 本番で必須 E2B_API_KEY最高優先度。 存在する（non-empty）場合、E2B microVM Chromium backendを選択します。これはオーサリング agentのlive browser sessionに使われます。unset 下記参照 JT_E2B_BROWSER_TEMPLATEpre-baked Chromium imageを含む任意のE2B sandbox template。 E2B SDK default No JT_E2B_TIMEOUT_MS任意のE2B sandbox timeout。SDKにforwardされます。 E2B SDK default No JT_BROWSER_CDP_URL第2優先度。 CDP WebSocket endpointがある場合、CDP経由で到達するself-hosted Chromium tier（ECS browser serviceのinternal DNS name、例: ws://browser.<name>.internal:9222/jt）を選択します。これはrun executionに使われます。unset deployed ECS topologyでは Yes （api と worker の両方が設定します） JT_LOCAL_BROWSER第3優先度。 Truthy（1/true/yes/on）の場合、Playwright経由のlocal headless Chromiumを選択します。dev onlyです。unset（false） No — dev only (none of the above) 決定論的なin-memory fake browser capabilityにフォールバックします。recorded flowsは実際にはbrowserを操作しません。起動時に大きなwarningをlogします。 — 本番では絶対に発生してはいけません 。これはhard readiness-gate failureです（browserBackend: "memory"） JT_BROWSER_POOL_SIZEopt-in warm browser pool。runごとに破棄する代わりに、checkout済みcapabilitiesをrun間で再利用します。0 ⇒ disabled（pass-through。各runは本当にtear downされるfresh capabilityを受け取ります）。 0No JT_BROWSER_IDLE_MSpool reaperが未使用のwarm capabilityを閉じるまでのidle timeout。 60000No JT_BROWSER_CONNECT_TIMEOUT_MS / JT_BROWSER_READY_TIMEOUT_MSbrowser backendへのconnect / readiness待機のtimeouts。 implementation default No JT_NODE_BINauthoring sessionのNode workerをspawnするために使うNode binaryへのpath。BunのWebSocket clientはPlaywrightのremote transportを直接driveできないため、オーサリングはNode child process経由でbridgeします。 PATH 上の nodeNo JT_BROWSER_WORKER / JT_BROWSER_WORKER_AUTHORINGrun-executor Node workerとauthoring-session Node workerを区別するinternal flags。 — Internal — 手動で設定しないでください
AI / オーサリング 変数 目的 デフォルト 本番で必須 ANTHROPIC_API_KEYauthoring agent用のClaude API key（自然言語のtask descriptionとlive browser sessionをrecorded stepsに変換します）。createAnthropicModelClient({}) により暗黙に読み取られます（Anthropic SDK自身のdefault env varであり、custom-namedではありません）。 unset（authoring model callsが失敗します） Yes — これがないとオーサリング（「手順を生成」）は動作しません
Browserflowエンジン（BROWSERFLOW_*, BF_*） これらは下位のオープンソースエンジンを設定します。つまり、browserflow CLIとスタンドアロンの @browserflow/web-api REST Launcherです。Jinba Trailはこれらをforkするのではなく合成しています。Jinba Trailをホスト型dashboard経由でのみ操作する場合、これらを直接設定することはありません。Browserflowを独立してセルフホストする場合、またはJinba TrailのTerraformを読む場合に関係します。
変数 目的 デフォルト 本番で必須 BROWSERFLOW_STORECLI: local run/journal store pathをoverrideします。またはephemeral in-memory store（tests、ephemeral CI）用に :memory: を指定します。 .browserflow/store.sqliteNo BROWSERFLOW_ENV_ALLOWCLI: flowの env capabilityが読み取れるenvironment variable names のcomma-separated allow-list。listed keysだけがsnapshotされます。flowは、名前を指定してもunlisted valueを読むことはできません。 ""（allow-listedなし）No。ただしflowごとにreviewしてください。これはflowのenv surface全体です BROWSERFLOW_SANDBOXCLI: shell.run / fs.* toolsのdefault sandbox backend（現在は e2b）。browserflow run --sandbox <kind> によりinvocationごとにoverrideされます。 unset（localでunsandboxedに実行） No — defaultでremote sandboxingしたい場合に意図して設定してください BROWSERFLOW_SANDBOX_TEMPLATECLIのsandbox backend用のE2B sandbox template。 E2B SDK default No BROWSERFLOW_SANDBOX_TIMEOUT_MSCLIのsandbox backend用のE2B sandbox timeout。 E2B SDK default No BF_SERVE_TOKENnon-loopback host（--allow-remote）にbindする場合に browserflow serve が要求するBearer token。serve はdev-only Launcherであり、--allow-remote とtoken（flagまたはこのenv var）の両方がないnon-loopback bindを拒否します。 unset（loopback-only bindは許可。remote bindは拒否） serve --allow-remote を実行する場合のみBF_ENGINE_TOKENスタンドアロン @browserflow/web-api control plane（/runs, /flows, /deploys, /secrets, /schedules, /registry）へのすべてのrequestで要求されるBearer token（Authorization: Bearer <token>）。これは推奨 されるguardです。 unset verified trusted gateの背後に置く場合を除き Yes （BF_ENGINE_TRUSTED_GATE を参照） BF_ENGINE_TRUSTED_GATE1/true は、このstandalone engine processがすでにexternal trusted gate（例: wrapper自身の engineControlPlaneGate + ALB allow-list）の前段にあり、in-process tokenを不要とすることをassertします。それ自体では何も保護しません 。BF_ENGINE_TOKEN なしで設定されている場合、misconfigured external gateによってcontrol plane全体がunauthenticatedになるため、大きなwarningをlogします。unset 代わりに BF_ENGINE_TOKEN を推奨します。これはexternal gateを検証済みの場合だけ使ってください PORTBun HTTP serverがbindするport。Jinba Trail serviceとスタンドアロン @browserflow/web-api entrypointの両方が読み取ります。 8080No
BF_ENGINE_TOKEN と BF_ENGINE_TRUSTED_GATE のどちらも設定されていない場合、スタンドアロン @browserflow/web-api control planeはfail closedします。すべてのrouteが401になります。defaultでopenになることはありません。ただし、実際のexternal gateなし（またはmisconfigured ALB allow-list）で BF_ENGINE_TRUSTED_GATE=1 を設定すると、control plane全体がunauthenticatedになります。これはJinba Trail自身のsecurity remediationがcomposed wrapperで閉じたexposureと同じ種類です。BF_ENGINE_TOKEN を推奨します。
Sandbox: shell.run / fs.* 用のE2B（CLI、browser backendとは別） E2B_API_KEY は2つの独立した場所 で読み取られ、それぞれ効果が異なります。混同しないでください。
Service: ブラウザー実行 packages/service/src/deps.ts では、E2B_API_KEY がオーサリング/runs用のE2B browser capability（microVM内のChromium）を選択します。上記の ブラウザー実行バックエンド を参照してください。
CLI: sandbox化されたshell/fs packages/cli/src/bin.ts では、同じ E2B_API_KEY（加えて BROWSERFLOW_SANDBOX=e2b または --sandbox e2b）が、shell.run と fs.* tools用のE2B sandbox capabilityを選択します。これはflowがdriveするbrowserとは関係ありません。Configuration & portability を参照してください。Observability（任意） 変数 目的 デフォルト 本番で必須 JT_ALB_IDLE_TIMEOUT_S情報用。/ready readiness snapshotに表示されるALB idle-timeout値（live-view SSE windowをcoverできる十分な長さである必要があります）。 300No JT_TRACING_ENABLED / OTEL_SERVICE_NAME / OTEL_TRACES_EXPORTER / OTEL_EXPORTER_OTLP_ENDPOINTVariable-gated OpenTelemetry tracing（Terraform enable_tracing）。spanのexportには、追加でADOT/OTel collector sidecarが必要ですが、defaultではwiredされていません。 enable_tracing = false ⇒ unset、costなしNo
Terraform（deploy/terraform/compute.tf）はPostgres connection stringsを直接設定しません。代わりに、plain（non-secret）envとして JT_DB_HOST / JT_DB_PORT / JT_DB_USER / JT_DB_NAME / JT_DB_SSLMODE を設定し、RDS-managed master credentialからliveに取得する JT_DB_PASSWORD secret を加えます。そしてcontainer entrypoint（deploy/docker/entrypoint.service.sh）がtask start時にそれらから DATABASE_URL を組み立てます。そのためconnection stringは、staticでdriftしやすいsecretではなく、現在のauto-rotated passwordを常に反映します。
まだ利用できません browserflow record（live interactive Playwright capture）は予定されていますが、まだ実装されていません。現時点では --ops <file> が必要なので、live captureを制御する追加のenvironment variableはまだありません。documentingする前にownerへ確認してください。
設定とポータビリティ これらの変数の背後にあるportability contract。environment-specificなconcernはすべてlocal defaultを持つinterfaceです。
CLIと開発者体験 --sandbox、serve、これらの変数がtuneするinner loopを含む、browserflow command mapです。
