the deploy story: spin deploy → container | wasm | edge

context

priority from the design convo was zero-ops "just deploy a binary." the
native binary (17KB, ~1.5ms cold start) already drops into any container/
custom-runtime host; the wasm module targets edge isolates. neither is
wrapped into a one-command deploy yet.

scope

• container path: a minimal Dockerfile (FROM scratch or distroless
  + the static binary + spin-serve as PID 1, or the binary speaking
  HTTP directly). deployable to Fly / Cloud Run / Lambda (custom runtime)
  / CF Containers, unmodified.
• edge path: wasm module + a fetch→(ENV,stdin)→stdout shim for
  CF Workers. depends on the wasm patch (#2).
• spin deploy: pick a target, build the right artifact, push.
  start with ONE target end-to-end (suggest Fly or Cloud Run — simplest
  "binary → URL").

non-goals

auto-scaling / multi-region — that's the host platform's job. spin produces
the artifact + adapter.

note

bin/spin-serve already does HTTP→CGI for native + wasm locally. the deploy
work is packaging that for a remote host, not re-solving the adapter.

Start by reading bin/spin-serve, which already handles HTTP-to-CGI locally for native and wasm, then review the dependency on wasm patch #2. Choose one deployment target from the listed platforms and trace the artifact and adapter requirements. Done means one target can build, package, push, and expose the app through a one-command spin deploy.