Deployment-Leitfaden

Produktion benötigt PostgreSQL, einen stabilen öffentlichen Ursprung, ein Auth-Secret und Zugangsdaten der gewählten Anbieter. NEXT_PUBLIC_*-Werte werden in Browser-Bundles eingebaut; ihre Änderung verlangt einen neuen Build und eine Bereitstellung.

Server oder Container

Vom Repository-Stamm aus:

bun install --frozen-lockfile
bun run db:generate
bun run --cwd packages/database db:migrate
bun run build
bun run --cwd apps/web start

Setzen Sie vorher DATABASE_URL, BETTER_AUTH_SECRET, NEXT_PUBLIC_SITE_URL und die gewählten Anbieterzugangsdaten in der Bereitstellungsumgebung. Verwenden Sie geprüfte Migrationen gegen die beabsichtigte Datenbank. Schemaänderungen müssen während eines rollenden Deployments zu alter und neuer Appversion passen; eine angewendete Migration allein garantiert keine Ausfallfreiheit.

Das eingecheckte Dockerfile besitzt getrennte Build-, Migrations-, Operations- und Web-Runner-Stufen. docker-compose.yml kann den lokalen Gesamtstack mit dem Profil app starten; sein Dienst operations startet nach den Migrationen. Beispielzugangsdaten und MOCK_SERVICES=true dienen aber der lokalen Entwicklung.

Vertrauenswürdiger Edge-Proxy und Readiness

Lassen Sie TRUST_PROXY_HEADERS leer, außer die Anwendung ist nur über einen Edge-Proxy erreichbar, der die verifizierte Client-IP an X-Forwarded-For anhängt. Bei aktivierter Einstellung nutzt VibeKit die letzte gültige IP dieses Headers für Netzwerk-Rate-Limits. Ein Proxy, der vom Client gelieferte Werte weiterleitet, oder ein offener Anwendungsport lässt Clients den Bucket beeinflussen und darf diese Einstellung nicht verwenden.

/api/health/live prüft, ob der Prozess antwortet, und /api/health/ready prüft notwendige Konfiguration, Datenbankerreichbarkeit und Migrationsstand. In Produktion ohne MOCK_SERVICES=true verlangt Readiness außerdem einen höchstens zwei Minuten alten Worker-Heartbeat und einen höchstens zwei Stunden alten Scheduler-Heartbeat. MOCK_SERVICES=true umgeht diese Operations-Prüfungen ausdrücklich für die lokale Sandbox; damit ist kein Produktions-Worker nachgewiesen. Readiness testet bewusst keine kostenpflichtigen Anbieter. Konfigurieren Sie Monitoring und prüfen Sie den vollständigen Ablauf jedes aktivierten Anbieters auf der finalen Domain, statt einen grünen Health-Endpunkt als Anbieterbeleg zu behandeln.

Verwaltetes Hosting

Konfigurieren Sie ein Monorepo-fähiges Next.js-Projekt mit apps/web als Anwendung und Zugriff auf die Workspace-Abhängigkeiten im Stamm. Führen Sie Repository-Build und Datenbankgenerierung aus und prüfen Sie die Auslieferung von apps/web/.next. Anbieter unterscheiden sich bei Stamm- und Ausgabeeinstellungen; das Repository liefert keine universelle Vercel-Deployment-Konfiguration.

Führen Sie Migrationen in einem expliziten Bereitstellungsschritt aus, konfigurieren Sie OAuth-Callbacks und Webhook-URLs für den endgültigen Ursprung und prüfen Sie danach Anmeldung, geschützte Seiten und echte Anbieterabläufe. Ein erfolgreicher Build belegt keine Live-Integrationen. Scheduler, Backups, Alarmempfänger und Job-Ausführung des gewählten Hosts benötigen weiterhin Konfiguration und einen Nachweis auf der finalen Domain.

Dauerhafter Worker und Wartung

Der Webprozess verarbeitet die dauerhafte Job-Warteschlange nicht. Konfigurieren Sie den gewählten Host für einen überwachten Prozess bun scripts/ops-worker.mjs --schedule. Er verarbeitet Jobs, plant die stündliche Wartung über deterministische UTC-Schlüssel und schreibt den Readiness-Heartbeat. Das Repository-Dokument docs/OPERATIONS.md führt die aktuellen Handler, die getrennten Zustände für Warteschlange, Anbieter und Postfach bei Einladungs-E-Mails, das Warten bei Löschungen und die noch erforderlichen Produktionsnachweise auf. Ein lokal gestarteter Worker oder Container beweist nicht, dass der finale Host ihn ausführt.

Siehe Konfiguration und Datenbank-Migrationen.