Files
zooqueen 62bbc7766c skills: give each skill the directory its name declares
Every SKILL.md already declared the new name — name: frames, frames-cli,
frames-core, and so on — but the directories were never moved, so the tree
carried frames-* in content and hyperframes-* on disk. Everything that
resolves a skill by path missed: the core-skill list, the plugin marketplace
pin, and the docs the CLI reads at runtime. Eight tests failed on main because
the files they open do not exist.

The directories now match what the files say they are, and the guide the
claude-design contract reads takes the name that contract already used.
2026-08-13 18:17:24 -07:00

3.5 KiB

Cloud Run rendering on Google Cloud

Use frames cloudrun only when the user explicitly wants self-managed Google Cloud infrastructure. It deploys Cloud Run, Workflows, and Cloud Storage. For a managed default use frames cloud; for AWS use frames lambda.

Prerequisites

  • gcloud is authenticated and the target project has billing enabled.
  • Terraform 1.5 or newer is on PATH.
  • Docker or permission to use Cloud Build is available.

Lifecycle

npx @hanzo/frames cloudrun deploy --project <gcp-project> --region us-central1
npx @hanzo/frames cloudrun sites create ./project
npx @hanzo/frames cloudrun render ./project --width 1920 --height 1080 --wait
npx @hanzo/frames cloudrun progress <execution-name>
npx @hanzo/frames cloudrun destroy --project <gcp-project>

deploy enables the required Google APIs, builds or accepts a container image, applies the bundled Terraform module, and stores the resulting coordinates in ~/.frames/cloudrun-state.json. Use deploy flags such as --image, --repo, --cpu, --memory, --max-instances, and --timeout only when the infrastructure needs those overrides.

sites create uploads a content-addressed project archive for reuse by render-batch; pass its --site-id to that command to skip the batch upload. Single cloudrun render currently resolves the project from its directory and does not consume --site-id. Both render commands require --width and --height; supported output formats are mp4, mov, png-sequence, and webm. Use --output-resolution 4k to supersample an authored composition without changing its layout dimensions.

Common render flags are --fps 24|30|60, --quality draft|standard|high, --codec h264|h265 for MP4, --chunk-size, --max-parallel-chunks, --target-chunk-frames, --render-id, --output-key, --wait, and --wait-interval-ms. Use --json for machine-readable output.

For a variable-driven single render:

npx @hanzo/frames cloudrun render ./template \
  --width 1920 --height 1080 \
  --variables-file ./alice.json \
  --strict-variables \
  --wait

Use exactly one of --variables and --variables-file. Read variables-and-media.md for the composition-side contract.

JSONL batches

npx @hanzo/frames cloudrun render-batch ./template \
  --batch ./users.jsonl \
  --width 1920 --height 1080 \
  --max-concurrent 10 \
  --site-id <site-id> \
  --json

Each nonblank line must contain an outputKey; variables is optional:

{ "outputKey": "renders/alice.mp4", "variables": { "name": "Alice" } }
  • --max-concurrent defaults to 50 and limits in-flight executions. --max-parallel-chunks separately limits chunks inside one render.
  • --dry-run parses the file and prints would-start rows without starting executions.
  • The template uploads once unless --site-id is supplied.
  • Per-entry start errors remain visible and make the command exit nonzero.
  • Do not rely on --strict-variables for cloudrun render-batch: the current command accepts the flag but does not validate batch rows. Validate the JSONL variable objects against the composition schema before dispatch. The strict gate does work for single cloudrun render.

render without --wait returns an execution name. Use cloudrun progress <execution-name> until it succeeds, then verify the reported GCS output. destroy removes the Terraform-managed stack and its scratch bucket; preserve any deliverables that must outlive the stack.