Next.js auf OpenShift deployen – was Netlify dir nicht beibringt

Warum OpenShift – und warum wieder weg?

Netlify hat nichts falsch gemacht. Railway auch nicht. Trotzdem wollte ich wissen, wie es sich anfühlt, wenn man selbst die Kontrolle hat – kein "Push and Deploy", kein Magic-Deployment, keine Abstraktion auf Abstraktion. OpenShift Developer Sandbox ist kostenlos, läuft auf Kubernetes, und es hat mich einen halben Tag gekostet, bis die erste Next.js-Seite oben war. Dieser Artikel ist das, was ich vorher gebraucht hätte.

Der nächste Schritt: die Spring Boot Microservices von Railway nach OpenShift migrieren. Aber zuerst musste das Frontend laufen.

Die nginx-Falle: Kein root auf OpenShift

Der erste Versuch war ein Standard-nginx-Container. OpenShift hat ihn sofort abgeschossen. Kein hilfreicher Fehler, nur CrashLoopBackOff. Die Ursache: OpenShift erlaubt per Default keine root-Container. nginx läuft auf Port 80, und Port 80 braucht root. Das ist auf normalen Servern kein Problem – auf OpenShift ist es ein Showstopper.

OpenShift Security Context Constraint (SCC)

  Standard nginx (Port 80, root)
  ─────────────────────────────
  Container startet → OpenShift prüft SCC
  → User 0 (root) verboten
  → CrashLoopBackOff ✗

  nginxinc/nginx-unprivileged (Port 8080, non-root)
  ──────────────────────────────────────────────────
  Container startet → OpenShift prüft SCC
  → Non-root User ✓
  → Pod läuft ✓

# Falsch – schlägt fehl auf OpenShift:
FROM nginx:alpine

# Richtig – rootless, Port 8080:
FROM nginxinc/nginx-unprivileged:alpine

Privates GitHub Repo einbinden

OpenShift kann nicht einfach auf ein privates GitHub-Repo zugreifen. Ein Personal Access Token reicht nicht – das Secret muss außerdem annotiert werden, damit OpenShift es automatisch der richtigen URL zuordnet.

# 1. Secret mit GitHub Personal Access Token anlegen
oc create secret generic github-secret \
  --from-literal=username=<github-username> \
  --from-literal=password=<github-PAT> \
  --type=kubernetes.io/basic-auth

# 2. Secret annotieren – OpenShift nutzt es automatisch für die URL
oc annotate secret github-secret \
  "build.openshift.io/source-secret-match-uri-1=https://github.com/<username>/*"

# 3. Builder-ServiceAccount bekommt Zugriff
oc secret link builder github-secret

Dockerfile für Next.js: Multi-Stage und standalone

Ein normales Dockerfile würde ein riesiges Image produzieren – node_modules sind hunderte Megabyte. Multi-Stage Build löst das: Die Build-Stage kompiliert, die Runtime-Stage kopiert nur das Ergebnis.

Das Schlüsselwort ist output: "standalone" in der next.config.ts. Next.js bündelt dann nur die tatsächlich importierten Dependencies in .next/standalone – kein node_modules im finalen Image nötig.

# next.config.ts – eine Zeile entscheidet alles:
output: "standalone"

# Das Ergebnis: .next/standalone enthält nur was wirklich gebraucht wird.
# Kein node_modules im finalen Image – spart ~800MB.

Die NEXT_PUBLIC_* Falle: Build-Zeit vs. Runtime

Das war der teuerste Fehler in Zeiteinheiten. Next.js unterscheidet strikt zwischen Variablen, die zur Build-Zeit eingefroren werden, und Variablen, die zur Laufzeit ausgewertet werden.

