Problem
AMS's existing Wave 4 fleet assets — docker-compose.miner.yml, the k8s manifests, and the Terraform starter shipped in #5177/#5181/#5183 — have no tenant/customer/instance concept in any of them; they're built for one operator running their own infra. ORB's equivalent work (#4898, making the setup wizard multi-instance-aware, and #4894-4897, templatizing systemd/Terraform/compose for multi-host) already went through this exact exercise. Without doing the same for AMS, any future hosted-provisioning work would either have to fork these assets into a second, divergent set of files, or bolt tenancy on ad hoc later.
Area
AMS / Fleet & ops management
Proposal
Extend the existing self-host fleet assets with an explicit tenant/customer/instance parameter set — naming conventions, isolation boundaries, and per-tenant resource limits — so the same templates serve both today's single-operator fleet mode and future hosted multi-tenant provisioning, without diverging into a second set of files to maintain in parallel.
Deliverables
- A design doc naming the specific tenant/instance parameterization to add to each existing asset (docker-compose, k8s manifests, Terraform starter)
- A statement of which Wave 4 files change in place vs. which get a new, additive tenant-aware variant — with the default being additive parameterization, not a fork
Resources
Boundaries
- Design only: no changes to the actual asset files in this issue — this produces the parameterization plan that a follow-on execution issue implements.
- Must not fork the Wave 4 assets into a separate hosted-only set. The recommended pattern is additive parameterization on the existing files; a design that proposes a second, divergent set of manifests/compose files/Terraform modules should be treated as not meeting this issue's bar and reworked before it's accepted.
- Must not assume a storage or provisioning-API shape that hasn't been settled by the sibling design issues in this milestone — reference them, don't re-derive them.
- This determines the shared-vs-forked shape of every future infra change to these assets; get the additive-vs-fork call wrong here and every subsequent fleet PR inherits the entanglement.
Problem
AMS's existing Wave 4 fleet assets —
docker-compose.miner.yml, the k8s manifests, and the Terraform starter shipped in #5177/#5181/#5183 — have no tenant/customer/instance concept in any of them; they're built for one operator running their own infra. ORB's equivalent work (#4898, making the setup wizard multi-instance-aware, and #4894-4897, templatizing systemd/Terraform/compose for multi-host) already went through this exact exercise. Without doing the same for AMS, any future hosted-provisioning work would either have to fork these assets into a second, divergent set of files, or bolt tenancy on ad hoc later.Area
AMS / Fleet & ops management
Proposal
Extend the existing self-host fleet assets with an explicit tenant/customer/instance parameter set — naming conventions, isolation boundaries, and per-tenant resource limits — so the same templates serve both today's single-operator fleet mode and future hosted multi-tenant provisioning, without diverging into a second set of files to maintain in parallel.
Deliverables
Resources
docker-compose.miner.yml, the k8s manifests, and the Terraform starter (Adddocker-compose.miner.ymlfor AMS fleet mode with named services and restart policy #5177, Add example Kubernetes manifests (Deployment + Secret) for AMS fleet-mode as a small-cluster alternative to docker-compose #5181, Add a Terraform starter module for provisioning a dedicated fleet-mode AMS host #5183)Boundaries