xAPI Workers for Platforms

Use the xapi CLI (xapi-to is the same executable). Verify xapi workers --help before using it; an older published installation may lack these commands even when the repository already contains them. Stop and report the version mismatch instead of silently replacing managed deployment with Wrangler direct deployment. Wrangler deploy --dry-run --outfile is allowed only as a local framework packaging step; the resulting Artifact must still be published with xAPI.

Start with scope

• Identify the control-plane host, Worker ID, and preview or production from the project and workers get. Test control plane and preview environment are separate choices.
• Authentication precedence: XAPI_KEY, XAPI_API_KEY, then ~/.xapi/config.json. Keys need workers:read and, for changes, workers:write, plus access to the target Worker. A scoped-out Worker can return 404.
• Production API host is api.xapi.to; testing uses XAPI_API_HOST=api.test.xapi.to (host only). Load secrets from the user's existing secure environment. Never print keys, include them in code/artifacts, or send the xAPI key to a public Worker URL or Cloudflare. Runtime application authentication is separate.
• For an existing linked project, start with workers inspect [worker-id] --env <environment> and workers capabilities. For a new unlinked project, use capabilities and plan; inspect needs a real Worker ID. Use workers plan --env <environment> when a local project is available and desired-state drift matters. inspect reads current runtime state only. plan runs the configured local build with credential-shaped environment variables removed, validates the exact Artifact, and compares it with live state without writing to the xAPI control plane. It also shows the budget cap, active price-book visibility, and usage-dependent resource changes; never present those estimates as an accrued invoice. Use existing user authorization for changes; don't expand cleanup from a test environment to production.
• Treat Worker execution and data placement separately. Worker code remains global. Use environment defaultResourceLocation only as the default for newly created D1/R2 resources and placementMode: smart only for Cloudflare Smart Placement. Never claim either setting migrates existing data.

Build where the CLI runs