Blog · Deploy-Anleitungen

So deployst du eine Nuxt-App 2026: ein Befehl, ein Node-Server und HTTPS

Vom Pethost-Team · 10. Oktober 2026 · Aktualisiert 25. Oktober 2026 · 8 Min. Lesezeit

Du hast eine Nuxt-App, die mit npm run dev läuft, und willst sie unter einer Adresse mit HTTPS online haben, gerendert auf dem Server. Bei Pethost ist das ein Befehl, pethost deploy, ausgeführt im Ordner mit der package.json. Er schreibt das Dockerfile für dich, führt nuxt build aus und startet den Server, den der Build geschrieben hat. Der Starter von Nuxt war beim ersten Mal in 53 s gebaut und gestartet.

Was du brauchst, um eine Nuxt-App 2026 zu deployen

Drei Dinge: die App, den Befehl pethost und ein Pethost-Konto.

Die App ist hier das, was die Installationsseite von Nuxt hinterlässt, mit dem Template „minimal“ und npm:

npm create nuxt@latest nuxt-app

Er schreibt die nuxt.config.ts, den Ordner app/ und eine package.json mit diesen Skripten. Keins davon ist ein Start-Skript, und es wird auch keins gebraucht:

"scripts": {
  "build": "nuxt build",
  "dev": "nuxt dev",
  "generate": "nuxt generate",
  "preview": "nuxt preview",
  "postinstall": "nuxt prepare"
}

Der Befehl ist ein Programm, installiert mit einer Zeile. Jeden seiner Befehle findest du in der Referenz der CLI.

curl -fsSL https://pethost.dev/install.sh | sh      # macOS, Linux
irm https://pethost.dev/install.ps1 | iex           # Windows, in PowerShell

Das Konto braucht einen Tarif. Wenn du nicht angemeldet bist, öffnet pethost deploy deinen Browser und meldet dich an. Wenn du noch keinen Tarif hast, zeigt er dir, wo du einen wählst, und wartet.

Die Nuxt-App mit einem Befehl deployen

Geh in den Ordner mit der package.json und führ pethost deploy aus. Das ist der ganze Bildschirm, für den Starter:

$ cd nuxt-app
$ pethost deploy
Name it [nuxt-app]:    it will live at https://nuxt-app.sam.pethost.app
✓ Packed 45 files, 450 KB   (left out node_modules)
✓ Uploaded straight to your machine
✗ /compose.yaml: the project directory has no compose.yaml at its root: add one
✓ Nuxt project detected, wrote Dockerfile.
✓ Packed 46 files, 451 KB   (left out node_modules)
✓ Uploaded straight to your machine
✓ Built and started in 53 s
  · wrote compose.yaml for the Dockerfile: the service app, reading .env
✓ app listens on 3000 → https://nuxt-app.sam.pethost.app
  It answers 200.

https://nuxt-app.sam.pethost.app

Wrote .pethost (commit it). Next:   pethost logs -f   ·   pethost open

1. Er fragt eine Sache Den Namen des Projekts, das erste Wort seiner Adresse. Enter übernimmt den Namen des Ordners.
2. Die Maschine findet nichts zum Ausführen Der Ordner geht direkt auf deine Maschine, ohne node_modules. Die Zeile mit dem Kreuz ist ihre Antwort: Ein Projekt läuft aus einem Dockerfile oder einer Compose-Datei, und der Ordner hat noch keins von beiden.
3. pethost schreibt das Dockerfile Er hat nuxt in der package.json gesehen und ein Skript, das nuxt build ausführt, und lädt den Ordner noch einmal hoch.
4. Die Maschine baut und startet es Sie sieht, dass der Server auf 3000 lauscht, und leitet die Adresse dorthin. Dann ruft pethost die Adresse selbst auf und gibt aus, was sie geantwortet hat: 200.

Die Datei .pethost sagt, welches Projekt dieser Ordner ist. Committe sie mit dem Dockerfile, dann fragt der nächste Deploy nichts mehr.

Das Dockerfile, das pethost für Nuxt schreibt

Das ist die Datei, wie sie in den Ordner des Starters geschrieben wurde, vollständig:

# Written by pethost deploy for this Nuxt project: Node 24 (no .nvmrc names another),
# npm installs it (package-lock.json), package.json builds it with "nuxt build", node
# runs .output/server/index.mjs (package.json has no start script).
# It is yours now: change it as you like. pethost does not write it again.

FROM node:24
WORKDIR /app

COPY . .

# Every dependency: what builds the project, and may start it, is among the ones for
# development.
RUN --mount=type=cache,target=/root/.npm \
    npm install

RUN npm run build

ENV NODE_ENV=production
CMD ["node", ".output/server/index.mjs"]

