Deploy Winget applications to Microsoft Intune with a single click.
Skip the manual packaging workflow and deploy Winget apps to Intune in seconds.
10,000+ Winget apps | One-click deployment | Multi-tenant support | Free and open source
This is a fork of ugurkocde/IntuneGet. Everything here came out of running one real air-gapped deployment end to end: self-hosted Docker, DATABASE_MODE=sqlite, no Supabase, local Windows packager, behind a corporate proxy. That combination is documented as supported, but several paths through it did not work — see issue #167.
Each fix is a separate branch and, where it is ready, a pull request upstream. The intent is for all of this to land upstream and for the fork to become unnecessary.
| Branch | Contents |
|---|---|
main |
Plain mirror of ugurkocde/IntuneGet:main. No changes of our own. |
fork-main |
Default branch. All the work below, merged and kept current with upstream. |
| PR | Area | What it fixes |
|---|---|---|
| #220 | Web app | Supabase-less SQLite self-hosting |
| #221 | Local packager | HTTP(S)_PROXY support |
| #222 | Local packager | Win32 app creation payload |
Supabase-less SQLite self-hosting. createServerClient() throws when Supabase is not configured, and it was being called unconditionally on paths that either do not need Supabase at all or need it only for MSP tenant resolution — neither of which exists in a single-tenant self-hosted install. Deployment failed with a bare 500, and the dashboard, reports, update checking and the Update button were affected in the same way. Tenant resolution now falls back to the token's own tenant, and features with no SQLite equivalent report plainly (an empty list for reads, 503 for writes) instead of crashing.
Proxy support. The local packager's node-fetch calls and its msal-node token requests both ignored HTTP_PROXY/HTTPS_PROXY, so packaging never completed on a network that requires one.
Win32 app creation payload. Three Graph validation errors on the same POST /deviceAppManagement/mobileApps call, each only reachable once the previous one was fixed: detection rules were sent via a later PATCH rather than at creation (The Win32LobApp must have at least one detection rule specified), in the shape of the deprecated detectionRules property rather than the unified rules collection; fileName was missing; and minimumSupportedWindowsRelease was sent as v10_1903 instead of the bare release string 1903.
Detection rules detect the exact deployed version
IntuneGet creates one Intune app object per deployed version, and the PSADT package writes a registry marker recording the version it installed. The generated detection rule compared that marker with greaterThanOrEqual, so after an update the old app object's rule was satisfied too:
Deploy 152.0.1 -> app object A, rule: marker >= 152.0.1
Update 152.0.5 -> app object B, rule: marker >= 152.0.5 (marker now reads 152.0.5)
A: 152.0.5 >= 152.0.1 -> "installed" <- wrong, A is gone
B: 152.0.5 >= 152.0.5 -> "installed"
Intune then reports both versions present on the same device, and the old object's install count never drops. With one object per version, detection has to be an identity check, so the comparison is now equal. The MSI product version fallback had the same problem and gets the same treatment.
A second defect only shows on updates: an update reuses the previous deployment's configuration, whose detection rules still name the previous version — so the new app object shipped looking for its predecessor and would never report as installed anywhere. The rules are now re-targeted at the version being deployed. That re-targeting is deliberately narrow: it touches the IntuneGet marker and an MSI product version, and passes everything else through, since a file check or a script has a meaning it cannot infer.
"Allow available uninstall" setting
Every deployed app landed in Intune with Allow available uninstall: No, because the property was never set and Graph defaults it to false — with no way to change it short of editing each app afterwards. It is now a global operator setting alongside carry-over and supersedence, since the ask is a house rule ("our users may remove apps they installed themselves") rather than a per-app choice.
The property lives on win32LobApp itself, not on the assignment settings; Intune applies it to available assignments on its own.
Not covered: the GitHub Actions packager builds the app body in PowerShell and would need the same property to stay consistent.
Auto-update apps the user installed, when superseding them
Superseding an app does not by itself replace one a user installed from Company Portal — Intune only does that when the assignment asks for it. So a superseded app sat on the old version indefinitely: the relationship was recorded and had no effect on those devices.
Available assignments now carry autoUpdateSettings.autoUpdateSupersededAppsState: 'enabled' whenever the job supersedes a previous app. It is tied to supersedence rather than exposed separately, because the two are useless apart. Required apps are pushed regardless, so only available assignments get it.
Note
fork-main is kept merged with upstream, so it carries fixes the pull requests above do not yet have — including guards for two newer Supabase-only features on the deploy path (the catalog retirement blocklist and QA gating), which fail the same way in a SQLite install.
- Curated App Catalog - Browse 10,000+ applications from the Winget repository, ready for Intune deployment
- One-Click Deployment - Deploy apps directly to your Microsoft Intune tenant
- Real-Time Status - Track deployment progress with live updates
- Pre-Configured Detection Rules - Skip the manual configuration
- Community Ratings - See how other admins rate apps before deploying
- App Suggestions - Suggest and vote on new apps for the catalog
- In-App Notifications - Get notified about deployment status, app updates, and community activity
- PSADT v4 Support - Deploy apps with PowerShell App Deployment Toolkit v4 UI elements (dialogs, balloon tips, process handling)
- Multi-Tenant Support - Works with any Microsoft Entra ID tenant
- MSP Mode - Manage multiple client tenants from a single interface
- Tenant Isolation - Each client's data remains completely separate
- Batch Deployments - Deploy a single app across multiple tenants simultaneously with configurable concurrency
- Team Management - Invite members, assign roles (Owner, Admin, Operator, Viewer), manage access with role-based permissions
- Webhook Integrations - Configure event-driven webhooks for Slack, Teams, Discord, or custom endpoints with delivery logging and retry
- Audit Logging - Comprehensive audit trail with IP/user agent tracking and a dedicated log viewer
- Advanced Reporting - Cross-tenant deployment trends, success rate analytics, export to CSV/JSON/PDF
- Multiple Database Options - Supabase Cloud, self-hosted Supabase, or SQLite
- Flexible Packaging - GitHub Actions or local Windows packager
- Air-Gapped Support - Run entirely on-premises with no external dependencies
- Full Source Access - Audit, modify, and extend as needed
The fastest way to get started:
git clone https://github.com/ugurkocde/IntuneGet.git
cd IntuneGet
cp .env.example .env.local
# Edit .env.local with your configuration
docker-compose up -dSee the Self-Hosting Guide for detailed instructions.
flowchart TB
subgraph Frontend
A[Next.js App]
end
subgraph Auth
B[Microsoft Entra ID]
end
subgraph Backend
C[Supabase]
D[(PostgreSQL)]
I[Notifications]
end
subgraph Packaging
E[GitHub Actions]
F[Windows Runner]
G[IntuneWin Tool]
end
subgraph Microsoft
H[Intune API]
end
subgraph External
J[Webhooks - Slack/Teams/Discord]
end
A -->|MSAL Auth| B
A -->|Real-time Updates| C
C --- D
I --- D
I -->|Deliver| J
A -->|Trigger Workflow| E
E --> F
F --> G
G -->|Upload Package| H
A -->|Deploy App| H
| Component | Technology | Purpose |
|---|---|---|
| Frontend | Next.js 14, React, TypeScript | Web application and UI |
| Database | Supabase (PostgreSQL) | App catalog, deployment status, real-time subscriptions |
| Authentication | MSAL | Microsoft Entra ID integration (multi-tenant) |
| Packaging | GitHub Actions | Windows runner for .intunewin file generation |
| Deployment | Intune Graph API | Application deployment to tenants |
| Notifications | In-app, Email, Webhooks | Deployment events, community updates, team activity |
| Community | Ratings, Suggestions, Voting | Community-driven app catalog feedback |
IntuneGet is designed for flexibility. Choose the deployment model that fits your organization.
| Option | Best For | Complexity |
|---|---|---|
| Docker Compose | Production self-hosting | Low |
| Vercel | Quick deployment, serverless | Low |
| Full Self-Hosted | Air-gapped environments, maximum control | Medium |
| Option | Description | Use Case |
|---|---|---|
| Supabase Cloud | Managed PostgreSQL with real-time | Fastest setup, hosted version |
| Self-Hosted Supabase | Full Supabase stack on your infrastructure | Enterprise, compliance requirements |
| SQLite | Single-file database | Development, small deployments |
| Option | Description | Use Case |
|---|---|---|
| GitHub Actions | Cloud-based Windows runner | Default, no infrastructure needed |
| Local Packager | npm package for on-premises | Air-gapped, compliance requirements |
See Database Setup and GitHub Actions Setup for configuration details.
IntuneGet is built with security as a core principle.
- Source Code (this repo) - Fully open source, transparent, and auditable
- Workflow Execution - Runs in a private repository to protect tenant information
- Tenant Isolation - Tenant IDs are masked in logs and never visible in public workflow runs
- No Data Storage - IntuneGet does not store your application binaries or tenant credentials
- HMAC-SHA256 Verification - All callbacks are cryptographically signed
- Token Handling - Access tokens are never persisted and expire after use
- Rate Limiting - API endpoints are protected by rate limiting
- Role-Based Access Control - MSP features use granular permissions with four role levels (Owner, Admin, Operator, Viewer)
- All MSP operations are logged with IP address, user agent, and timestamp
- Dedicated log viewer for reviewing team and deployment activity
For organizations with strict compliance requirements:
- Run the local packager on your own Windows infrastructure
- Use self-hosted Supabase or SQLite
- No external network calls required
See SECURITY.md for our complete security policy.
| Category | Technology |
|---|---|
| Frontend | Next.js 14 with App Router |
| Language | TypeScript |
| UI Components | shadcn/ui |
| Styling | Tailwind CSS |
| Database | Supabase (PostgreSQL) |
| Authentication | MSAL (Microsoft Entra ID) |
| State Management | Zustand + TanStack Query |
| Animations | Framer Motion |
| Deployment | Vercel, Docker |
| Document | Description |
|---|---|
| Self-Hosting Guide | Complete guide for self-hosting IntuneGet |
| Azure AD Setup | Configure Microsoft Entra ID app registration |
| GitHub Actions Setup | Set up the packaging pipeline |
| Database Setup | Supabase configuration options |
| Development Guide | Local development setup |
| Environment Reference | Full env var matrix by deployment mode |
| API Reference | Endpoint overview by feature area |
| SCCM Migration Guide | SCCM import, matching, and migration flow |
| Updates and Policy Guide | Auto-update policies, triggers, and history |
| Inventory/Reports/Uploads Guide | Operational dashboard feature docs |
| Authentication Architecture | MSAL, admin consent, and service principal flow |
| Documentation Audit | Coverage and remaining documentation gaps |
| Capability | Traditional | IntuneGet |
|---|---|---|
| Curated app catalog | -- | Yes |
| One-click deployment | -- | Yes |
| Automated cloud packaging | -- | Yes |
| Pre-configured detection rules | -- | Yes |
| Direct deployment to tenant | -- | Yes |
| Multi-app batch deploy | -- | Yes |
| Multi-tenant batch deployment | -- | Yes |
| Role-based team management | -- | Yes |
| Community ratings and suggestions | -- | Yes |
| Webhook notifications | -- | Yes |
| Self-hosting support | -- | Yes |
Contributions are welcome. Please read CONTRIBUTING.md before submitting a pull request.
This project is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).
This license applies to all code in this repository, regardless of when it was committed.
- Self-host for internal business use
- Modify for personal or internal use
- Network service modifications must be open-sourced
Simplify your Intune deployments.
