React Deployment: Vercel, Netlify oder Self-Hosted

1. Warum die Deployment-Strategie früh entschieden werden muss

Das React Deployment wird in vielen Teams erst kurz vor dem ersten Livegang ernsthaft geplant, dabei bestimmt die gewählte Plattform bereits die Architekturentscheidungen der App. Wer sich für Server Side Rendering mit Next.js entscheidet, aber erst spät merkt, dass das Hosting keine Node-Runtime unterstützt, muss die App nachträglich auf statisches Rendering umbauen. Ein durchdachtes React Deployment beginnt deshalb mit der Frage, ob die App rein statisch ausgeliefert werden kann oder einen Server pro Request braucht.

Die drei gängigen Wege für ein React Deployment sind verwaltete Plattformen wie Vercel und Netlify, sowie der Selbstbetrieb über Docker und einen eigenen Reverse Proxy. Verwaltete Plattformen übernehmen Build, CDN-Verteilung und SSL automatisch, kosten dafür aber mit steigendem Traffic spürbar mehr. Self-Hosting gibt volle Kontrolle über Infrastruktur und Kosten, verlangt im Gegenzug eigenes Betriebswissen für Zertifikate, Skalierung und Monitoring. Die folgenden Abschnitte zeigen alle drei Wege mit echten Konfigurationsdateien.

Wichtig für die Entscheidung ist außerdem das Team selbst. Ein kleines Team ohne dedizierten DevOps-Ansprechpartner profitiert meist stärker von einer verwalteten Plattform als von der theoretischen Kostenersparnis eines Self-Hosted-Setups. Das React Deployment ist am Ende immer eine Abwägung zwischen Betriebsaufwand, Kosten und Kontrolle, nicht zwischen richtig und falsch.

2. Vercel: Zero Config Deployment für Next.js und Vite

Vercel ist die Plattform der Next.js-Entwickler selbst und bietet dadurch das reibungsloseste React Deployment für Next.js-Projekte. Ein Git-Push auf den verbundenen Branch löst automatisch einen Build aus, jede Route wird als Edge Function oder statische Seite ausgeliefert, je nachdem was der Next.js Router dafür vorsieht. Für Vite-basierte React-Apps funktioniert Vercel ebenso gut, erkennt das Framework automatisch und braucht in den meisten Fällen keine zusätzliche Konfiguration.

Sobald spezielle Routing-Regeln, Redirects oder eigene Header nötig sind, kommt die vercel.json ins Spiel. Diese Datei steuert das React Deployment feingranular, ohne den Anwendungscode selbst anzufassen. Besonders relevant sind Rewrites für Single Page Applications, die alle nicht gefundenen Pfade auf index.html umleiten müssen, damit der clientseitige Router übernehmen kann.

{
  "buildCommand": "npm run build",
  "outputDirectory": "dist",
  "rewrites": [
    { "source": "/api/(.*)", "destination": "https://api.mironsoft.de/$1" },
    { "source": "/(.*)", "destination": "/index.html" }
  ],
  "headers": [
    {
      "source": "/assets/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
      ]
    }
  ]
}

Ein häufiger Stolperstein beim React Deployment auf Vercel: Environment Variablen mit einem VITE_ oder NEXT_PUBLIC_ Präfix werden zur Build Zeit eingebettet. Wer eine Variable im Vercel Dashboard ändert, muss also einen neuen Build anstoßen, ein bloßes Redeploy des alten Builds reicht nicht aus. Die Preview-Umgebung, das Production-Environment und lokale Entwicklung erlauben in Vercel jeweils eigene Variablenwerte, was Staging-Tests deutlich vereinfacht.

3. Netlify: Build-Plugins, Redirects und Edge Functions

Netlify verfolgt einen ähnlichen Ansatz wie Vercel, ist dabei aber technologieoffener und eignet sich für jedes statische React Deployment, unabhängig vom verwendeten Build-Tool. Die Konfiguration erfolgt über netlify.toml im Projektwurzelverzeichnis, was den Vorteil hat, dass Deployment-Einstellungen versioniert im selben Repository liegen wie der Anwendungscode.

Netlify Build-Plugins erweitern den Build-Prozess um zusätzliche Schritte, etwa automatische Lighthouse-Checks nach jedem Build oder Bild-Optimierung vor der Auslieferung. Für ein React Deployment mit hohen Performance-Anforderungen lohnt sich das Plugin @netlify/plugin-lighthouse, das einen Build fehlschlagen lässt, sobald definierte Performance-Budgets unterschritten werden.

# netlify.toml
[build]
  command = "npm run build"
  publish = "dist"

[build.environment]
  NODE_VERSION = "20"

[[redirects]]
  from = "/api/*"
  to = "https://api.mironsoft.de/:splat"
  status = 200

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

[[plugins]]
  package = "@netlify/plugin-lighthouse"

  [plugins.inputs.thresholds]
    performance = 0.85
    accessibility = 0.95

