Problem
Split from #7180 — this piece is buildable now. TenantProvisioningDriver.createContainer/destroyContainer/containerExists (control-plane/src/tenant-provisioning-driver.ts) only has the in-memory fake. The container platform decision is made (Cloudflare Containers, one isolated container per tenant per product — ratified in #7173); nothing blocks implementing the real methods. The container image itself doesn't need to be built from scratch either: this repo already ships a self-host root Dockerfile that runs the ORB app — AMS needs its own equivalent (check packages/loopover-miner's self-host docs/systemd path for whether one already exists before adding a new one).
Area
control-plane/src/tenant-provisioning-driver.ts.
Proposal
Implement createContainer/destroyContainer/containerExists for real: use the Cloudflare Containers API (@cloudflare/containers) to stand up/tear down one container instance per tenant+product, keyed by request.tenant.name + request.product, running the existing self-host image (ORB: root Dockerfile; AMS: its own image per the note above). Pair each container with a Durable Object for routing/wake, per #7173's ratified shape — this is the piece #7181 (webhook routing) and #7182 (cron wake) will route/wake through once it exists. containerExists should be a real reachability/existence probe, not a guess. Keep the fake driver as-is for tests; add the real implementation selected by whatever fake-vs-real selection mechanism the driver factory already uses (check for the existing pattern — mirrors CodingAgentDriver's own driver-factory.ts — before inventing a new one).
Deliverables
Resources
Boundaries
Container lifecycle only — does not implement database provisioning (#7653) or HTTP transport (#7654), both separate pieces. Does not implement secret injection (separate issue, filed alongside this one) — a freshly-created container may sit without live secrets briefly; that ordering is provisionTenant's job (control-plane/src/provisioning.ts), already implemented and unaffected by this issue.
maintainer-only — provisions real infrastructure, not a first-pass contributor task.
Problem
Split from #7180 — this piece is buildable now.
TenantProvisioningDriver.createContainer/destroyContainer/containerExists(control-plane/src/tenant-provisioning-driver.ts) only has the in-memory fake. The container platform decision is made (Cloudflare Containers, one isolated container per tenant per product — ratified in #7173); nothing blocks implementing the real methods. The container image itself doesn't need to be built from scratch either: this repo already ships a self-host rootDockerfilethat runs the ORB app — AMS needs its own equivalent (checkpackages/loopover-miner's self-host docs/systemd path for whether one already exists before adding a new one).Area
control-plane/src/tenant-provisioning-driver.ts.Proposal
Implement
createContainer/destroyContainer/containerExistsfor real: use the Cloudflare Containers API (@cloudflare/containers) to stand up/tear down one container instance per tenant+product, keyed byrequest.tenant.name+request.product, running the existing self-host image (ORB: rootDockerfile; AMS: its own image per the note above). Pair each container with a Durable Object for routing/wake, per #7173's ratified shape — this is the piece #7181 (webhook routing) and #7182 (cron wake) will route/wake through once it exists.containerExistsshould be a real reachability/existence probe, not a guess. Keep the fake driver as-is for tests; add the real implementation selected by whatever fake-vs-real selection mechanism the driver factory already uses (check for the existing pattern — mirrorsCodingAgentDriver's own driver-factory.ts — before inventing a new one).Deliverables
createContainer/destroyContaineragainst the Cloudflare Containers API, product-agnostic (identical call shape for ORB and AMS tenants).containerExistsreachability check.Resources
control-plane/src/tenant-provisioning-driver.ts,control-plane/src/provisioning.tsDockerfile(existing ORB self-host image to reuse);packages/loopover-miner's self-host docs (AMS-side image)Boundaries
Container lifecycle only — does not implement database provisioning (#7653) or HTTP transport (#7654), both separate pieces. Does not implement secret injection (separate issue, filed alongside this one) — a freshly-created container may sit without live secrets briefly; that ordering is
provisionTenant's job (control-plane/src/provisioning.ts), already implemented and unaffected by this issue.maintainer-only — provisions real infrastructure, not a first-pass contributor task.