T3 Production Single-Site Deployment
NOTE
Advanced tier. Most teams should run the full training lifecycle at T0 — Dev or T2 — Pilot first. T3 adds declarative, GitOps-style deployment at a single site. It does not change how you train or validate.
T3 proves that declarative, GitOps-style deployment does not require Azure Arc. Several robots at one site you control, all reachable from a single operator network, are reconciled to a Git-declared desired state by a single local k3s node running FluxCD. Arc is unnecessary precisely because there is only one site you can reach directly. Train and curate exactly as at T2 — Pilot.
🧱 Minimum Infrastructure
| Concern | What you need |
|---|---|
| Hardware | Several robots at one site, reachable from a single operator network. |
| Edge infra | One local k3s node (a ~60 MB binary) + FluxCD. No Arc, no IoT Operations. |
| Cloud infra | Same as T2 — Pilot: AzureML, storage, registry, MLflow. |
| Delivery | FluxCD reconciles robots to Git-declared desired state; rollback is a git revert. |
🚀 Where to Go
This is a stub. The deployment mechanics are documented in the existing deployment docs. This recipe deliberately does not duplicate them:
- Fleet Deployment: FluxCD GitOps pipelines, image automation, and the deployment gating service used to swap policies safely.
- Infrastructure: cluster setup and advanced cluster setup: standing up the runtime.
- Ubuntu HiL OSMO Backend: move one Ubuntu desktop through host-ready, optional private reachability, connected, and CPU/no-command validated milestones.
🎓 Graduate When
- Robots span multiple sites, or sites become unreachable from a single operator network. That is the point at which a cross-site reachability and identity broker becomes genuinely necessary: T4 — Scale.
🔗 Related Documentation
🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.