Netlify Edge Functions laufen, anders als klassische serverless Functions, direkt am Edge-Standort nahe der Nutzerin und eignen sich deshalb für A/B-Tests oder Geo-Redirects innerhalb eines sonst rein statischen React Deployment. Der entscheidende Unterschied zu Vercel liegt oft weniger in der Technik als im Preismodell, das für Teams mit hohem Bandbreitenverbrauch genauer verglichen werden sollte.

4. Self-Hosted mit Docker und Nginx: volle Kontrolle

Ein selbst betriebenes React Deployment über Docker gibt die volle Kontrolle über Infrastruktur, Netzwerk und Kosten zurück, verlangt im Gegenzug eigenes Wissen über Container-Orchestrierung. Der übliche Ansatz nutzt einen mehrstufigen Dockerfile Build, der zuerst die App mit Node.js baut und anschließend nur die fertigen statischen Dateien in ein schlankes Nginx-Image kopiert.

Diese Zweistufigkeit hält das finale Image klein, da Node.js, npm und der gesamte Quellcode nicht Teil des Produktions-Images werden. Für das React Deployment in bestehende Kubernetes-Cluster oder auf eigenen Servern ist dieses Muster der Standard, weil das resultierende Image nur wenige Megabyte groß ist und in Sekunden startet.

# Dockerfile — multi-stage build for a React deployment
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:1.27-alpine AS production
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -q --spider http://localhost/ || exit 1
CMD ["nginx", "-g", "daemon off;"]

Die dazugehörige nginx.conf muss für ein React-Deployment eine wichtige Regel enthalten: alle nicht gefundenen Pfade müssen auf index.html zurückfallen, damit der clientseitige Router die Route selbst auflösen kann. Ohne diese Regel liefert Nginx bei jedem direkten Aufruf einer Unterseite einen 404-Fehler, obwohl die Route in der React-App existiert. Zusätzlich lohnt sich Gzip- oder Brotli-Kompression direkt in Nginx, da die meisten CDN-Plattformen das automatisch übernehmen, ein selbst betriebenes React Deployment aber explizit konfiguriert werden muss.

5. Statische Builds gegen SSR-Deployment: Infrastruktur-Unterschiede

Ein rein clientseitiges React Deployment mit Vite erzeugt am Ende nur statische HTML-, CSS- und JavaScript-Dateien, die von jedem CDN oder simplen Webserver ausgeliefert werden können. Das macht Self-Hosting trivial und günstig, da keine Node-Runtime im Produktionsbetrieb laufen muss. Server Side Rendering mit Next.js oder Remix verändert diese Gleichung fundamental, weil jede Anfrage von einer laufenden Node.js-Instanz beantwortet werden muss, die React-Komponenten zur Laufzeit in HTML rendert.

Diese Notwendigkeit einer laufenden Runtime bedeutet für das React Deployment, dass Autoscaling, Health-Checks und Speicherverwaltung plötzlich genauso wichtig werden wie bei jedem klassischen Backend-Service. Vercel und Netlify abstrahieren das über serverless Functions, die pro Request hochgefahren werden, was Kaltstarts verursachen kann. Ein selbst betriebenes SSR-Deployment mit Docker läuft dagegen dauerhaft, vermeidet Kaltstarts, verlangt aber eine bewusste Kapazitätsplanung für Lastspitzen.

Für viele Projekte lohnt sich deshalb ein hybrider Ansatz: Marketing-Seiten und Blogartikel werden statisch generiert und wie eine klassische Single Page Application ausgeliefert, während wirklich dynamische, personalisierte Bereiche über SSR laufen. Diese Trennung reduziert die Serverlast für das React Deployment erheblich, ohne auf die Vorteile von SSR bei individuellen Seiten zu verzichten.

6. CI/CD-Pipeline für automatisiertes React Deployment

Unabhängig von der gewählten Plattform sollte jedes React Deployment über eine automatisierte Pipeline laufen, die Tests, Linting und den eigentlichen Build vor jedem Ausrollen ausführt. GitHub Actions eignet sich dafür gut, weil es direkt an das Repository gekoppelt ist und sowohl für Vercel-Deployments über die CLI als auch für Self-Hosted-Setups über Docker-Registries funktioniert.

# .github/workflows/deploy.yml
name: React Deployment

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "npm"

      - run: npm ci
      - run: npm run lint
      - run: npm run test -- --run
      - run: npm run build

      - name: Build and push Docker image
        run: |
          docker build -t registry.mironsoft.de/shop-frontend:${{ github.sha }} .
          docker push registry.mironsoft.de/shop-frontend:${{ github.sha }}

      - name: Deploy to production host
        run: |
          ssh deploy@prod.mironsoft.de \
            "docker service update --image registry.mironsoft.de/shop-frontend:${{ github.sha }} shop-frontend"

Der entscheidende Vorteil einer solchen Pipeline für das React Deployment liegt darin, dass fehlerhafte Builds gar nicht erst produktiv landen. Schlägt ein Test fehl, bricht die Pipeline ab, bevor irgendein Image gebaut oder ausgerollt wird. Das ersetzt manuelle Deployment-Checklisten durch reproduzierbare, versionierte Automatisierung, die jedes Teammitglied gleichermaßen nutzen kann.

