storkit: create 407_spike_fly_io_machines_for_multi_tenant_storkit_saas

.storkit/work/1_backlog/407_spike_fly_io_machines_for_multi_tenant_storkit_saas.md

@@ -1,31 +1,31 @@
 ---
-name: "Fly.io Machines for multi-tenant storkit SaaS"
+name: "Fly.io Machines for multi-tenant storkit SaaS — docs, security & pricing"
 ---
 
-# Spike 407: Fly.io Machines for multi-tenant storkit SaaS
+# Spike 407: Fly.io Machines for multi-tenant storkit SaaS — docs, security & pricing
 
 ## Question
 
-Can Fly.io Machines provide sufficient isolation, fast enough cold start, and simple enough orchestration for a multi-tenant storkit SaaS where each tenant gets a dedicated container running storkit + claude code?
+What do Fly.io's published docs, security claims, and pricing say about using Machines as the isolation layer for a multi-tenant storkit SaaS? Is there anything that rules it out before we write code?
 
 ## Hypothesis
 
-Fly.io Machines (Firecracker-based microVMs) offer the right balance of isolation, cold-start speed, and operational simplicity for early-stage SaaS. A thin Rust auth proxy routes JWT-authenticated requests to per-tenant machines, avoiding the ops complexity of self-managed gVisor/Kubernetes.
+Fly.io Machines (Firecracker-based microVMs) are a viable isolation primitive for tenants running arbitrary shell commands, and the pricing model is workable at early SaaS scale.
 
 ## Timebox
 
-4 hours
+2 hours
 
 ## Investigation Plan
 
-- [ ] Review Fly.io Machines API docs (web search) — create/start/stop/destroy machine via REST; document the key endpoints and request shapes for a Rust `reqwest` client
+- [ ] Read Fly.io Machines API docs — what are the core primitives (machine lifecycle, networking, volumes, secrets)?
-- [ ] Research Fly.io's documented isolation model — what guarantees do they publish about Firecracker microVM isolation? Document what is claimed, and explicitly flag what would require independent security review before production use. Do not attempt to verify isolation empirically.
+- [ ] Research Fly.io's published isolation model — what security guarantees do they document for Firecracker microVMs? Summarise claims and explicitly flag what would require independent security review before production use.
-- [ ] Research cold start time — what do Fly.io docs and community benchmarks say? Flag that real numbers require a test account with a storkit image (out of scope for this spike).
+- [ ] Research cold start time — what do Fly.io docs and community benchmarks claim? Note that real numbers require a test account (covered in spike 408).
-- [ ] Evaluate persistent volume support — document the Fly Volumes API; can a volume be attached per-tenant for `.storkit/` and project root?
+- [ ] Research persistent volume support — can a volume be attached per-tenant? What are the size/count limits?
-- [ ] Research Claude auth injection — what options exist for passing per-tenant secrets (e.g. `~/.claude/.credentials.json`) at machine start? (env vars, secrets API, volume mounts)
+- [ ] Research secret injection options — env vars, Fly Secrets API, volume mounts. What's the right approach for per-tenant `~/.claude/.credentials.json`?
-- [ ] Sketch the auth proxy design — JWT validation → machine lookup → reverse proxy; confirm WebSocket proxying is supported
+- [ ] Research machine count and org limits — any hard caps that would block SaaS growth?
-- [ ] Check pricing model — document always-on vs stop-on-idle machine costs at 10, 100, 1000 tenants
+- [ ] Research pricing — always-on vs stop-on-idle machine costs at 10, 100, 1000 tenants. Include volume and egress costs.
-- [ ] Identify any documented showstoppers (machine count limits, network egress, image registry constraints)
+- [ ] Identify any documented showstoppers.
 
 ## Findings