Nuxt auf Nodion deployen

Nuxt Schritt für Schritt deployen

1. Standard-Skripte und Lockfile behalten Committe dein Lockfile; ohne Lockfile scheitert der Build. Nuxt-Projekte haben kein start-Skript, und du brauchst auch keins: Nodion führt dein build-Skript aus und startet danach .output/server/index.mjs, das auf dem PORT lauscht, den Nodion setzt. Legst du ein start-Skript an, nimmt Nodion stattdessen dieses. package.json

   "scripts": {
     "build": "nuxt build",
     "dev": "nuxt dev"
   }

2. App anlegen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an, wähle Branch und Region EU Central und lass die Build-Strategie auf Buildpacks.
3. Mit NUXT_-Variablen konfigurieren Deklariere deine Einstellungen in runtimeConfig und setz sie auf dem Tab Environment als NUXT_API_SECRET oder NUXT_PUBLIC_API_BASE. Nuxt liest sie beim Start des Servers, sie brauchen also kein Häkchen Build. Das brauchen nur Werte, die nuxt.config während des Builds aus process.env liest. nuxt.config.ts

   export default defineNuxtConfig({
     runtimeConfig: {
       apiSecret: "",
       public: {
         apiBase: "",
       },
     },
   });

4. Pushen und deployen Jeder Push auf den Branch baut ein neues Release. Der Traffic wechselt, sobald / mit 2xx oder 3xx antwortet. Antwortet / mit 401 oder 404, leg eine Server-Route wie server/routes/health.ts an und trag in den App-Einstellungen /health als Health-Check-Pfad ein.

Gut zu wissen

• Statische Site mit nuxt generatenuxt generate erkennt Nodion nicht von selbst und startet weiter den Server. Für eine statische Site machst du nuxt generate zu deinem build-Skript und legst eine static.toml mit output-dir = ".output/public" an. Nodion liefert diesen Ordner dann über einen statischen Webserver mit index.html-Fallback aus, die kleinste Größe reicht.
• Nitro-PresetNodion startet .output/server/index.mjs, das Nitros Standard-Preset node-server schreibt. Wählt nuxt.config oder NITRO_PRESET ein Preset für einen anderen Hoster, entfern es.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Preview-Environments erklärt: eine App pro Pull Request Eine laufende Kopie deiner App für jeden Pull Request: wofür Preview-Environments gut sind, wo es knifflig wird und wie Nodion sie handhabt.
• Cloud Native Buildpacks erklärt Buildpacks machen aus deinem Quellcode ein Container-Image ohne Dockerfile. Was sie sind und wie sie funktionieren.

Nuxt auf Nodion: Fragen und Antworten