An AI agent builds Azure Local end to end — from a cold server's iDRAC to a running AKS cluster with GPUs. Then it moves that workload between your racks and Azure, and back, on landing zones we stand up to the Cloud Adoption Framework. Hands-off. Run out of New York.
Every stage is scripted, idempotent, and re-runnable. The agent serves the OS image over a range-capable server, drives the Dell iDRAC over Redfish, and reads its own telemetry to know when to advance — including the failure modes that usually need a human at the KVM at 3am.
Azure Local and Azure run the same control plane through Azure Arc, so a workload can live in your racks or in Azure — and move between them. The honest mechanism is replicate, run side by side, then cut over once checks pass — not live motion across the boundary. Containerized apps move cleanly via one GitOps definition; VMs move with Azure Migrate (migrating VMs into Azure Local is in preview for some source hypervisors — there's no one-click first-party reverse, so a move back is simply the replicate-and-cut-over loop run again). Because the resource stays Arc-governed, that loop runs in either direction.
Placement is fluid — the same workload can be re-homed either way after a validated cut-over.
We stand up enterprise-scale landing zones on both grounds — Azure public cloud and Azure Local — from the same Microsoft Cloud Adoption Framework blueprint, then govern them as one estate. Unified governance across the on-premises ground runs through Azure Arc, so it depends on outbound Azure connectivity. On the cloud side, the eight CAF design areas (identity, management groups, network topology, governance, and more). On Azure Local, the same identity, policy, and resource model extended on-premises through Azure Arc, the Arc resource bridge, and custom locations. We deploy and customize Microsoft's reference architecture — we don't replace Azure Policy, Entra, or Resource Manager.
The same blueprint targets Azure subscriptions and on-prem Azure Local. That parity — one identity model, one policy set, one resource hierarchy across both grounds — is exactly what makes the Pillar 02 mobility safe: a workload moves into a foundation it already recognizes.
AzureStack.NYC keeps the live record across all three pillars — clusters built, workloads moved, landing zones stood up. Figures are illustrative of the platform's own fleet unless tied to a named engagement.
Live, in flight, and planned. This is the public view; the console streams live stage detail for an active run.
| Cluster | Status | Hardware | GPU | Workload | Stage | Updated |
|---|
registry source: deployments.json · maintained by the deployment agents · IPs and credentials are never published here
The console streams the active run — stage progress, the agent's decisions, and the raw deployment log. Access is granted to operators and engagement clients.
Single sign-on connects to the AI Director console. Use your engagement access key to preview here.
Signed in · streaming the active 2x-t4-fl run. Full multi-cluster control is in the AI Director console.
A hybrid-cloud control plane and NYC-based Azure Local consulting — discovery, deployment, landing-zone design, and go-live. Built on the Luca Express platform.
Independent service — not affiliated with Microsoft. AzureStack.NYC is an independent offering operated by Gus IT on the Luca Express platform. It is not affiliated with, endorsed by, sponsored by, or a product of Microsoft Corporation, and holds no Microsoft partnership tier or certification unless separately stated. “Microsoft”, “Azure”, “Azure Local”, “Azure Stack HCI”, “Azure Arc” and “AKS” are trademarks of Microsoft Corporation, used here for descriptive and interoperability purposes only. We deploy and customize Microsoft's own reference architectures and tools; we do not resell or represent Microsoft. Capabilities described follow Microsoft's documented behavior — cross-environment workload moves are replicate-then-cut-over (not live motion), and figures shown are illustrative unless tied to a named engagement.