Next.js-Entwickler in Berlin

Ich bin Mariusz Szatkowski, ein einzelner Entwickler aus Gdynia, und arbeite seit 2006 mit WordPress. Für Berlin schreibe ich hier über eine Frage, die bei Next.js-Projekten spät auftaucht: Wo läuft die Anwendung, und was passiert, wenn es nicht Vercel ist? Alle Angaben zu Next.js stammen aus der Dokumentation auf nextjs.org. Aktuell ist laut npm-Registry Version 16.4.6 vom 9. November 2026.

#Welche Betriebswege Next.js selbst nennt

Die Seite zum Deployment führt vier Wege auf.

Der erste Punkt klingt banal und wird trotzdem oft übersehen: Ein Node.js-Server mit next build und next start unterstützt alles, was Next.js kann. Wer bei Vercel hostet, hat einen bequemen Weg gewählt, keinen zwingenden. Der statische Export fällt aus dem Rahmen, weil er keine Funktionen unterstützt, die einen Server brauchen. Laut Self-Hosting-Anleitung gehört dazu der Proxy.

#Der standalone-Build für Container

Für Docker ist output: 'standalone' der übliche Einstieg. Die Dokumentation zu output beschreibt es so: Next.js verfolgt beim Build, welche Dateien jede Seite braucht, und legt sie unter .next/standalone ab, einschließlich ausgewählter Dateien aus node_modules. Der Ordner lässt sich ohne weitere Installation deployen.

// next.config.js
module.exports = {
  output: 'standalone',
}

Zwei Details sorgen in der Praxis für Überraschungen. Erstens kopiert der Build public und .next/static nicht mit, weil diese Ordner laut Dokumentation idealerweise ein CDN ausliefert. Wer keines vorschaltet, kopiert sie nach dem Build von Hand:

cp -r public .next/standalone/ && cp -r .next/static .next/standalone/.next/

Zweitens startet man die minimale Datei mit node .next/standalone/server.js, und Port und Host kommen aus den Umgebungsvariablen PORT und HOSTNAME. Bei einem Monorepo verfolgt Next.js standardmäßig nur den Projektordner, Dateien außerhalb fehlen dann im Ergebnis. Dafür gibt es outputFileTracingRoot.

Vor den Server gehört nach der Self-Hosting-Anleitung ein Reverse Proxy wie nginx, der fehlerhafte Anfragen, langsame Verbindungen, Größenlimits und Rate Limiting übernimmt, damit Next.js seine Zeit mit dem Rendern verbringt.

#Cache, Bilder und Umgebungsvariablen

Hier unterscheidet sich der Betrieb ohne Vercel am stärksten. Die Self-Hosting-Anleitung hält fest: Caching und ISR nutzen denselben Server-Cache, und der liegt standardmäßig im Arbeitsspeicher und auf der lokalen Platte jeder Instanz. Mit einer Instanz und persistenter Platte klappt das ohne Konfiguration. Bei mehreren Containern gilt:

• Unter Kubernetes hat jeder Pod seine eigene Kopie des Caches.
• revalidateTag() auf einer Instanz entwertet laut Dokumentation nur den Cache dieser Instanz, die anderen liefern weiter alte Inhalte.

Die Lösung ist ein eigener cacheHandler:

// next.config.js
module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // disable default in-memory caching
}

Die Dokumentation stellt dafür Bedingungen. Der Speicher muss für alle Instanzen erreichbar sein (genannt werden Redis und S3), seine Größe begrenzen, Einträge serialisieren, weil sie Buffer und Map enthalten, Einträge nach Tags indizieren und Speicherfehler abfangen. Ein Handler, der nur eine Map im Prozess hält, gibt jedem Pod wieder seinen eigenen Cache. Das ist mehr als ein Häkchen in der Konfiguration.

Bilder. next/image funktioniert beim Selbstbetrieb mit next start ohne Konfiguration. Auf Linux-Systemen mit glibc kann die Bildoptimierung laut Dokumentation zusätzliche Einstellungen brauchen, damit sie nicht übermäßig Speicher belegt.

Umgebungsvariablen. Mit NEXT_PUBLIC_ markierte Variablen werden beim Build in das JavaScript-Bundle geschrieben. Ein einziges Docker-Image für Test und Produktion klappt deshalb nur, wenn Werte zur Laufzeit gelesen werden, etwa nach await connection() in einer dynamisch gerenderten Komponente.

#Was bei mehreren Instanzen kaputtgeht

Die Anleitung nennt vier Stellen, an denen ein Betrieb mit mehreren Instanzen anders reagiert als ein einzelner Server.

Der letzte Punkt gilt auch für Load Balancer. Die Anleitung nennt als Beispiel AWS ALB mit Lambda-Integration, der Antworten standardmäßig puffern kann. Beim Beenden eines Containers verlangt Next.js ein geordnetes Herunterfahren per SIGINT oder SIGTERM, damit laufende Anfragen und after()-Callbacks fertig werden. Die Dokumentation empfiehlt 10 bis 30 Sekunden Wartezeit.

