Architecture

winget Source API

kvellman implements the winget Source REST contract exactly, so the winget CLI treats it like any other source:

• GET /api/{siteToken}/information — source metadata and supported versions.
• POST /api/{siteToken}/manifestSearch — full-text search.
• GET /api/{siteToken}/packageManifests/{id} — manifest delivery with server-side resolution.

Site context

winget sends no custom headers, so site context is carried in the URL site token (primary), with subnet and mTLS client certificate as additional signals. The resolved context drives server-side InstallerUrl placeholders ($REPO_URL, $SITE, $LOCATION, $LANG) — so the same manifest can point at a site-local SMB/DFS share without being forked.

Manifests, overlays & storage

Manifests are versioned YAML, validated against the official winget JSON schemas on upload. Local edits are kept as an overlay on top of the untouched upstream, and per-package overlay templates make repeatable edits (e.g. an internal mirror URL with $VERSION/$ARCH) easy across versions. Installers can be mirrored to S3/MinIO or SMB; hashes are recomputed on delivery.

Edge / mirror nodes

Edge nodes are thin caching proxies that serve the winget API + downloads locally and lazily fetch from the origin. They keep an offline search index, enroll via mTLS, and are centrally scoped (which packages, which installer architectures/scopes) and observable from the origin.

Stack

Nuxt 4 (Vue 3 + Nitro), TypeScript, PostgreSQL + Drizzle ORM, S3-compatible storage, BullMQ/Redis for background jobs. On-premise only — fully self-hostable, including air-gapped operation.