Deployment

Was die Anwendung braucht

• PostgreSQL — der gesamte Zustand des Origin.
• Ein dauerhaftes Volume — für Installer, die Sie auf dem Origin ablegen.
• Etwas davor, das HTTPS terminiert. Die Anwendung selbst ist ein einfacher HTTP-Server auf Port 3000; sie kümmert sich nicht um TLS.

HTTPS ist nicht optional

winget verweigert eine REST-Quelle, die nicht über HTTPS mit einem vertrauenswürdigen Zertifikat läuft — bei neueren winget-Versionen auch für localhost. Eine interne CA ist in Ordnung, solange Ihre Clients ihr vertrauen; ein nicht vertrauenswürdiges selbstsigniertes Zertifikat nicht.

Der Reverse-Proxy

kvellman lauscht auf Port 3000 und spricht einfaches HTTP. Es terminiert kein TLS und kümmert sich nicht darum, was davor steht. Alles, was HTTPS terminieren und an ein HTTP-Upstream weiterleiten kann, funktioniert: nginx, HAProxy, Apache, eine Appliance, Ihr vorhandener Ingress.

Was auch immer Sie einsetzen, muss:

• an Port 3000 der Anwendung weiterleiten
• ein Zertifikat ausliefern, dem die Clients vertrauen
• Host und Protokoll des ursprünglichen Requests durchreichen (Host, X-Forwarded-Proto)
• Response-Bodies nicht puffern oder begrenzen — Installer sind groß
• lang laufende Downloads zulassen (großzügige Read-/Send-Timeouts)

Das ist die gesamte Integrationsfläche.

Beispiele im Detail

Ein Compose-Stack mit gebündeltem Proxy

Die Standard-docker-compose.yml bündelt Caddy, das automatisch ein Let's-Encrypt-Zertifikat bezieht. Nutzen Sie sie, wenn der Host öffentlich erreichbar ist und Sie noch keinen Proxy betreiben.

cp .env.deploy.example .env.deploy   # DOMAIN, NUXT_SESSION_PASSWORD, POSTGRES_PASSWORD setzen
docker compose --env-file .env.deploy up -d

Routing über einen vorhandenen Ingress

docker-compose.traefik.yml kommt ohne gebündelten Proxy — die Anwendung hängt sich in Ihr vorhandenes Traefik-Netz und wird per Labels geroutet. Nutzen Sie das, wenn Port 80/443 schon etwas anderem gehören.

docker compose -f docker-compose.traefik.yml --env-file .env.deploy up -d

Jeder andere Proxy

Der Anwendung ist es egal. Zeigen Sie einen beliebigen HTTPS-terminierenden Proxy auf Port 3000 — zum Beispiel nginx:

server {
  listen 443 ssl;
  server_name ihre-domain;
  location / {
    proxy_pass http://kvellman:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_request_buffering off;
    client_max_body_size 0;
  }
}

Konfiguration

Betrieb ohne die Compose-Dateien

Eigenes PostgreSQL und eigene Orchestrierung mitzubringen ist kein Problem: das Image starten, DATABASE_URL auf Ihre Datenbank zeigen lassen und Port 3000 Ihrem Proxy exponieren. Migrationen laufen beim Start automatisch — es gibt keinen separaten Migrationsschritt zu skripten.

Backups und Upgrades

Der gesamte Zustand einer Installation ist die PostgreSQL-Datenbank plus das Installer-Volume — sichern Sie beide. Ein Upgrade ist das Ziehen eines neueren Image-Tags und ein Neustart; Migrationen laufen beim Start.

Telemetrie

Standardmäßig aus, per Umgebungsvariable aktivierbar. Erfasst Suchen, Manifest-Abrufe und Installer-Downloads, stündlich innerhalb des Anwendungsprozesses selbst zusammengefasst, mit Löschung der Rohereignisse nach der von Ihnen konfigurierten Aufbewahrungsdauer. Für den Betrieb ist keine Queue, kein Cache und kein zusätzlicher Dienst nötig. Die zusammengefassten Zahlen erscheinen in der Admin-Oberfläche als Dashboards, aufgeschlüsselt nach Site und nach winget-Client-Version.

Air-Gap-Betrieb

Die Anwendung macht für den Betrieb keine ausgehenden Aufrufe, und die Lizenzprüfung ist vollständig lokal — sie läuft also vollständig getrennt vom Internet. Der Upstream-Katalog-Sync und der Manifest-Import von GitHub brauchen Internetzugang — lassen Sie CATALOG_SYNC_ENABLED aus und importieren Sie Manifeste von Hand, wenn der Host keinen hat.

Die vollständige Schritt-für-Schritt-Anleitung (Origin, Edge-Node unter WSL, TLS für LAN/localhost, Registry-Workflow) steht in DEPLOYMENT.md im Open-Core-Repository — diese Seite beschreibt die Grobform davon.