#Adapter: Cloudflare, AWS und die offizielle Schnittstelle

Seit Next.js 16.2.0 ist die Adapter-API laut Versionshistorie stabil: adapterPath wanderte von experimental.adapterPath in die Hauptoptionen. Nach npm-Registry erschien 16.2.0 am 18. März 2026. Plattformen können damit in den Build eingreifen. Auf der Deployment-Seite stehen Vercel und Bun als verifizierte Adapter, die die Kompatibilitätstests durchlaufen. Cloudflare und Netlify arbeiten dort noch an verifizierten Adaptern, bis dahin bieten sie eigene Integrationen an, die nicht auf der öffentlichen Adapter-API aufbauen und deren Funktionsumfang abweichen kann.

Cloudflare. Der Adapter OpenNext für Cloudflare bringt Next.js-Anwendungen auf Cloudflare Workers und nutzt die Node.js-Runtime. Genannt werden App Router, Pages Router, SSG, SSR, ISR, Partial Prerendering, Middleware und Image Optimization. Node Middleware ist laut Seite noch nicht unterstützt. Als Cache für ISR empfiehlt die Caching-Seite R2. Von KV rät sie ab, weil es laut Seite nur „eventually consistent“ sei. Für On-Demand-Revalidierung braucht es zusätzlich einen Tag-Cache auf D1 oder auf Durable Objects. Cloudflares eigene Anleitung beschreibt dagegen vinext, laut Seite eine Beta, und führt OpenNext nur als Alternative für bestehende Anwendungen mit Lücken auf. Wer bei Cloudflare landen will, liest also zwei Quellen mit unterschiedlicher Gewichtung. Mehr zu Workers allgemein steht auf der Seite Cloudflare Workers in Berlin.

AWS. OpenNext für AWS wandelt die Next.js-Ausgabe in Pakete für AWS Lambda, Amazon ECS und einen klassischen Node.js-Server um. Die Seite sagt, das Projekt wolle alle Funktionen von Next.js 15 unterstützen, einzelne seien noch in Arbeit, und es werde von der SST-Community gepflegt. Welche Funktion Ihre Anwendung braucht, prüfe ich gegen diese Liste, bevor ich einen Weg vorschlage.

#Datenresidenz in der EU: wo der Code läuft

Foto: Dietmar Rabich, CC BY-SA 4.0, Wikimedia Commons.

Wer Next.js bei einem Plattformanbieter betreibt, muss wissen, in welcher Region der Servercode läuft. Vercels Regionenseite nennt als Standard für Vercel Functions iad1, also Washington, D.C. Frankfurt (fra1) steht in der Liste und lässt sich einstellen. Bei Cloudflare laufen Workers laut Dokumentation zu Smart Placement in dem Rechenzentrum, das der Anfrage am nächsten ist. Ein Placement-Hint wie aws:eu-central-1 zielt auf geringe Latenz zu Ihrem Backend, nicht auf eine geografische Beschränkung. Für Letzteres beschreibt die Seite zu Regional Services eine Möglichkeit: TLS-Terminierung, Cache, WAF und Workers laufen dann nur in der gewählten Region, zum Beispiel der EU. Sie nennt Regional Services einen Enterprise-Zusatz.

Was das rechtlich bedeutet, beschreibt die Berliner Beauftragte für Datenschutz und Informationsfreiheit auf ihrer Seite zu Datenexporten:

• Geprüft wird in zwei Stufen. Erstens: Wäre die Verarbeitung erlaubt, wenn sie in der EU oder im EWR stattfände? Zweitens: Ist zusätzlich der Export in das Drittland erlaubt?
• Der Begriff der Übermittlung ist weit. Er schließt Zugriffsrechte von Stellen im Drittland ein, etwa für Kundenbetreuung, IT-Service oder Administration, auch bei Subunternehmen.
• Der Angemessenheitsbeschluss zum EU-U.S. Data Privacy Framework vom 10. Juli 2023 gilt nur, wenn der US-Empfänger zertifiziert ist. Verantwortliche prüfen das in der Liste des US-Handelsministeriums.
• Ohne Zertifizierung braucht es andere Instrumente aus Kapitel V der DSGVO, etwa Standardvertragsklauseln, und eine Bewertung der Rechtslage im Drittland.
• Verliert der Beschluss seine Wirksamkeit, müssen Verantwortliche auf andere Instrumente umstellen oder Übermittlungen einstellen.

