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 und klickops-Builds die Umgebungsvariablen der App nicht bekommen, legst du sie im Repo ab (etwa in .env.production) oder im Dockerfile; der nächste Push baut damit neu.
Eine Domain mit TLS, über das du nie nachdenkst
Wählst du unter „Who can reach it?“ „Anyone (public)“, bekommt die App beim Deployment eine Plattform-Subdomain mit funktionierendem HTTPS. Für Staging und Previews reicht das völlig. Für die Produktion bestätigst du deine Domain einmal unter Domains in deiner Organisation (ein TXT-Eintrag), fügst sie der App hinzu und setzt den angezeigten CNAME; 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: Stellst du eine App auf null Kopien, etwa eine Staging-App übers Wochenende, verursacht sie bei nutzungsbasierter Abrechnung keine Rechenkosten, solange sie gestoppt ist. Der Kompromiss ist ehrlich und gut zu kennen: klickops weckt eine App nicht bei der ersten Anfrage, eine gestoppte App antwortet also nicht, bis du sie wieder hochskalierst. Für Staging und interne Tools, die du nur ab und zu brauchst, ist das ein guter Tausch. Für eine Produktions-Homepage nicht; dort lässt du mindestens ein Replica laufen 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 mit kleinem Fussabdruck landet weit tiefer, und der Gratis-Plan bietet ohne Karte Platz für eine kleine App und eine Datenbank, sein Guthaben von CHF 1 pro Monat deckt aber nur etwa eine statische Website.
Die Tarife auf der Preisseite sind dieselben Listenpreise, 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.