One request, no build stepOne request, no build step

JSON: a slug, a sentence of metadata saying why the thing was built, and the files base64-encoded. Each file may carry the SHA-256 of its own decoded bytes, which the server recomputes and refuses on a mismatch — so a truncated upload fails at deploy time rather than quietly serving a corrupt page.

The response carries the artifact’s id, the version just written, and the URL. Copy that URL field exactly: renderers glue adjacent characters onto a link, including invisible ones, and a zero-width space on the end of a perfectly good address is a 404 somebody has already tapped.

The alternative was direct multipart upload to storage. It lost for a reason that outlived the convenience argument: no storage access keys exist for this account, and with an endpoint none ever need to. The worker already holds a native binding to the bucket, so the only credential in play authorises deploying rather than raw bucket access.

That matters most for the case this product is actually for. The credential ends up in an agent’s environment, on somebody’s laptop, possibly in a hosted assistant’s stored configuration. A deploy key scoped to one account’s own artifacts and revocable from a dashboard is a much smaller thing to lose.

There is no build. If your agent wrote TypeScript, your agent compiles it. That is not an omission to be filled in later — a build step on this side would mean running somebody else’s toolchain against somebody else’s dependencies, and the product’s whole shape is that no user-authored code runs on the platform.

It also will not write the artifact. The platform runs no inference anywhere; every byte comes out of your agent’s model, on your tokens.