Das ist keine Rechtsberatung und ersetzt sie nicht. Für die Technik folgt daraus eine Frage, die ich vor dem Start schriftlich beantworte: Welche Komponente läuft wo, und wer hat Zugriff? Dazu zählen Servercode, Cache, Bildoptimierung, Logs und Datenbank. Die Antwort bekommt Ihre Rechtsberatung als Tabelle.

#Checkliste vor der Entscheidung

#Wann Vercel die einfachere Wahl bleibt

Gibt es keine Vorgabe zu Standort oder Anbieter, und gibt es keinen Betriebsmitarbeiter, der Container pflegen soll, dann ist die Plattform, für die Next.js gebaut wird, der kürzeste Weg. Dann ist die Frage nur, ob die Funktionsregion auf Frankfurt steht. Selbstbetrieb lohnt sich, wenn der Standort vorgegeben ist, wenn ohnehin ein Kubernetes-Cluster läuft oder wenn Sie nicht an einen Anbieter gebunden sein wollen. Ist die Anwendung im Kern eine Inhaltsseite, prüfe ich vorab, ob Astro weniger Betrieb bedeutet. Für Bestandsanwendungen, die zum falschen Werkzeug gewachsen sind, gibt es die Seite zur Migration zwischen Next.js und Astro in Berlin.

#So läuft ein Projekt mit mir

Ich arbeite allein, aus der Ferne und schriftlich, ohne Termine und Telefonate. Am Anfang steht Ihre Mail mit Zielen, Stack und Frist. Ich stelle meine Fragen schriftlich und schicke eine Beschreibung des Umfangs mit den Annahmen. Gebaut wird auf einer Staging-Umgebung, Sie nehmen schriftlich ab, danach geht es live. Für den Selbstbetrieb liefere ich das Container-Setup, die Konfiguration von Cache und Proxy sowie eine Betriebsbeschreibung, mit der auch Ihr Team die Anwendung übernehmen kann. Das Layout liefern Sie als Wireframe, ich baue es nach. Wollen Sie die Pflege danach abgeben, beschreibt die Seite Wartung und Support in Berlin den Ablauf. Für PHP-Backends hinter dem Frontend gibt es die Seite PHP-Entwicklung in Berlin.

#Häufige Fragen

Muss eine Next.js-Anwendung bei Vercel laufen? Nein. Die Next.js-Dokumentation nennt vier Wege: Node.js-Server, Docker-Container, statischer Export und Adapter. Node.js-Server und Docker unterstützen laut Tabelle alle Funktionen, der statische Export nur einen Teil. Welcher Weg passt, hängt von Cache, Betrieb und Datenstandort ab, nicht von Next.js selbst.

Was bewirkt output standalone? Next.js legt unter .next/standalone nur die Dateien ab, die der Produktionsserver braucht, samt einer minimalen server.js. Die Ordner public und .next/static kopiert der Build nicht mit, sie sollen laut Dokumentation idealerweise ein CDN ausliefern. Man kann sie von Hand daneben legen.

Funktioniert ISR mit mehreren Containern? Nur mit einem geteilten Cache. Standardmäßig hält jede Instanz ihren eigenen Cache, und revalidateTag() wirkt nur auf der Instanz, die den Aufruf bekommt. Die Dokumentation verlangt einen eigenen cacheHandler mit einem Speicher, den alle Instanzen erreichen, zum Beispiel Redis.

Läuft Next.js auf Cloudflare? Ja, über den OpenNext-Adapter für Cloudflare mit der Node.js-Runtime. Laut Projektseite fehlt noch Node Middleware. Cloudflares eigene Next.js-Anleitung führt inzwischen vinext auf, das dort als Beta bezeichnet wird, und nennt OpenNext als Alternative. Vor der Wahl lese ich beide Seiten gegen Ihre Funktionsliste.

Reicht ein Server in Frankfurt für die DSGVO? Ein Standort in der EU ist ein Baustein, nicht die ganze Antwort. Die Berliner Datenschutzbehörde zählt auch Zugriffsrechte von Stellen in einem Drittland zur Übermittlung, etwa für Support oder Administration. Die rechtliche Bewertung gehört zu Ihrer Rechtsberatung, ich liefere die technische Übersicht, wo welche Komponente läuft.

Gestalten Sie auch das Layout? Nein. Das Layout kommt von Ihnen oder Ihrer Agentur. Sie markieren in einer Tabellenvorlage, welches Element auf welche Ansicht gehört; daraus baue ich das responsive Frontend.

#Ihr Projekt in einer E-Mail

Wollen Sie eine Anwendung selbst betreiben, von Vercel wegziehen oder prüfen, ob ein Adapter für Ihre Funktionen taugt? Über das Kontaktformular erreichen Sie mich schriftlich. Nennen Sie die Adresse Ihrer Anwendung, Ihr Ziel, den Wunschtermin und den aktuellen Stack samt Hosting. Ich antworte an Werktagen mit meinen Fragen und einer ersten Schätzung, und die ist kostenlos.