For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /de/docs/desktop/updates.md (or send Accept: text/markdown).

Auto-Updates und Release-Kanäle

Signierte Update-Feeds, der stable/beta-Kanal und der mitgelieferte Release-Workflow.

Zu dieser Anleitung fragen

Das Updater-Schlüsselpaar einmal erzeugen

Der Updater verifiziert minisign-Signaturen auf heruntergeladenen Artefakten. Erzeugen Sie ein Schlüsselpaar mit dem Tauri-Signer und bewahren Sie den privaten Schlüssel als TAURI_SIGNING_PRIVATE_KEY mit seinem Passwort in TAURI_SIGNING_PRIVATE_KEY_PASSWORD auf — beide in Ihrem Secret Store, nie im Repository. Builds, die Updater-Artefakte erzeugen, legen eine .sig-Sidecar neben jeden Installer; der öffentliche Schlüssel geht an die Clients, der private bleibt in der CI.

corepack pnpm --filter @supastack/desktop exec tauri signer generate -w ~/.tauri/product.key

Den Updater zur Build-Zeit konfigurieren

tauri.conf.json liefert einen Sentinel-Updater-Block mit leeren endpoints und pubkey — behalten Sie ihn, denn das Updater-Plugin kann ohne vorhandene Schlüssel nicht initialisieren. Echte Werte werden zur Build-Zeit über ein --config-JSON-Overlay oder die Umgebungsvariable TAURI_CONFIG tiefengemergt; check:release-config gibt das exakte Overlay zum Einfügen aus, wenn SUPASTACK_UPDATER_ENDPOINT und SUPASTACK_UPDATER_PUBKEY gesetzt sind.

Setzen Sie beide oder keins: Ein Overlay nur mit endpoints lässt pubkey leer — die Prüfungen scheinen dann zu funktionieren, während jede Installation an der Signaturprüfung scheitert. Die Endpunkt-URL trägt die Platzhalter {{target}}, {{arch}} und {{current_version}} — der Versionsslot ist Pflicht — plus ein optionales {{channel}}-Pfadsegment, das Release-Kanäle aktiviert.

# check:release-config prints this overlay for tauri build --config:
# {"plugins":{"updater":{"endpoints":["https://releases.example.com/{{channel}}/{{target}}/{{arch}}/{{current_version}}"],"pubkey":"<base64 public key>"}}}
# SUPASTACK_UPDATER_ENDPOINT=
# SUPASTACK_UPDATER_PUBKEY=

Den latest.json-Feed veröffentlichen

Jeder Endpunkt beantwortet ein latest.json-Manifest — version, notes, pub_date und eine platforms-Map über darwin-aarch64, darwin-x86_64, windows-x86_64, windows-aarch64, linux-x86_64 und linux-aarch64 —, in der jeder Eintrag die Installer-URL mit ihrer signature paart.

Bauen Sie es mit dem Skript release:manifest: Es durchsucht ein Bundle-Verzeichnis nach .app.tar.gz-, -setup.exe- (bevorzugt vor .msi) und .AppImage-Artefakten — jedes braucht seinen .sig-Nachbarn — und schreibt oder mergt das Manifest. Flags decken --version, --base-url, --bundle-dir mit --platform, --merge zum Sammeln der Plattformen über Läufe hinweg, --notes, --pub-date und --out ab.

corepack pnpm --filter @supastack/desktop release:manifest -- \
  --version 1.2.0 \
  --base-url https://releases.example.com/stable \
  --bundle-dir src-tauri/target/release/bundle \
  --platform windows-x86_64 \
  --merge latest.json

Stable- und Beta-Kanäle

Enthält ein Endpunkt den Platzhalter {{channel}}, aktiviert das App-Menü eine Beta Updates-Checkbox, die den Feed zwischen stable und beta umschaltet. Die Wahl bleibt in einer update-channel-Datei neben der App-Konfiguration erhalten; SUPASTACK_UPDATE_CHANNEL überschreibt sie pro Lauf — alles Unerkannte wird mit einer Warnung ignoriert —, und stable ist der Standard. Ohne Platzhalter bleibt der Schalter deaktiviert, und nur der stable-Feed wird geprüft.

Wann Updates geprüft werden

Beim Start läuft eine stille Hintergrundprüfung, die nur dann einen Dialog zeigt, wenn ein Update existiert; der Menüeintrag Check for Updates… meldet jedes Ergebnis. Prüfungen werden serialisiert — eine zweite gleichzeitige Anfrage wird verworfen. Ein verfügbares Update bietet Install and Restart, das die App herunterlädt, installiert und neu startet; nicht konfigurierte Builds antworten mit „Updates aren't configured for this build.“, und Fehler erscheinen als Dialoge statt als Wiederholungen.

Der mitgelieferte Release-Workflow

.github/workflows/desktop-release.yml baut die Matrix — macOS auf beiden Architekturen, Windows und Ubuntu — bei desktop-v*-Tags oder einem manuellen Dispatch mit Version und Kanal. Es prägt die Manifest-Version aus dem Tag (ein Release, das dies überspringt, bietet sich für immer selbst als Update an), mergt die Manifeste pro Plattform und erstellt einen GitHub-Release-Entwurf mit latest.json plus jedem Installer und jeder Signatur — für Beta-Kanäle als Prerelease markiert.

Es braucht SUPASTACK_APP_URL und SUPASTACK_UPDATER_ENDPOINT als Repository-Variablen sowie SUPASTACK_UPDATER_PUBKEY plus den privaten Signierschlüssel und sein Passwort als Secrets; Apple-Signierdaten sind optionale Ergänzungen. Das vollständige Runbook liegt im Repository unter docs/desktop-updates.md.

Überprüfung und Fehlerbehebung

Installieren Sie einen Build, veröffentlichen Sie ein neueres Manifest in einem Test-Feed und bestätigen Sie, dass der Update-Dialog bei der nächsten Prüfung erscheint und die App in die neue Version neu startet. Wechseln Sie dann auf beta und bestätigen Sie, dass sich die Antwort des Kanal-Feeds ändert.