Troubleshooting
Solutions to common issues and frequently asked questions about self-hosting IntuneGet.
Quick Diagnosis
Start by checking the health endpoint to identify which components are working:
curl https://your-app.vercel.app/api/healthExpected response:
{
"status": "healthy",
"mode": "self-hosted",
"services": {
"database": true,
"auth": true,
"pipeline": true
}
}If any service shows false, focus troubleshooting on that component.
Common Error Messages
Authentication Errors
AADSTS50011: The reply URL specified in the request does not match
The redirect URI in your request doesn't match the configured URIs.
Solution:
- Go to Azure Portal > Your App Registration > Authentication
- Verify your URL is listed (e.g.,
https://your-app.vercel.app) - Ensure it's added as a SPA redirect, not Web
- Check for trailing slashes - they must match exactly
AADSTS65001: The user or administrator has not consented
Admin consent has not been granted for your tenant.
Solution:
- Contact your Global Administrator
- Have them visit:
https://login.microsoftonline.com/YOUR_TENANT/adminconsent?client_id=YOUR_CLIENT_ID - They must click Accept on the consent screen
AADSTS700016: Application with identifier was not found
The client ID is incorrect or the app was deleted.
Solution:
- Verify NEXT_PUBLIC_AZURE_AD_CLIENT_ID is correct
- Check the app still exists in Entra ID
- Compare the ID in your .env with the Overview page in Azure
Database & Packager Errors
Database not found / SQLite error
The SQLite database file cannot be accessed or created.
Solution:
- Verify DATABASE_MODE is set to "sqlite"
- Check DATABASE_PATH points to a writable location (default: ./data/intuneget.db)
- Ensure the /data directory exists and has write permissions
- For Docker: verify the volume mount is configured correctly
Packager API key invalid / Connection refused
The local packager cannot authenticate or connect to the web app.
Solution:
- Verify PACKAGER_MODE is set to "local"
- Check PACKAGER_API_KEY matches between the web app and the packager service
- Ensure the packager Windows machine can reach your web app URL
- Verify NEXT_PUBLIC_URL is correct and accessible
Unmanaged Apps Errors
Permission error on Unmanaged Apps page
Missing DeviceManagementManagedDevices.Read.All permission.
Solution:
- Go to Settings > Permissions tab and run "Check Permissions"
- If the DeviceManagementManagedDevices.Read.All permission shows as missing, have a Global Administrator re-grant admin consent
- Add the permission in Azure Portal > App Registration > API Permissions if it is not listed
Webhook delivery failed
Webhook notifications are not being received by the target endpoint.
Solution:
- Verify the webhook URL is correct and publicly accessible
- Check the webhook delivery logs in Settings > Notifications
- Ensure the endpoint accepts POST requests with JSON payloads
- For Slack/Teams/Discord, verify the incoming webhook URL has not been revoked
Pipeline Errors
Workflow not triggering
Deployments get stuck in "pending" status.
Solution:
- Verify GITHUB_PAT has repo and workflow scopes
- Check workflows are enabled in your fork's Actions tab
- Verify GITHUB_OWNER and GITHUB_REPO match your fork
- Check the PAT hasn't expired
Callback verification failed
Pipeline completes but status doesn't update.
Solution:
- Verify CALLBACK_SECRET matches in both GitHub Secrets and .env
- Check NEXT_PUBLIC_URL is accessible from the internet
- Look at the workflow run logs in GitHub Actions
IntuneWinAppUtil failed
Packaging fails for specific apps.
Solution:
- Check the app exists in Winget: winget show {app-id}
- Verify the app has a supported installer type
- Check workflow logs for specific error messages
- Some apps may not be compatible with IntuneWinAppUtil
Debugging Tips
Check Logs
Vercel: Dashboard > Your Project > Logs
Docker: docker-compose logs -f
Browser Console
Press F12 and check the Console and Network tabs for errors and failed requests.
GitHub Actions
Check your fork's Actions tab for workflow run details and error messages.
Environment Check
Verify all environment variables are set. Missing or incorrect values cause most issues.
Environment Variable Checklist
Verify each variable is set correctly:
| Variable | Check |
|---|---|
DATABASE_MODE | Set to "sqlite" for self-hosted deployments |
DATABASE_PATH | Path to SQLite file (default: ./data/intuneget.db) |
PACKAGER_MODE | Set to "local" for the local packager service |
PACKAGER_API_KEY | Shared secret between web app and packager service |
NEXT_PUBLIC_AZURE_AD_CLIENT_ID | UUID format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
AZURE_CLIENT_SECRET | Should not be expired, contains ~ |
NEXT_PUBLIC_URL | Full URL with https://, no trailing slash |
Frequently Asked Questions
The complete setup typically takes 1-2 hours if you follow the guide step by step. Most of this time is spent on Entra ID configuration. The actual deployment with Docker takes only a few minutes.
Yes! IntuneGet is free and open source under the AGPL-3.0 license. The self-hosted version uses SQLite (embedded, no external service needed) and runs in Docker. There are no external database costs. If you use GitHub Actions for packaging (optional), private repos may incur costs after 2,000 minutes/month.
You need permission to create app registrations, which is often available to all users by default. However, a Global Administrator is needed to grant admin consent for the application permissions that allow uploading to Intune.
The self-hosted version uses SQLite by default, which requires zero configuration. The hosted version (intuneget.com) uses a different backend. For self-hosting, SQLite is recommended as it provides simple backups (just copy the file) and no external dependencies.
Pull the latest changes from your upstream remote (git fetch upstream && git merge upstream/main), then redeploy. For Docker: docker-compose down && docker-compose build --no-cache && docker-compose up -d. Check release notes for any required migrations.
Yes! IntuneGet is designed as a multi-tenant application. Users from different Microsoft 365 organizations can sign in and deploy apps to their respective Intune tenants, as long as their admin has granted consent. The MSP features provide additional multi-tenant management capabilities.
Currently, IntuneGet only supports apps available in the Winget repository. You can use the Unmanaged Apps feature to discover applications on your devices and manually link them to Winget packages if a match exists. Custom app support is on the roadmap for future releases.
Unmanaged apps are applications discovered on your Intune-managed devices that are not yet deployed through Intune. IntuneGet detects these apps, matches them against the Winget repository, and lets you claim them for deployment. This requires the DeviceManagementManagedDevices.Read.All permission.
The MSP (Managed Service Provider) features allow you to manage multiple client tenants from a single dashboard. You can batch-deploy applications across tenants, manage team access with roles, configure webhooks for deployment notifications, view audit logs, and generate cross-tenant reports.
IntuneGet supports email notifications (real-time, daily digest, or critical-only) and webhooks for Slack, Microsoft Teams, Discord, or custom HTTP endpoints. Webhooks are signed with HMAC for security. Configure both in the Settings page under the Notifications tab.
Getting Help
Before Opening an Issue
- Search existing issues for similar problems
- Include your deployment method (Vercel, Docker, etc.)
- Share relevant error messages (redact sensitive info)
- Describe what you expected vs. what happened
Still Need Help?
Review the detailed setup guides for each component: