Eine Next.js-App auf Schweizer Hosting deployen mit klickops
Next.js wird meist auf Vercel gezeigt, ist im Kern aber ein Node-Server und läuft überall, wo ein Container läuft. Das zählt, wenn deine Nutzer, die Anwälte deiner Kunden oder deine eigenen Grundsätze sagen, dass die App in der Schweiz laufen soll. Diese Anleitung führt durch ein produktives Next.js-Deployment auf klickops: richtig bauen, live gehen, Domain und Datenbank anschliessen, und verstehen, was Autoscaling und Scale-to-zero für eine servergerenderte App bedeuten.
Mit Standalone-Output bauen
Standardmässig erwartet ein Next.js-Produktions-Build zur Laufzeit den ganzen node_modules-Baum. Das macht Deployments langsam und Images schwer. Der Standalone-Modus verfolgt genau, welche Dateien der Server braucht, und kopiert sie in einen eigenständigen Ordner mit minimalem server.js. Eine Zeile in der Konfiguration schaltet ihn ein:
Nach next build liegt alles, was die App zur Laufzeit braucht, in .next/standalone, dazu die statischen Assets in .next/static und dein public-Ordner. Dieses Trio ist deine Deployment-Einheit, und es macht das Image typischerweise Hunderte Megabyte kleiner.
module.exports = {
output: "standalone"
};Zwei Wege zum Deployment
Der schnellste Weg: Verbinde dein GitHub- oder GitLab-Repository in klickops. Jeder Push baut und deployt automatisch, und für Pull Requests bekommst du auf Wunsch Preview-Umgebungen pro Branch. Du schreibst keine Pipeline-Konfiguration; die Plattform beginnt bei deinem Repo und endet bei einer laufenden App mit URL.
Wenn du den Build lieber selbst besitzt, lieferst du stattdessen ein Container-Image. klickops deployt jedes Image, das es ziehen kann, und inspiziert es beim Deployment, um Port und Umgebung vorzuschlagen. Ein Multi-Stage-Dockerfile für Standalone-Next.js sieht so aus:
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/.next/standalone ./
COPY --from=build /app/.next/static ./.next/static
COPY --from=build /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]Umgebungsvariablen nach Next.js-Art
Next.js trennt Konfiguration in zwei Welten, und es lohnt sich, diese Trennung beim Verdrahten zu respektieren. Variablen mit dem Präfix NEXT_PUBLIC_ werden beim Build ins Client-Bundle eingebettet. Sie müssen also beim Build existieren und sind für jeden mit einem Browser sichtbar. Alles andere liest der Server zur Laufzeit, und es bleibt privat.
Auf klickops setzt du Laufzeitwerte als Umgebungsvariablen auf der App. Alles Sensible (Datenbank-URLs, API-Keys, Auth-Secrets) speicherst du als verwaltete Secrets: Sie werden zur Laufzeit in den Container injiziert, und das Dashboard zeigt den Wert nach dem Speichern nie wieder an. Weil NEXT_PUBLIC_-Werte beim Build eingebacken werden, heisst eine Änderung neu bauen, was der Repo-Flow beim nächsten Push für dich erledigt.
Eine Domain mit TLS, über das du nie nachdenkst
Jede App bekommt beim Deployment eine Plattform-Subdomain mit funktionierendem HTTPS. Für Staging und Previews reicht das völlig. Für die Produktion fügst du im Dashboard deine eigene Domain hinzu und setzt einen DNS-Eintrag; klickops stellt das TLS-Zertifikat aus und erneuert es automatisch. Kein certbot, keine Zertifikats-Ressource, kein Erneuerungs-Cron, den man vergessen kann.
Eine Planungsnotiz: Der Gratis-Plan läuft nur auf der Plattform-Subdomain. Eigene Domains beginnen beim Hobby-Plan (CHF 9 pro Monat), der drei davon enthält.
Was Autoscaling und Scale-to-zero für Next.js bedeuten
Eine servergerenderte Next.js-App ist ein langlaufender Prozess, und klickops behandelt sie so. Autoscaling fügt Replicas hinzu, wenn die Last steigt, und entfernt sie, wenn sie fällt, mit unterbrechungsfreien Rollouts bei jedem Deployment. CPU und Speicher dimensionieren sich automatisch, du wählst also nie einen Instanztyp; abgerechnet wird stundengenau, was die App wirklich nutzt.
Scale-to-zero denkt das zu Ende: Ohne Traffic kann die App ganz stoppen, und eine gestoppte App verursacht bei nutzungsbasierter Abrechnung keine Rechenkosten. Der Kompromiss ist ehrlich und gut zu kennen: Die erste Anfrage nach dem Schlaf wartet auf den Container-Start, bei einem Standalone-Next.js-Server typischerweise ein paar Sekunden. Für Staging, interne Tools und Nebenprojekte ist das ein guter Tausch. Für eine latenzkritische Produktions-Homepage nicht; dort lässt du mindestens ein Replica warm und überlässt die Spitzen dem Autoscaling.
Verwaltetes Postgres dazu
Die meisten echten Next.js-Apps bekommen irgendwann eine Datenbank, und hier schlägt eine Plattform das Zusammenstückeln von Diensten. Erstelle eine verwaltete PostgreSQL-Instanz im selben Projekt: Sie kommt mit Hochverfügbarkeit, automatischen Backups, Point-in-time-Restore und einer Query-Konsole, und sie läuft im selben Schweizer Rechenzentrum wie deine App. Abfragen überqueren also nie eine Grenze oder das öffentliche Internet.
Kopiere den Connection-String in ein Secret (DATABASE_URL), referenziere es aus der App, und dein ORM läuft unverändert. Prisma, Drizzle und Co. brauchen nichts weiter als die URL.
Was es ungefähr kostet
Weil gemessen abgerechnet wird, folgen die Kosten dem echten Fussabdruck der App statt der Form eines Plan-Tiers. Eine produktive Next.js-App plus eine kleine Postgres-Instanz mit im Schnitt rund 0.4 vCPU, 1.5 GB Speicher und 10 GB Disk kommt zu Listenpreisen auf etwa CHF 43 pro Monat, und das Planguthaben drückt die echte Rechnung darunter (jeder Plan enthält Nutzungsguthaben, das mehr wert ist als der Planpreis). Ein Hobby-Projekt, das die meiste Zeit schläft, landet weit tiefer, und der Gratis-Plan deckt eine kleine App und eine Datenbank in einem kleinen Rahmen ab, ohne Karte.
Der Preisrechner auf der Preisseite nutzt dieselben Live-Tarife, wenn du deine eigenen Zahlen durchspielen willst, bevor du etwas deployst.
Warum das für Next.js einen VPS schlägt
Du könntest denselben Container auf einem gemieteten VPS betreiben, und viele tun das, bis am Wochenende die Zertifikatserneuerung scheitert oder die Maschine einen Kernel-Patch braucht. Auf klickops übernimmt die Plattform TLS, Rollouts, Rollbacks, Skalierung, Backups und Monitoring, während darunter alles Standard bleibt: Deine App ist ein normales Kubernetes-Deployment, das du als sauberes YAML exportieren und überallhin mitnehmen kannst. Schweizer Datenstandort auf Hardware im Besitz des Betreibers, ohne Server-Hausaufgaben, und ohne Lock-in, der dich festhält.
Bereit für Schweizer Infrastruktur?
Private Beta, Gratis-Plan für einen kleinen Stack, keine Karte nötig.