runlot.json

{
  "name": "my-app",
  "org": "me",
  "main": "src/index.ts",
  "assets": "public",
  "database": true
}

フィールド

name は必須です。main と assets のうち少なくとも一方を指定する必要があります。両方ない場合、提供するワーカーも静的アセットもありません。framework を指定したプロジェクトは例外で、ビルドの過程でエントリーポイントとアセットを生成します。

サービスを宣言するフィールド

database、storage、auth は宣言です。runlot deploy がこの値を読み、まだないサービスを作ります。wrangler 設定のバインディング宣言と同じ場所で、有効にするコマンドやダッシュボードのボタンは別にありません。作成は冪等なので、同じ宣言で何度デプロイしてもサービスは 1 つです。

宣言を消してもサービスは残ります。消すのは runlot pg delete、runlot storage delete、runlot auth delete で、確認を経ます。auth はデータベースが必要なので、"auth": true だけ書いてもデータベースを一緒に作ります。

各サービスはプロジェクトごとに 1 つだけ接続できるため、サービス名の代わりに true で宣言します。ワーカーからはそれぞれ env.db、env.storage、env.auth でアクセスします。

バンドルマニフェスト

runlot deploy は、この設定ファイルをそのままアップロードしません。CLI はビルド結果を参照する別の runlot.json マニフェストをバンドル内に生成します。ユーザーが自分で書く必要はありませんが、以下の検証ルールが適用されます。

compatibilityFlags は許可リスト方式です。どのマニフェストも、ユーザーコードにプロセス全体の制御権限を与えるフラグを有効化できてはならないためです。バンドルが Node の組み込みモジュールを import する場合は nodejs_compat が必要なため、CLI が自動的に設定します。

WASM は modules フィールドを通じてのみ含めることができます。workerd は、バンドル内部で new WebAssembly.Module(bytes) を呼び出してコンパイルする方式を許可していません。Prisma のクエリコンパイラはこの制約の影響を受けます。

バンドルの上限

バンドルには通常のファイルのみを含めることができます。シンボリックリンク、プロジェクトルートの外を指すパス、重複したエントリはすべて拒否されます。