7. Preview-Deployments und Branch-Deploys für Code-Reviews

Vercel und Netlify erzeugen für jeden Pull Request automatisch eine eigene, isolierte Vorschau-Umgebung mit eindeutiger URL. Das verändert den Review-Prozess für ein React Deployment grundlegend, weil Reviewerinnen und Reviewer eine Änderung nicht mehr nur im Diff lesen, sondern live im Browser ausprobieren können, bevor sie gemerged wird. Design-Abweichungen, kaputte Interaktionen oder Layout-Bugs fallen so deutlich früher auf als bei reiner Code-Review ohne Vorschau.

Für ein Self-Hosted React Deployment lässt sich dasselbe Prinzip mit etwas mehr Aufwand nachbauen: Ein CI-Job baut pro Pull Request ein eigenes Docker-Image und startet es unter einem Subdomain-Pattern wie pr-142.preview.mironsoft.de. Traefik oder Nginx mit dynamischer Konfiguration übernehmen dabei das Routing anhand des Branch-Namens. Der Mehraufwand lohnt sich vor allem in Teams, die viele Frontend-Änderungen parallel entwickeln und regelmäßig visuelle Regressionen vermeiden wollen.

8. Rollbacks, Health-Checks und Zero-Downtime-Deployment

Ein produktionsreifes React Deployment braucht einen schnellen Weg zurück, wenn ein Release unerwartete Fehler produziert. Vercel und Netlify speichern jeden erfolgreichen Build und erlauben einen Rollback auf eine frühere Version mit einem einzigen Klick im Dashboard, ohne dass ein neuer Build nötig wäre. Diese Sofort-Verfügbarkeit vergangener Deployments ist einer der größten praktischen Vorteile verwalteter Plattformen.

#!/usr/bin/env bash
# rollback.sh — zero-downtime rollback for a self-hosted React deployment
set -euo pipefail

PREVIOUS_TAG="${1:?Usage: rollback.sh <previous-image-tag>}"
SERVICE="shop-frontend"

echo "[INFO] Rolling back $SERVICE to $PREVIOUS_TAG"
docker service update \
  --image "registry.mironsoft.de/${SERVICE}:${PREVIOUS_TAG}" \
  --update-order start-first \
  "$SERVICE"

# Wait until the new task reports healthy before declaring success
until [ "$(docker service ps "$SERVICE" --filter "desired-state=running" -q | wc -l)" -gt 0 ]; do
  sleep 2
done
echo "[OK] Rollback to $PREVIOUS_TAG completed"

Bei einem Self-Hosted React Deployment mit Docker Swarm oder Kubernetes ist die Reihenfolge start-first entscheidend: Der neue Container muss erst als gesund gemeldet werden, bevor der alte beendet wird. Genau das verhindert eine Downtime während des Rollouts. Health-Checks im Dockerfile, wie im vorherigen Beispiel gezeigt, liefern dem Orchestrator die nötige Information, ob ein Container tatsächlich Anfragen beantworten kann, statt nur gestartet zu sein.

9. Kostenvergleich und Entscheidungskriterien

Die Entscheidung für ein React Deployment hängt stark von Traffic-Volumen, Teamgröße und den regulatorischen Anforderungen an Datenhaltung ab. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen und dient als erste Orientierung, ersetzt aber keine individuelle Kalkulation.

In der Praxis zeigt sich, dass kleinere Teams und Prototypen fast immer mit Vercel oder Netlify schneller ans Ziel kommen, weil das React Deployment keine zusätzliche Infrastrukturarbeit erfordert. Sobald Traffic, Compliance-Anforderungen oder Kostenkontrolle entscheidend werden, verschiebt sich die Abwägung zunehmend in Richtung Self-Hosting mit Docker, insbesondere wenn ohnehin schon ein eigener Kubernetes- oder Swarm-Cluster für andere Services betrieben wird.

10. Zusammenfassung

Das React Deployment auf Vercel oder Netlify liefert das schnellste Ergebnis mit dem geringsten Betriebsaufwand, weil Build, CDN und SSL vollständig verwaltet werden. Beide Plattformen bieten automatische Preview-Deployments pro Pull Request und einen Rollback per Klick, was den täglichen Entwicklungsalltag deutlich erleichtert. Der Preis dafür sind steigende Kosten bei hohem Traffic und eine gewisse Abhängigkeit von US-amerikanischen Anbietern.

Ein Self-Hosted React Deployment mit Docker und Nginx verlangt eigenes Betriebswissen für Health-Checks, Zero-Downtime-Rollouts und Zertifikatsverwaltung, gibt dafür volle Kontrolle über Kosten und Datenhoheit zurück. Für viele Projekte ist die Entscheidung keine reine Technikfrage, sondern hängt von Teamgröße, Compliance-Vorgaben und der langfristigen Kostenplanung ab. Eine automatisierte CI/CD-Pipeline mit Tests vor jedem Rollout lohnt sich unabhängig von der gewählten Plattform immer.

11. FAQ: React Deployment