Die ersten Zeilen sagen, was pethost in deinem Ordner gelesen hat. Drei Dinge kommen von dort:

• Der Paketmanager ist der, den dein Lockfile nennt: npm, pnpm, Yarn oder Bun.
• Die Node-Version ist die, die .nvmrc oder .node-version nennt, und Node 24, wo es keins von beiden gibt.
• Der Start ist dein start-Skript, wenn die package.json eins hat. Der Starter hat keins, also führt die Datei aus, was nuxt build mit seinem Standard-Preset für den Node-Server schreibt: .output/server/index.mjs.

Der laufende Starter brauchte 30 MB RAM. Wenn die Maschine das Dockerfile, das pethost geschrieben hat, nicht bauen oder starten kann, nimmt pethost die Datei wieder aus deinem Ordner und sagt, was fehlgeschlagen ist.

Runtime-Config und Umgebungsvariablen

Nuxt liest seine Runtime-Config beim Start des Servers aus Variablen, die mit NUXT_ beginnen. Bei Pethost ist eine Variable ein Befehl. Sie landet in der Datei .env des Projekts auf der Maschine, die der Service liest und die jeder spätere Deploy behält:

pethost env set NUXT_PUBLIC_API_BASE=https://api.example.com
pethost env set NUXT_API_SECRET          # asks for the value without showing it

Die App startet mit dem neuen Wert neu. pethost env listet die Namen, und pethost env --show gibt die Datei mit ihren Werten aus.

Eine Seite ändern und neu deployen

Bearbeite app/app.vue und führ denselben Befehl aus. Der zweite Deploy des Starters dauerte 12 s, weil die Maschine die Layer des Builds und den Cache von npm behält:

$ pethost deploy
nuxt-app (.pethost)
✓ Packed 47 files · uploaded · built and started in 12 s
  · wrote compose.yaml for the Dockerfile: the service app, reading .env
  · kept the project's x-pethost
  It answers 200.
https://nuxt-app.sam.pethost.app

Um stattdessen bei jedem Push zu deployen, verbinde das Repository einmal:

pethost github sam/nuxt-app          # from now on, every push deploys itself

Pethost liest nur die Repositorys, die du seiner GitHub-App freigegeben hast. Wenn ein Deploy schiefgeht, holt pethost rollback die Version davor zurück, und deine Maschine behält die drei Versionen vor der aktuellen. Ein KI-Agent kann all das über den MCP-Server von Pethost für dich erledigen: wie ein Agent ein Projekt deployt und betreut.

Eine eigene Domain für die Nuxt-App nutzen

Jeder Name unter der Domain deines Kontos ist sofort eine Adresse, mit HTTPS. Eine Domain, die dir gehört, braucht einen Befehl und einen DNS-Eintrag:

pethost domain add app.example.com

Der Befehl gibt den Eintrag aus, den du anlegen musst: einen CNAME von deinem Namen auf den Namen deiner Maschine. Das Zertifikat kommt von selbst, sobald der Name auflöst, und erneuert sich selbst. pethost password stellt eine Passwortseite vor die ganze App, für eine, die noch nicht öffentlich ist.

Was du für den Preis bekommst

Pethost kostet 9,99 € im Monat für alles, was du hostest, mit 2 vCPU, 3 GB RAM und 30 GB Disk. Der Server des Starters brauchte davon 30 MB RAM, also hat die Maschine Platz für die API, die die App aufruft, ihre Datenbank und deine anderen Projekte. Es gibt keine Gebühr pro Projekt und nichts nach Verbrauch: Server-Rendering wird nicht pro Request abgerechnet.

• 9,99 € im Monat für alle deine Projekte, nichts nach Verbrauch
• 53 s, bis der Starter beim ersten Mal gebaut und gestartet war
• 12 s für den Deploy danach

Was schon für dich erledigt ist: HTTPS mit Zertifikaten, die sich selbst erneuern, Deploys aus GitHub, nächtliche Backups, 14 Tage aufbewahrt, SSH in jeden Container und jeder Request gezählt, mit den meistaufgerufenen Pfaden und der Fehlerquote der letzten 30 Tage. Die Maschine läuft immer, also wartet eine Seite nie auf einen Kaltstart. Die Tarife stehen im Teil Preise der Startseite.

Die Bildschirme zeigen Deploys der App, die npm create nuxt@latest aus seinem minimalen Template schreibt, mit Nuxt 4.6.1 und pethost 0.2.1, auf einer Testmaschine von uns. Das Konto darin ist das Beispielkonto, sam.

1. Nuxt: Installation
2. Nuxt: Deployment
3. Nuxt: Runtime-Config
4. pethost, die Kommandozeile von Pethost