Software Development
Next.js Standalone für Azure App Service vorbereiten
Wie dieses Repository Build, Standalone-Artefakt und Azure-Source-Deployment voneinander trennt.
In DevelopmentOpen in signal graph →- Category
- Software Development
- Difficulty
- Intermediate
- Reading time
- 5 min
- Updated
- TODO
Zwei Deployment-Verträge, ein Build
Dieses Repository erzeugt mit next build eine Next.js-Anwendung und aktiviert in next.config.ts den Modus output: "standalone". Next.js schreibt dadurch einen minimalen Server nach .next/standalone/server.js und nimmt nur die für den Serverbetrieb ermittelten Dateien und Abhängigkeiten auf.
Das Standalone-Verzeichnis ist ein lokales Prüfartefakt. Der geplante Azure-Pfad bleibt ein Source-Deployment: Azure Developer CLI übergibt den Quellstand an App Service, dort führt Oryx Installation und Build aus. Ein Azure-Deployment wurde zum Veröffentlichungszeitpunkt dieses Artikels noch nicht ausgeführt.
Statische Dateien ergänzen
Next.js kopiert public/ und .next/static nicht automatisch in das Standalone-Verzeichnis. Deshalb läuft nach jedem Build scripts/prepare-standalone.mjs. Das Skript prüft die benötigten Verzeichnisse, ersetzt alte Kopien und erzeugt diese Struktur:
.next/standalone/
public/
.next/static/
server.js
Der lokale Produktionsstart verwendet danach:
npm run build
npm start
npm start startet in diesem Repository ausdrücklich .next/standalone/server.js. Der generierte Server berücksichtigt die von App Service gesetzte Variable PORT.
Azure-Konfiguration
Die deklarierte Zielruntime ist Node.js 24 LTS auf Azure App Service Linux. Der Bicep-Vertrag setzt NODE|24-lts, behält den B1-Plan bei und verwendet npm start als Startkommando. Für den Build aus der Quelle sind SCM_DO_BUILD_DURING_DEPLOYMENT und ENABLE_ORYX_BUILD aktiviert.
Zur Betriebsdiagnose beschreibt die Infrastruktur zusätzlich:
- einen Health Check auf
/api/health, - eine user-assigned Managed Identity,
- workspace-basiertes Application Insights,
- App-Service-Logs und Metriken über Diagnostic Settings.
Diese Ressourcenbeschreibung ist lokal kompiliert. Ob sie bestehende Azure-Ressourcen unverändert wiederverwendet, muss vor jeder Bereitstellung mit bestätigtem Subscription-Kontext, ARM-Validierung und What-if geprüft werden.
Reproduzierbare Prüfung
Der Befehl npm run verify führt Typprüfung, ESLint, Tests und Produktions-Build nacheinander aus. Damit werden Anwendungslogik und Standalone-Artefakt gemeinsam geprüft. Die Azure-Prüfung bleibt davon getrennt: Ein grüner lokaler Build ist notwendig, aber kein Nachweis für eine erfolgreiche Bereitstellung.
Diese Trennung hält drei Aussagen auseinander:
- Der Quellcode ist typisiert und getestet.
- Das lokale Standalone-Artefakt kann erzeugt werden.
- Die Azure-Ressourcen und das Deployment sind erst nach eigener Validierung freigegeben.