docs(website): tighten container runner intro paragraph

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5417 fix(api-public): return 405 for method mismatch instead of 5 …
• #5415 feat(dashboard): surface managed pool error state on compute …
• #5416 docs(website): tighten container runner intro paragraph 👈
• main

Get stack: forklift get 5416
Push local edits: forklift submit
Merge when ready: forklift merge 5416

_{change nkroqkku}

[claude]

Review

Small, low-risk doc tightening. One accuracy concern with the new wording:

Potential inaccuracy: "batch jobs like FFmpeg transcoding"

The new intro says the container runner is for "non-RivetKit workloads such as Unity or Godot dedicated game servers and batch jobs like FFmpeg transcoding." This doesn't match how the runner actually works:

• container-runner/src/child.rs::wait_until_ready polls the child's TCP port and only reports the actor "ready" once the child accepts a connection, failing (and killing the child) if it doesn't within readiness_timeout_secs (default 30s, per the Configuration table further down this same doc).
• actor.rs explicitly documents this as "readiness (so the actor is never reported ready before the child listens)."
• The whole model (see "How It Works" section below) is built around proxying gateway HTTP/WebSocket traffic to a listening child server, not running a one-shot CLI process to completion.

A typical ffmpeg invocation doesn't bind an HTTP port, so as described it would hit the readiness timeout and fail to start rather than running as a "batch job." Unless there's a documented pattern for wrapping one-shot processes with a stub HTTP listener (not covered anywhere in this doc or the README), the FFmpeg example contradicts the rest of the page and could mislead readers into attempting an unsupported use case.

Suggest either dropping the FFmpeg/batch-job example or, if one-shot batch workloads are actually supported (e.g. via some wrapper pattern), briefly noting how readiness works for that case.

Everything else

• The details trimmed from the intro (child-process-per-actor, gateway proxying, request-concurrency-per-container) are still covered in "How It Works" and "Deploy" below, so no information is lost.
• No code, tests, or other docs are touched — scope is appropriately minimal for a copy tightening PR.

[railway-app]

🚅 Deployed to the rivet-pr-5416 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	Jul 15, 2026 at 9:23 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Jul 15, 2026 at 9:18 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Jul 15, 2026 at 9:18 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Jul 15, 2026 at 9:16 pm
ladle	✅ Success (View Logs)	Web	Jul 15, 2026 at 9:12 pm
mcp-hub	✅ Success (View Logs)	Web	Jul 15, 2026 at 9:11 pm