runlot.json

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

필드

name 은 없으면 배포가 거절됩니다. main 과 assets 중 적어도 하나는 있어야 합니다 — 둘 다 없으면 서빙할 것이 없기 때문입니다. framework 를 적은 프로젝트는 예외입니다: 진입점과 자산을 빌드가 만듭니다.

기록이지 선언이 아닙니다

database · storage · auth 는 runlot pg create · runlot storage create · runlot auth create 가 적는 기록입니다. runlot deploy 는 이 값을 보고 만들지 않습니다 — 배포가 프로비저닝 경로이면 오타 하나가 조용히 데이터베이스를 만들고, 그것을 지우는 길은 배포에 없기 때문입니다. 기록과 실제가 어긋나면 배포가 경고합니다.

값이 이름이 아니라 true 인 이유는 한 프로젝트에 한 벌씩이기 때문입니다. 고를 것이 없으니 워커에서는 늘 env.db · env.storage · env.auth 입니다.

번들 매니페스트

runlot deploy 는 위 파일을 그대로 올리지 않습니다. 번들 안에 들어가는 runlot.json 은 빌드 결과를 가리키는 매니페스트이고, CLI 가 만듭니다. 사용자가 직접 적을 일은 없지만 검사 규칙은 알아 둘 만합니다.

compatibilityFlags 가 허용 목록인 이유는, 사용자 코드가 프로세스를 통째로 쥐게 하는 플래그를 어떤 매니페스트도 켤 수 없어야 하기 때문입니다. nodejs_compat 은 CLI 가 알아서 켭니다 — 번들에 Node 내장 모듈 import 가 있으면 그 플래그 없이는 로드 오류라, 사용자가 고를 것이 없습니다.

WASM 이 modules 로만 들어가는 이유는 workerd 가 번들 안에서 new WebAssembly.Module(bytes) 로 컴파일하는 길을 막기 때문입니다. Prisma 의 쿼리 컴파일러가 이 길로 들어갑니다.

번들 상한

번들에는 실제 파일만 담깁니다. 심볼릭 링크, 프로젝트 루트 밖을 가리키는 경로, 중복 항목은 모두 거절됩니다.