Eine serverseitig gerenderte…

In dieser Anleitung führe ich Sie durch die Schritte, um eine serverseitig gerenderte Angular-20+-Anwendung auf Cloudflare Workers bereitzustellen, einer leistungsstarken Serverless-Plattform, mit der Sie Ihre Angular-App in Cloudflares globalem Edge-Netzwerk ausführen können.

Voraussetzungen

Sie benötigen Folgendes:

Node.js 22 oder neuer
Ein Cloudflare-Konto

Demo-Anwendung

Ein funktionierendes Beispiel dieses Deployments sehen Sie in Aktion unter https://angular-ssr-app.launchfast.workers.dev/posts. Es demonstriert eine vollständig serverseitig gerenderte Angular-Anwendung auf Cloudflare Workers ohne Cold Starts.

Die Architektur verstehen

Beim Deployment von Angular SSR auf Cloudflare Workers wird die Anwendung in zwei Teile aufgeteilt:

Browser-Build (dist/<app>/browser/*) - Statische Assets, die direkt über Cloudflares Asset-Handling ausgeliefert werden und den Worker umgehen
Server-Build (dist/<app>/server/*) - In den Worker gebündelt für das serverseitige Rendering

Die Cloudflare-Worker-Brücke

Erstellen Sie einen Einstiegspunkt für Ihr Cloudflare-Deployment unter cloudflare/worker.ts. Diese Datei verbindet Ihre Angular-SSR-Anwendung mit der Cloudflare-Workers-Laufzeitumgebung. Das macht sie:

import {
  AngularAppEngine,
  createRequestHandler,
  ɵsetAngularAppEngineManifest as setAngularAppEngineManifest,
} from '@angular/ssr';

// Generated build artifact containing the engine manifest
import engineManifest from '../dist/angular-ssr-app/server/angular-app-engine-manifest.mjs';

setAngularAppEngineManifest(engineManifest);

const angularApp = new AngularAppEngine();

/**
 * createRequestHandler returns a Web-standard (Request) => Response handler,
 * which is exactly the shape Cloudflare's fetch handler expects.
 */
const fetch = createRequestHandler(async (request: Request) => {
  const response = await angularApp.handle(request);
  return response ?? new Response('Not found', { status: 404 });
});

export default { fetch };

Wichtige Punkte

AngularAppEngine wird initialisiert, um das SSR-Rendering zu übernehmen
Das engine manifest wird aus Ihrer Build-Ausgabe importiert: es enthält inline eingebundene HTML-Templates und Build-Metadaten
createRequestHandler verpackt Angulars Engine in einen Web-standardkonformen fetch-Handler, den Cloudflare erwartet
Jede Anfrage, die zu keiner Route passt, gibt einen 404 zurück

Wrangler-Konfiguration aktualisieren

Aktualisieren Sie Ihre wrangler.jsonc-Datei wie folgt:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "angular-ssr-app",
  "main": "cloudflare/worker.ts",
  "compatibility_date": "2025-05-05",
  // Enable Node.js compatibility for Angular's SSR dependencies
  "compatibility_flags": ["nodejs_compat"],
  // Define import.meta.url for polyfills compatibility
  "define": {
    "import.meta.url": "\"file:///worker.mjs\""
  },
  // Serve browser build as static assets
  "assets": {
    "directory": "./dist/angular-ssr-app/browser",
    "binding": "ASSETS"
  },
}

Konfiguration erklärt

compatibility_flags: ["nodejs_compat"] - Erforderlich, weil Angulars Server-Polyfills Node.js-Built-ins verwenden
define - Stellt einen Fallback für import.meta.url bereit, das beim Bundling zusammengefasst wird
assets.directory - Verweist auf Ihren Browser-Build für die Auslieferung statischer Dateien

Build-Konfiguration für Cloudflare

Ihre angular.json legt fest, wie Angular für die Cloudflare-Plattform baut:

{
  "projects": {
    "angular-ssr-app": {
      "architect": {
        "build": {
          "builder": "@angular/build:application",
          "options": {
            "browser": "src/main.ts",
            "server": "src/main.server.ts",
            "outputMode": "server",
            "ssr": {
              "entry": "src/server.ts"
            },
            "security": {
              "allowedHosts": [
                "localhost",
                "angular-ssr-app.launchfast.workers.dev"
              ]
            }
          }
        }
      }
    }
  }
}

SSRF-Schutz mit Allowed Hosts

Die Einstellung allowedHosts verhindert Server-Side-Request-Forgery-Angriffe (SSRF):

Nur die hier aufgeführten Hostnamen können serverseitig gerendert werden
Fügen Sie Ihre Produktions- und Preview-Domains hinzu
Zur Deploy-Zeit können Sie über die Umgebungsvariable NG_ALLOWED_HOSTS zusätzliche Hosts hinzufügen, ohne neu zu bauen

Bauen und Bereitstellen

Ihre package.json enthält praktische Skripte zum Testen und Bereitstellen:

{
  "scripts": {
    "build": "ng build",
    "preview:cf": "npm run build && wrangler dev",
    "deploy:cf": "npm run build && wrangler deploy"
  }
}

Lokales Testen

So testen Sie Ihre Anwendung lokal vor dem Deployment:

npm run preview:cf

Dies baut Ihre Angular-Anwendung und startet den Wrangler-Dev-Server unter http://localhost:8787.

Deployment auf Cloudflare

Wenn Sie bereit sind, in die Produktion zu deployen:

npm run deploy:cf

Dies:

Baut Ihre Angular-SSR-Anwendung für die Produktion
Bündelt den Server-Code mit esbuild in den Worker
Lädt Ihre Browser-Assets zu Cloudflare hoch
Deployt Ihren Worker global über Cloudflares Netzwerk

Umgebungsvariablen und Allowed Hosts

Für Staging- oder Preview-Deployments mit anderen Domains können Sie zur Deploy-Zeit zusätzliche erlaubte Hosts angeben, ohne neu zu bauen:

NG_ALLOWED_HOSTS=staging.example.com,preview.example.com npm run deploy:cf

Die Umgebungsvariable akzeptiert kommagetrennte Hostnamen und wird zur Laufzeit mit den in angular.json definierten Hosts zusammengeführt.

Fazit

Geschafft! Sie haben jetzt ein Angular-20+-SSR-Projekt, das automatisch auf Cloudflare deployt wird, ohne zusätzliche Konfiguration innerhalb des Angular-Bereichs.

Bei Fragen oder Problemen konsultieren Sie die Angular-SSR-Dokumentation und die Cloudflare-Workers-Dokumentation.

Eine serverseitig gerenderte Angular-20+-Anwendung auf Cloudflare Workers bereitstellen