Architecture

Request path

A winget client talks HTTPS to your reverse proxy, which forwards plain HTTP to the origin. The origin reads and writes PostgreSQL and, for installers stored on it, its own storage volume.

• 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 placeholder resolution.

Only approved versions are ever returned.

Data model

Packages, versions and manifests are stored relationally, in shapes that mirror winget's own manifest schema, alongside the untouched upstream snapshot and any overlay on top. Sites, edge nodes, users, the audit log and telemetry events live in the same database. One database is the entire state of an installation, plus the installer volume.

Installer delivery

Installers stored on the origin are served from its own volume at /dl/..., with the SHA-256 recomputed on every delivery.

Node control plane

The origin enrolls, scopes and monitors edge nodes; it doesn't run the node itself. See Edge nodes.

Extension model

Authentication providers register through a plugin host and are gated on entitlements read from the license token — a plugin only activates once the matching entitlement is present. @kvellman/plugin-sdk is the public type surface for building against it.

Stack

Nuxt 4 (Vue 3 + Nitro), TypeScript, PostgreSQL with Drizzle ORM, Zod and the official winget JSON schemas (via ajv) for manifest validation, Nuxt UI, English and German interface. On-premise only — self-hostable including air-gapped operation.

Scope of an installation

One application process handles requests, installer delivery, and scheduled work (telemetry rollup, catalog sync). Installers live on a local volume or are referenced by URL. Accounts are local to the installation in the core edition. An installation's components are the application container and a database.