Orbit
Unterstützte Frameworks und Runtimes in Orbit
Orbit builds any project that installs with npm, yarn or pnpm and produces a folder of files or a Node.js server, and it detects the framework and package manager for you so most projects deploy…
Orbit baut jedes Projekt auf, das sich mit npm, yarn oder pnpm installiert und einen Ordner mit Dateien oder einen Node.js-Server erzeugt. Orbit erkennt das Framework und den Paketmanager automatisch, daher benötigen die meisten Projekte überhaupt keine Build-Konfiguration. In diesem Leitfaden erfahren Sie, was erkannt wird, welche Einstellungen die einzelnen gängigen Frameworks benötigen, wann Sie den Server-Modus aktivieren müssen und wie Sie eine Node.js-Version auswählen.
Was Orbit Automatisch Erkennt
Wenn ein Build ausgeführt wird, erfasst Orbit das Gefundene und zeigt es Ihnen an:
- Framework, auf der Deployment-Detailseite und als Badge auf Deployment-Karten auf der Projektübersicht.
- Paketmanager, ausgewählt aus Ihrer Lockdatei:
package-lock.jsonergibt npm,yarn.lockergibt yarn,pnpm-lock.yamlergibt pnpm.
Die Build-Einstellungen unter Settings sind alle optional. Lassen Sie ein Feld leer, und der Platzhalter teilt Ihnen mit, was stattdessen verwendet wird: Install command zeigt npm ci (auto-detected), Build command zeigt npm run build (auto-detected) und Output directory zeigt dist (auto-detected).
Committen Sie genau eine Lockdatei. Wenn sowohl package-lock.json als auch yarn.lock im Repository sind, ist der Paketmanager, den Orbit wählt, möglicherweise nicht derjenige, den Sie lokal verwenden, und Sie erhalten eine Installation, die sich ohne erkennbaren Grund anders verhält als auf Ihrem Computer. Löschen Sie die Datei, die Sie nicht verwenden.
Einstellungen Nach Framework
Dies sind die Werte, die jedes Framework benötigt. Wenn Orbit eine Starter-Vorlage für das Framework bereitstellt, verwendet die Vorlage genau diese Einstellungen.
| Framework | Build-Befehl | Output-Verzeichnis | Server-Modus |
|---|---|---|---|
| Next.js, statischer Export | npm run build | out | Aus |
| Next.js, SSR oder ISR | npm run build | .next | An |
| Astro, statisch | astro build | dist | Aus |
| Astro, Server oder Hybrid | astro build | dist | An |
| Vite (React, Vue, Svelte) | npm run build | dist | Aus |
| SvelteKit | npm run build | build | Abhängig vom Adapter |
| Nuxt 3 | npm run build | .output | An |
| Remix | npm run build | build | An |
| Express oder eine einfache Node API | npm run build | dist | An |
| Create React App | npm run build | build | Aus |
| Reines HTML oder ein statischer Generator | leer lassen oder Befehl des Generators | . oder der Ordner, in den er schreibt | Aus |
Vite schreibt immer in dist, außer wenn Sie build.outDir in vite.config.ts gesetzt haben. Der Output-Ordner von Astro ist dist in jedem Modus. Was sich zwischen den Modi ändert, ist nicht, wohin die Dateien gehen, sondern ob Sie den Server-Modus benötigen.
Server-Modus
Server-Modus ist ein Schalter unter Settings, unter Runtime. Wenn er aktiviert ist, behält Orbit die Build-Maschine am Laufen npm start nach jedem Deploy bei, anstatt einen Ordner mit statischen Dateien zu bedienen.
Aktivieren Sie ihn für Next.js mit SSR, Remix, Nuxt, eine Express API und alles andere, das kein statischer Export ist. Lassen Sie ihn aus, wenn Sie wirklich einen statischen Build haben.
Er gilt ab dem nächsten Deploy, nicht für das Deployment, das gerade live ist.
Das klassische Symptom für einen fehlenden Server-Modus ist eine Website, auf der die Startseite perfekt geladen wird und jede dynamische Route einen 404-Fehler zurückgibt. Der Build war erfolgreich, die Dateien wurden veröffentlicht, und es läuft einfach kein Server, um die Routen zu beantworten. Wenn das der Fall ist, aktivieren Sie den Server-Modus, stellen Sie erneut bereit und ändern Sie nichts anderes, bevor Sie das tun.
Node.js-Version
Legen Sie Node.js version unter Settings unter Build settings fest. Geben Sie nur die Hauptversionsnummer ein: 18, 20 oder 22. Lassen Sie es leer, um die Plattformstandard zu verwenden.
Die Version gilt sowohl für den Build als auch, wenn der Server-Modus aktiviert ist, für die Laufzeit.
Legen Sie die Version explizit fest, anstatt sich auf die Standardeinstellung zu verlassen. Eine Abhängigkeit, die eine neuere Node-Version als die Standardeinstellung erfordert, schlägt die Installation mit einem Fehler fehl, der das nicht offensichtlich sagt, und das Festlegen entfernt eine ganze Klasse von "es funktionierte gestern" Build-Ausfällen.
Monorepos
Legen Sie Root directory auf das Unterverzeichnis fest, das die App enthält, beispielsweise apps/web. Orbit wechselt in dieses Verzeichnis, bevor es Ihre Install- und Build-Befehle ausführt.
Es tut auch etwas, das Sie mögen, aber möglicherweise nicht erwarten: Pushes, die nur Dateien außerhalb dieses Pfads ändern, werden automatisch übersprungen. Ein Monorepo mit vier Orbit-Projekten erstellt daher nur die Apps neu, die ein Commit tatsächlich berührt hat.
Jede Umgebung kann das Root-Verzeichnis separat überschreiben, unter Staging: build overrides unter Settings, was nützlich ist, wenn Staging einen anderen Workspace erstellt.
Benutzerdefinierte Build-Einstellungen
Überschreiben Sie alles unter Settings, unter Build settings:
| Feld | Beispiel | Hinweise |
|---|---|---|
| Install command | npm ci | Oder yarn install --frozen-lockfile, pnpm install --frozen-lockfile |
| Build command | npm run build:prod | Genau wie geschrieben ausführen |
| Output directory | dist/client | Der Ordner, der nach dem Build veröffentlicht wird |
| Root directory | apps/frontend | Monorepo-Unterverzeichnis |
| Node.js version | 20 | Nur Hauptversion |
Leer bedeutet automatische Erkennung. Klicken Sie auf Save auf der Build settings-Karte, um zu speichern.
Staging kann jeden dieser Werte unabhängig überschreiben, in der Sektion Staging: build overrides. Ein Feld, das dort leer gelassen wird, erbt den Wert auf Projektebene, sodass Sie nur den Build-Befehl für Staging ändern und alles andere so lassen können.
Build-Cache
Orbit zwischenspeichert node_modules zwischen Builds auf den Liftoff- und Apex-Plänen. Wenn der Cache verwendet wird, zeigt das Deployment ein Badge Cache hit an und die Install-Phase ist viel kürzer. Ein Build ohne Cache zeigt Cold build.
Um eine vollständige Neuinstallation zu erzwingen, öffnen Sie Settings, dann Clear build cache und bestätigen Sie. Die nächste Bereitstellung für jede Umgebung führt eine vollständige Installation von Grund auf durch. Dies kann nicht rückgängig gemacht werden, und der darauffolgende Build wird langsam sein.
Build-Maschinenressourcen
Die Größe der Build-Maschine hängt von Ihrem Plan ab, was für große Builds wichtig ist:
| Plan | vCPU | RAM | Disk | Zeitlimit |
|---|---|---|---|---|
| Launch | 1 | 1 GB | 4 GB | 30 Minuten |
| Liftoff | 2 | 2 GB | 8 GB | 30 Minuten |
| Apex | 4 | 4 GB | 16 GB | 30 Minuten |
Ein Build, dem der Arbeitsspeicher ausgeht oder dessen Disk vollläuft, schlägt fehl, wobei diese Fehlerkategorie auf der Deployment-Seite benannt wird. Das Erhöhen von NODE_OPTIONS=--max-old-space-size hilft nur bis zum tatsächlichen RAM der Maschine.
Vom Template Starten
Wenn Sie ein funktionierendes Deployment haben möchten, bevor Sie ein Repository haben, verwenden Sie eine Starter-Vorlage. Unter New project wechseln Sie von Import Git Repo zu Start from Template und wählen eines aus: Next.js mit shadcn/ui, eine Astro-Marketing-Website, den Remix Indie Stack, einen SvelteKit-Starter, eine minimale Nuxt 3-App oder eine Express REST API. Orbit kopiert die Vorlage, wendet die richtigen Build-Einstellungen an und stellt sie bereit.
Weiterführende Ressourcen
- Konfigurieren von Build-Befehl und Output-Verzeichnis für die Framework-spezifischen Details und häufige Fehler
- Behebung fehlgeschlagener Builds
- Orbit-Plan-Limits