Project / Retired
Infrastructure & automation
One centrally managed source for deploying vetted applications across a multi-client managed-services estate. A self-hosted ProGet repository in Azure feeds a customised Chocolatey layer; Intune deployment maps back to the central repo and only personalisation is handled device-side. Designed, built and shipped solo, end to end – a real infrastructure bet, not a side experiment.
- Status
- Retired
- Group
- Internal
- Stack
- Azure, ProGet, Chocolatey, Microsoft Intune, Entra ID, PowerShell
- Repo
- Previous employer — private (Azure DevOps)
- Related writing
- Internal only (previous employer)
Architecture
- ProGet over Azure Artifacts or the public Chocolatey community feed. Native Chocolatey support, client-side SSO for engineers and end users, Entra-manageable roles, and built-in security scanning – all in one product. Community installers were a hard no: vet-and-host them ourselves, never deploy something that could later be a supply-chain risk. Security first, ease second.
- Hosted on a Windows Azure VM, not Linux. Linux would have run it; Windows kept it manageable and ownable by a wider team long-term, rather than tied to one person. Chose handover-ability over a leaner host.
- Chocolatey layer over per-tenant Intune Win32 packaging. One versioned package set reused across every client tenant, instead of rebuilding installers per client. Trade-off accepted: a central dependency everyone relies on.
- Core package immutable, personalisation pushed to the device. Ship a change once and it lands everywhere, rather than editing per client. Keeps the source of truth singular.
- Public read-only repo, admin locked down – a deliberate accessibility trade-off. Remote engineers run out-of-box builds from anywhere, so reads were left open while publish/admin sat behind Entra roles and packages were scanned before landing. Azure-native geo-targeting, DDoS protection and rate limiting were provisioned but off at pilot scale, toggle-on-able instantly, with a traffic review planned as the trigger. Risk named, bounded, and one switch from mitigated.
Evidence
- The genuinely hard parts: getting roles to propagate cleanly from security groups, and writing the PowerShell so adding a new package was as low-friction as possible.
- Validated at ~100 devices in pilot, onboarded client-by-client (gated by per-tenant Intune setup and propagation); architected for a ~50k-device multi-client estate, with headroom beyond before licensing would need revisiting.
- A real commitment, not a toy: a licensed package-management platform with a mid four-figure annual running cost behind it.
- Reached production with senior leadership sign-off and two waves of engineer training.
- Retired – and the lesson stuck. It reached production but didn't become the default way of working, and the takeaway was mine to keep: a platform only succeeds if adoption is designed in from the start, not assumed. Next time I'd treat rollout and change-management as first-class deliverables alongside the build itself.