NEXT_PUBLIC_* – die Falle

  Build-Zeit                    Runtime
  ──────────────────────────    ──────────────────────────
  NEXT_PUBLIC_SITE_URL          BLOG_BASE_URL
  NEXT_PUBLIC_BLOG_BASE         AUTH_BASE_URL
  NEXT_PUBLIC_CLOUDINARY_*      CLOUDINARY_API_SECRET
  NEXT_PUBLIC_GA_*              CLOUDINARY_API_KEY

  → Werden in den JS-Bundle     → Werden beim Start des
    eingefroren (unveränderbar)   Servers ausgelesen

  Falsch gesetzt → leere         Falsch gesetzt → localhost
  Variablen im Frontend          als Proxy-Ziel

# BuildConfig – NEXT_PUBLIC_* als buildArgs:
spec:
  strategy:
    type: Docker
    dockerStrategy:
      buildArgs:
        - name: NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME
          value: dein-cloud-name
        - name: NEXT_PUBLIC_SITE_URL
          value: https://zelkulon.com

# Runtime Vars – Server-seitige Secrets:
oc create secret generic zelkulon-secrets --from-env-file=.env.local
oc set env deployment/zelkulon-homepage --from=secret/zelkulon-secrets

BuildConfig statt oc new-app

oc new-app --strategy=docker schlägt häufig fehl wenn OpenShift die Git-URL nicht direkt verifizieren kann. Die sauberere Lösung: BuildConfig manuell per YAML anlegen.

# ImageStream zuerst anlegen – sonst: InvalidOutputReference
oc create imagestream zelkulon-homepage

# BuildConfig per YAML
cat <<EOF | oc apply -f -
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: zelkulon-homepage
spec:
  source:
    type: Git
    git:
      uri: https://github.com/<username>/zelkulon-homepage.git
    sourceSecret:
      name: github-secret
  strategy:
    type: Docker
  output:
    to:
      kind: ImageStreamTag
      name: zelkulon-homepage:latest
EOF

# Build starten und live beobachten (dauert 5–7 Minuten)
oc start-build zelkulon-homepage --follow

Ein Build dauert 5–7 Minuten – Next.js TypeCheck und Production Build brauchen ihre Zeit. Mit npm cache würde es schneller gehen, aber für die Sandbox reicht es.

HTTPS automatisch mit Edge Route

Was mich am meisten überrascht hat: TLS ist kein manueller Schritt. OpenShift übernimmt die Zertifikatsverwaltung vollständig – man erstellt eine Edge Route, und HTTPS funktioniert sofort.

# App aus ImageStream deployen
oc new-app --image-stream=zelkulon-homepage:latest --name=zelkulon-homepage

# HTTPS Route mit Edge Termination – TLS übernimmt OpenShift automatisch
oc create route edge zelkulon-homepage \
  --service=zelkulon-homepage \
  --port=3000

# URL abrufen
oc get routes

OpenShift vs. Netlify vs. Railway

Die Tabelle zeigt die ehrliche Einschätzung nach 30 Tagen Sandbox-Betrieb. OpenShift ist kein Netlify-Ersatz für kleine Teams.

Fazit: Schneller, aber nicht für jeden

OpenShift ist schneller. Das ist keine Theorie – nach 30 Tagen Sandbox lädt die Seite spürbar flotter, die Bilder sind sofort da. Kubernetes-Scheduling, dedizierte Ressourcen, kein Cold-Start-Theater.

Trotzdem bleiben wir bei Netlify und Railway. Nicht weil OpenShift schlechter ist, sondern weil das Sandbox-Tier ausläuft und ein echter OpenShift-Cluster für eine kleine UG schlicht zu teuer ist. Der Performancevorteil rechtfertigt die Kosten aktuell nicht.

• Root-Container funktionieren nicht – nginxinc/nginx-unprivileged ist Pflicht
• NEXT_PUBLIC_* gehören in buildArgs, nicht in Runtime-Secrets
• ImageStream vor dem ersten Build anlegen
• BuildConfig per YAML ist zuverlässiger als oc new-app
• Performance ist messbar besser – aber der Preis passt nicht für kleine UGs

Das hier war Phase 1. In den nächsten Artikeln folgt, wie sich OpenShift mit Spring Boot Microservices schlägt – Service Discovery, persistente Datenbanken, interne Kommunikation. Ob sich der Aufwand lohnt, wird sich zeigen.