Compute deploy: managed pool enters error state (Failed to start container / PORT) although containers boot and listen on 0.0.0.0:3000

Summary

@rivetkit/cli deploy consistently fails with managed pool entered error state: Failed to start container: Ensure your container starts successfully on the PORT environment variable. Make sure your image was built for linux/amd64. — while the namespace logs show the exact same containers booting cleanly, binding 0.0.0.0:3000, and logging nothing but the RivetKit banner. Reproduces on every deploy attempt, across two namespaces and two separate apps/sessions.

Environment

• RivetKit 2.3.14 (npm), runtime banner reports 2.3.10
• CLI: rivet 2.3.14 (npx @rivetkit/cli deploy)
• Docker Desktop 29.8.0 / buildx (macOS, arm64 host — CLI builds with --platform linux/amd64)
• Runtime mode: serverless (Compute-injected; app uses plain registry.start(), no custom HTTP router)
• Image: node:24-slim, CMD ["node", "dist/server.js"], EXPOSE 3000, deps externalized
• App: registry with one agentOS actor (vm)

Steps to reproduce

npx @rivetkit/cli deploy --token <cloud_api_*> --namespace beta-7g2s-production-d1j5 --env PORT=3000 --yes
# also tried: --env PORT=3000 --env RIVET_PORT=3000

Token authenticates, namespace is created/upserted, image builds (docker buildx build --platform linux/amd64) and pushes to registry.rivet.dev/beta-g2ly:fca85e1 (digest sha256:0cb154e8…, second push sha256:0aec6ba5…). Pool then cycles deploying → … → error with the message above.

Actual result

INFO pool status status=deploying   (x20)
INFO pool status status=error
Error: managed pool entered error state: Failed to start container: Ensure your container starts successfully on the PORT environment variable. Make sure your image was built for linux/amd64.

rivet logs immediately after (timestamps UTC) shows healthy boots from four regions:

2026-09-10T07:34:41.050Z [DEFAULT] us-west-1        RivetKit 2.3.10 (Engine - Serverless)
2026-09-10T07:34:43.702Z [DEFAULT] ap-southeast-1   - Listening: http://0.0.0.0:3000
2026-09-10T07:34:43.895Z [DEFAULT] eu-central-1     - Actors: 1
2026-09-10T07:34:44.387Z [DEFAULT] us-east-1        - Public Dir: /public

No error/warn/crash lines after the banners — the containers stay up and listen.

What we already ruled out

1. Port mismatch — PORT=3000 (and PORT + RIVET_PORT=3000 variants); container logs confirm the app binds 0.0.0.0:3000.
2. Architecture — the CLI itself builds --platform linux/amd64; no arm64 layers in the manifest list.
3. Image defect — the identical image runs locally: docker run -e RIVETKIT_RUNTIME_MODE=serverless -p 3999:3000 … → GET /api/rivet/health → 200 {"runtime":"rivetkit","status":"ok","version":"2.3.10"}.
4. App crash — namespace logs contain only clean boot banners across us-west-1 / ap-southeast-1 / eu-central-1 / us-east-1.
5. Auth / namespace state — deploys authenticate, push, and upsert the pool fine.

Cross-check

A second app, deployed to a second namespace (beta-g2ly-production-kxh0) from an independent session, hits the identical error string — while its logs also show successful boots. Both namespaces currently 404 on their <ns>.rivet.run/api/rivet/health (no route), consistent with the pool start-check failing so no route is registered.

Ask

Looks like the managed-pool container start-check (health/registration probe) is rejecting containers that are actually up — possibly a probe-target/registration race or a probe-port regression in the runner. Happy to share namespace details privately or run any diagnostics you point me at.

Run the reported @rivetkit/cli deploy command and inspect rivet logs alongside the managed-pool status transition. Compare the start-check or registration probe with the logs showing 0.0.0.0:3000 and the /api/rivet/health request; done means a healthy container reaches a ready pool state and the namespace health route returns 200.