Nx mit Claude Code: Enterprise Monorepo-Management 2026

Nx Claude Code Monorepo Angular React Node.js TypeScript Enterprise CI/CD

Enterprise-Softwareprojekte wachsen schnell. Aus einem einzelnen Angular-Frontend werden zehn Micro-Frontends, drei Node-APIs, eine geteilte Design-System-Bibliothek und ein Dutzend Utility-Packages. Genau hier entfaltet Nx seine volle Stärke — und Claude Code beschleunigt den Umgang mit dem mächtigen Toolset erheblich.

Dieser Artikel zeigt, wie du Nx in einer Enterprise-Umgebung 2026 einsetzt: von der Workspace-Konfiguration über Custom Generators und Executors bis hin zu Remote Caching und strikten Module Boundaries. Claude Code fungiert dabei als intelligenter Co-Pilot, der Boilerplate generiert, Konfigurationen versteht und Refactorings über Tausende von Dateien durchführt.

Inhalt

Nx Grundlagen & Workspace-Struktur
Generators & Schematics
Custom Executors
Affected Commands & CI-Optimierung
Module Boundaries & Dependency Enforcement
Remote Cache & Nx Cloud

1. Nx Grundlagen & Workspace-Struktur

Nx ist ein Smart Build System, das Monorepos mit mehreren Frameworks verwaltet. Im Gegensatz zu reinen Package-Manager-Workspaces (npm/yarn workspaces) versteht Nx die semantischen Abhängigkeiten zwischen Projekten und kann gezielt nur die betroffenen Teile neu bauen oder testen.

🗂️

Workspace Graph

Nx analysiert statisch alle Imports und erstellt einen vollständigen Dependency-Graphen.

⚡

Computation Cache

Outputs werden gecacht. Identische Inputs = kein Rebuild. Lokal und remote.

🎛️

Plugin-Ökosystem

Plugins für Angular, React, Next.js, NestJS, Vite, Jest, Playwright und mehr.

🤖

Claude Code Integration

Claude versteht nx.json, project.json und generiert konforme Konfigurationen automatisch.

Workspace anlegen & Struktur

Ein neues Enterprise-Monorepo erstellst du mit:

# Neues Nx Workspace (integrated preset)
npx create-nx-workspace@latest enterprise-mono \
  --preset=ts \
  --nxCloud=yes \
  --workspaceType=integrated

# Typische Verzeichnisstruktur
enterprise-mono/
├── apps/
│   ├── admin-portal/          # Angular App
│   ├── customer-web/          # React App
│   └── api-gateway/           # NestJS API
├── libs/
│   ├── shared/
│   │   ├── ui/                # Design System
│   │   ├── data-access/       # API Clients
│   │   └── util/              # Utilities
│   ├── feature/
│   │   ├── auth/              # Auth Feature
│   │   └── dashboard/         # Dashboard Feature
│   └── domain/
│       └── user/              # Domain Models
├── nx.json
├── package.json
└── tsconfig.base.json

nx.json — Workspace-Konfiguration

Die zentrale nx.json steuert Task-Pipeline, Caching und Plugin-Verhalten. Claude Code kann diese Datei direkt lesen und Anpassungen vorschlagen:

{
  "$schema": "./node_modules/nx/schemas/nx-schema.json",
  "nxCloudId": "my-workspace-cloud-id",
  "defaultBase": "main",
  "namedInputs": {
    "default": ["{projectRoot}/**/*", "sharedGlobals"],
    "production": [
      "default",
      "!{projectRoot}/**/?(*.)+(spec|test).[jt]s?(x)",
      "!{projectRoot}/tsconfig.spec.json",
      "!{projectRoot}/jest.config.[jt]s"
    ],
    "sharedGlobals": []
  },
  "targetDefaults": {
    "build": {
      "cache": true,
      "dependsOn": ["^build"],
      "inputs": ["production", "^production"]
    },
    "test": {
      "cache": true,
      "inputs": ["default", "^production", "{workspaceRoot}/jest.preset.js"]
    },
    "lint": {
      "cache": true,
      "inputs": [
        "default",
        "{workspaceRoot}/.eslintrc.json",
        "{workspaceRoot}/.eslintignore"
      ]
    },
    "e2e": {
      "cache": true,
      "inputs": ["default", "^production"]
    }
  },
  "plugins": [
    {
      "plugin": "@nx/eslint/plugin",
      "options": { "targetName": "lint" }
    },
    {
      "plugin": "@nx/jest/plugin",
      "options": { "targetName": "test" }
    }
  ]
}

Vergleich: Nx vs. Turborepo

Feature	Nx	Turborepo
Dependency Graph Visualisierung	✓ nx graph (interaktiv)	— (limitiert)
Custom Generators	✓ vollständig	✗ nicht nativ
Custom Executors	✓ vollständig	✗ nur Scripts
Module Boundary Enforcement	✓ ESLint Plugin	✗ manuell
Remote Cache	✓ Nx Cloud	✓ Vercel Remote Cache
Framework-Plugins	✓ 20+ offizielle Plugins	— (begrenzt)
Distributed Task Execution	✓ Nx Agents	✗ nativ nicht verfügbar

Wichtige Nx-Befehle im Überblick

# Dependency-Graphen visualisieren
npx nx graph

# Einzelnes Projekt bauen
npx nx build customer-web

# Alle betroffenen Projekte testen (seit letztem Git-Commit)
npx nx affected --target=test

# Alle Projekte parallel bauen (max 4 parallel)
npx nx run-many --target=build --all --parallel=4

# Projekt-Details anzeigen
npx nx show project admin-portal --web

# Nx Version updaten
npx nx migrate latest
npx nx migrate --run-migrations

💡 Claude Code Tipp Frag Claude Code: "Analysiere meine nx.json und erkläre, welche Tasks gecacht werden und warum." Claude liest die Konfiguration, erklärt die namedInputs und schlägt sinnvolle Optimierungen vor.

2. Generators & Schematics

Nx Generators sind das mächtigste Werkzeug für Konsistenz in Enterprise-Monorepos. Sie automatisieren die Erstellung von Projekten, Komponenten, Services und ganzen Feature-Modulen nach euren internen Standards.

GENERATOR Was Generators leisten

Standardisierte Projektstruktur für alle Teams erzwingen
Boilerplate-Code automatisch generieren (Tests, Barrel-Exports, Stories)
Konfigurationsdateien (project.json, tsconfig, jest.config) konsistent erstellen
Bestehende Dateien aktualisieren (z.B. Barrel-Index nach Komponenten-Erstellung)
Interaktive CLI-Prompts für Entwickler

Offizielle Generators nutzen

# Angular-App erstellen
npx nx generate @nx/angular:application admin-portal \
  --routing=true \
  --style=scss \
  --standalone=true \
  --directory=apps/admin-portal

# React-Library mit Vite erstellen
npx nx generate @nx/react:library shared-ui \
  --directory=libs/shared/ui \
  --bundler=vite \
  --component=true \
  --style=css

# NestJS-Ressource (CRUD) erzeugen
npx nx generate @nx/nest:resource users \
  --project=api-gateway \
  --type=rest \
  --crud=true

Custom Generator erstellen

Enterprise-Teams brauchen eigene Generators für ihre Konventionen. Hier ein vollständiger Custom Generator für ein Feature-Modul:

# Generator-Gerüst erzeugen
npx nx generate @nx/plugin:generator feature-module \
  --project=workspace-plugin \
  --directory=src/generators/feature-module

Die schema.json definiert die Eingabeparameter:

{
  "$schema": "http://json-schema.org/schema",
  "$id": "FeatureModuleGenerator",
  "title": "Feature Module Generator",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Name des Feature-Moduls",
      "$default": { "$source": "argv", "index": 0 },
      "x-prompt": "Wie soll das Feature-Modul heißen?"
    },
    "scope": {
      "type": "string",
      "description": "Scope (z.B. shared, feature, domain)",
      "enum": ["shared", "feature", "domain"],
      "default": "feature",
      "x-prompt": {
        "message": "Welchem Scope gehört das Modul an?",
        "type": "list"
      }
    },
    "withTests": {
      "type": "boolean",
      "description": "Sollen Test-Stubs generiert werden?",
      "default": true
    },
    "withStorybook": {
      "type": "boolean",
      "description": "Storybook-Stories generieren?",
      "default": false
    }
  },
  "required": ["name"]
}

Die generator.ts Implementierung:

import {
  Tree,
  formatFiles,
  generateFiles,
  updateJson,
  names,
  offsetFromRoot,
  joinPathFragments,
} from '@nx/devkit';
import * as path from 'path';
import { FeatureModuleGeneratorSchema } from './schema';

export default async function (tree: Tree, options: FeatureModuleGeneratorSchema) {
  const moduleName = names(options.name);
  const projectRoot = `libs/${options.scope}/${moduleName.fileName}`;

  // Dateien aus Templates generieren
  generateFiles(
    tree,
    path.join(__dirname, 'files'),
    projectRoot,
    {
      ...options,
      ...moduleName,
      offsetFromRoot: offsetFromRoot(projectRoot),
      template: '',
    }
  );

  // tsconfig.base.json mit Path-Alias erweitern
  updateJson(tree, 'tsconfig.base.json', (json) => {
    json.compilerOptions.paths = {
      ...json.compilerOptions.paths,
      [`@enterprise/${options.scope}/${moduleName.fileName}`]: [
        `${projectRoot}/src/index.ts`
      ],
    };
    return json;
  });

  // Workspace-Graph aktualisieren (project.json setzen)
  updateJson(tree, joinPathFragments(projectRoot, 'project.json'), (json) => {
    json.tags = [
      `scope:${options.scope}`,
      `type:feature`
    ];
    return json;
  });

  await formatFiles(tree);
}

✅ Claude Code Workflow Zeige Claude Code deinen bestehenden Generator und sage: "Erweitere diesen Generator um eine Storybook-Konfiguration und generiere automatisch eine index.stories.ts Datei im Template-Ordner." — Claude analysiert die bestehende Struktur und ergänzt sie korrekt.

3. Custom Executors

Executors sind das Äquivalent zu Webpack-Plugins oder Gradle-Tasks in Nx. Sie kapseln Build-Logik, können gecacht werden und integrieren sich nahtlos in die Nx-Pipeline. Enterprise-Teams nutzen Custom Executors für spezifische Build-Anforderungen wie Docker-Images, API-Dokumentation oder Assets-Optimierung.

Wann Custom Executors sinnvoll sind

Eigene Build-Tools integrieren (z.B. internes Asset-Pipeline-System)
Docker-Image-Build mit spezifischen Labels und Registry-Logik
OpenAPI-Dokumentation aus Quellcode generieren und deployen
Datenbankmigrationen als Teil des Build-Prozesses ausführen
Custom Lint-Regeln mit Caching ausführen

Executor Gerüst erstellen

# Executor generieren
npx nx generate @nx/plugin:executor docker-build \
  --project=workspace-plugin \
  --directory=src/executors/docker-build

schema.json für den Executor

{
  "$schema": "http://json-schema.org/schema",
  "version": 2,
  "title": "Docker Build Executor",
  "description": "Baut ein Docker-Image für das Projekt",
  "type": "object",
  "properties": {
    "imageName": {
      "type": "string",
      "description": "Name des Docker-Images"
    },
    "registry": {
      "type": "string",
      "description": "Docker Registry URL",
      "default": "registry.enterprise.io"
    },
    "dockerfile": {
      "type": "string",
      "description": "Pfad zum Dockerfile",
      "default": "Dockerfile"
    },
    "push": {
      "type": "boolean",
      "description": "Image nach dem Build pushen?",
      "default": false
    },
    "buildArgs": {
      "type": "object",
      "description": "Docker Build-Arguments",
      "additionalProperties": { "type": "string" }
    }
  },
  "required": ["imageName"]
}

executor.ts Implementierung

import { ExecutorContext, logger } from '@nx/devkit';
import { execSync } from 'child_process';
import { DockerBuildExecutorSchema } from './schema';

export default async function dockerBuildExecutor(
  options: DockerBuildExecutorSchema,
  context: ExecutorContext
): Promise<{ success: boolean }> {
  const { imageName, registry, dockerfile, push, buildArgs = {} } = options;
  const projectName = context.projectName!;
  const projectRoot = context.projectsConfigurations!.projects[projectName].root;

  // Git-Hash für Image-Tag ermitteln
  const gitHash = execSync('git rev-parse --short HEAD').toString().trim();
  const imageTag = `${registry}/${imageName}:${gitHash}`;
  const imageLatest = `${registry}/${imageName}:latest`;

  // Build-Args zusammenstellen
  const buildArgsStr = Object.entries(buildArgs)
    .map(([k, v]) => `--build-arg ${k}="${v}"`)
    .join(' ');

  const buildCmd = [
    `docker build`,
    `-f ${projectRoot}/${dockerfile}`,
    `-t ${imageTag}`,
    `-t ${imageLatest}`,
    buildArgsStr,
    `--label "nx.project=${projectName}"`,
    `--label "nx.git-hash=${gitHash}"`,
    `${projectRoot}`,
  ].filter(Boolean).join(' ');

  try {
    logger.info(`🐳 Building Docker image: ${imageTag}`);
    execSync(buildCmd, { stdio: 'inherit' });

    if (push) {
      logger.info(`📤 Pushing ${imageTag} to registry...`);
      execSync(`docker push ${imageTag}`, { stdio: 'inherit' });
      execSync(`docker push ${imageLatest}`, { stdio: 'inherit' });
    }

    logger.info(`✅ Build erfolgreich: ${imageTag}`);
    return { success: true };
  } catch (error) {
    logger.error(`❌ Docker Build fehlgeschlagen: ${error}`);
    return { success: false };
  }
}

Executor in project.json registrieren

{
  "name": "api-gateway",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "projectType": "application",
  "sourceRoot": "apps/api-gateway/src",
  "prefix": "api",
  "tags": ["scope:api", "type:app"],
  "targets": {
    "build": {
      "executor": "@nx/webpack:webpack",
      "options": { "main": "apps/api-gateway/src/main.ts" }
    },
    "docker-build": {
      "executor": "workspace-plugin:docker-build",
      "dependsOn": ["build"],
      "options": {
        "imageName": "api-gateway",
        "registry": "registry.enterprise.io",
        "push": false
      },
      "configurations": {
        "production": {
          "push": true,
          "buildArgs": {
            "NODE_ENV": "production",
            "API_VERSION": "v2"
          }
        }
      }
    }
  }
}

# Executor ausführen
npx nx run api-gateway:docker-build
npx nx run api-gateway:docker-build:production

4. Affected Commands & CI-Optimierung

Der größte Produktivitätsgewinn durch Nx in Enterprise-Umgebungen entsteht durch die Affected Commands. Nx analysiert, welche Projekte von Änderungen im aktuellen Branch betroffen sind, und führt Tasks nur für diese aus.

AFFECTED Wie Change Detection funktioniert

Nx vergleicht den aktuellen Stand mit dem defaultBase Branch (meist main). Es analysiert den Dependency-Graphen und berechnet transitiv alle betroffenen Projekte: Wenn shared-ui sich ändert, sind alle Apps betroffen, die davon abhängen.

# Alle betroffenen Projekte anzeigen
npx nx show projects --affected

# Tests nur für betroffene Projekte
npx nx affected --target=test

# Build nur für betroffene Projekte
npx nx affected --target=build

# Lint nur für betroffene Projekte
npx nx affected --target=lint

# Mehrere Targets kombinieren
npx nx affected --target=lint,test,build --parallel=3

# Gegen spezifische Basis vergleichen
npx nx affected --target=test --base=release/2.0 --head=HEAD

# Dry-run: nur ausgeben was betroffen wäre
npx nx affected --target=build --dry-run

GitHub Actions CI-Pipeline mit Affected

name: CI Pipeline

on:
  push:
    branches: [main, 'release/**']
  pull_request:
    branches: [main]

jobs:
  affected:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Vollständige Git-History für Nx

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Nx SHAs ermitteln
        uses: nrwl/nx-set-shas@v4  # Setzt NX_BASE und NX_HEAD

      - name: Lint (affected)
        run: npx nx affected --target=lint --base=$NX_BASE --head=$NX_HEAD --parallel=3

      - name: Test (affected)
        run: npx nx affected --target=test --base=$NX_BASE --head=$NX_HEAD --parallel=3

      - name: Build (affected)
        run: npx nx affected --target=build --base=$NX_BASE --head=$NX_HEAD --parallel=3

      - name: E2E (affected)
        run: npx nx affected --target=e2e --base=$NX_BASE --head=$NX_HEAD

  deploy:
    needs: affected
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Deploy affected apps
        run: npx nx affected --target=docker-build:production --parallel=2

⚠️ Wichtig: fetch-depth: 0 Ohne vollständige Git-History kann Nx nicht korrekt ermitteln, welche Commits sich geändert haben. Stelle sicher, dass fetch-depth: 0 in deiner CI-Konfiguration gesetzt ist — sonst behandelt Nx alle Projekte als betroffen.

Performance-Vergleich: Mit vs. Ohne Nx Affected

Szenario	Ohne Nx	Mit Nx Affected	Ersparnis
1 Library geändert, 12 Apps	~45 min	~8 min	~82%
1 App geändert, 12 Apps	~45 min	~4 min	~91%
Shared Util geändert	~45 min	~20 min	~56%
Mit Remote Cache (Cache Hit)	~45 min	<1 min	~98%

5. Module Boundaries & Dependency Enforcement

In einem wachsenden Monorepo entstehen schnell unerwünschte Abhängigkeiten zwischen Projekten. Module Boundaries sind das Nx-Feature, das architektonische Grenzen technisch durchsetzt. Circular Dependencies und verbotene Imports werden zur Build-Zeit erkannt — nicht erst beim Code Review.

Tag-System für Architektur-Enforcement

Jedes Nx-Projekt erhält in project.json Tags, die seine Rolle beschreiben. Der ESLint-Plugin @nx/enforce-module-boundaries prüft dann anhand von Regeln, welche Tags welche importieren dürfen.

Tags in project.json vergeben

// libs/feature/auth/project.json
{
  "name": "feature-auth",
  "tags": [
    "scope:feature",    // Welchem Scope gehört das Projekt an?
    "type:feature",    // Welchen Typ hat das Projekt?
    "platform:web"     // Für welche Plattform ist es gedacht?
  ]
}

// libs/shared/ui/project.json
{
  "name": "shared-ui",
  "tags": [
    "scope:shared",
    "type:ui",
    "platform:web"
  ]
}

// apps/admin-portal/project.json
{
  "name": "admin-portal",
  "tags": [
    "scope:app",
    "type:app",
    "platform:web"
  ]
}

depConstraints in .eslintrc.json

{
  "root": true,
  "ignorePatterns": ["**/*"],
  "plugins": ["@nx"],
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
      "rules": {
        "@nx/enforce-module-boundaries": [
          "error",
          {
            "enforceBuildableLibDependency": true,
            "allow": [],
            "depConstraints": [
              // Apps dürfen alles importieren
              {
                "sourceTag": "type:app",
                "onlyDependOnLibsWithTags": [
                  "type:feature", "type:ui", "type:data-access",
                  "type:util", "type:domain"
                ]
              },
              // Features dürfen keine anderen Features importieren
              {
                "sourceTag": "type:feature",
                "onlyDependOnLibsWithTags": [
                  "type:ui", "type:data-access",
                  "type:util", "type:domain"
                ]
              },
              // UI darf nur util und domain importieren
              {
                "sourceTag": "type:ui",
                "onlyDependOnLibsWithTags": ["type:util", "type:domain"]
              },
              // Shared Libraries dürfen nur scope:shared importieren
              {
                "sourceTag": "scope:shared",
                "notDependOnLibsWithTags": ["scope:feature", "scope:app"]
              },
              // Domain-Modelle dürfen nichts importieren
              {
                "sourceTag": "type:domain",
                "onlyDependOnLibsWithTags": ["type:util"]
              },
              // Plattform-Trennung: web darf nicht mobile importieren
              {
                "sourceTag": "platform:web",
                "notDependOnLibsWithTags": ["platform:mobile"]
              }
            ]
          }
        ]
      }
    }
  ]
}

# Boundaries prüfen (als Teil von lint)
npx nx run-many --target=lint --all

# Nur Boundary-Verletzungen prüfen
npx nx affected --target=lint --verbose

# Circular Dependencies im Graphen visualisieren
npx nx graph --focus=feature-auth

💡 Architektur-Pattern: Schichtenmodell Das Muster app → feature → ui → util/domain verhindert Circular Dependencies strukturell. Claude Code hilft dabei, bestehende Codebases auf dieses Muster umzustrukturieren und dabei alle Import-Pfade korrekt anzupassen.

Circular Dependency Detection

# Circular Deps ausgeben
npx nx graph --json | node -e "
const g = JSON.parse(require('fs').readFileSync('/dev/stdin','utf8'));
const nodes = Object.keys(g.graph.nodes);
// Einfache Cycle-Detection via DFS
// Nx Cloud Dashboard zeigt Cycles visuell an
console.log('Projekte:', nodes.length);
"

# Mit nx-graph-visualizer (Webinterface)
npx nx graph  # Öffnet Browser mit interaktivem Graph

6. Remote Cache & Nx Cloud

Der Local Cache von Nx beschleunigt bereits erheblich die lokale Entwicklung. Für Enterprise-Teams ist Remote Caching der eigentliche Game-Changer: Task-Outputs werden in der Cloud gespeichert und zwischen CI-Runs, Entwickler-Maschinen und Branches geteilt.

CACHE Remote Cache in der Praxis

Wenn Entwickler A den Build für shared-ui ausgeführt hat und Entwickler B auf demselben Commit arbeitet, bekommt B den gecachten Output sofort — ohne Build. CI-Pipelines profitieren davon besonders, weil Feature-Branches oft denselben Basis-Code teilen.

Nx Cloud einrichten

# Nx Cloud zum bestehenden Workspace hinzufügen
npx nx connect-to-nx-cloud

# Oder manuell in nx.json
# Nach dem Connect wird automatisch nxCloudId hinzugefügt

nx.json für Remote Cache konfigurieren

{
  "$schema": "./node_modules/nx/schemas/nx-schema.json",
  "nxCloudId": "your-workspace-cloud-id-here",
  "nxCloudUrl": "https://cloud.nx.app",

  // Read/Write Tokens für CI vs. Entwickler trennen
  // Entwickler: nur lesen (kein Schreiben in Cloud-Cache)
  // CI: lesen + schreiben

  "tasksRunnerOptions": {
    "default": {
      "runner": "nx-cloud",
      "options": {
        "cacheableOperations": [
          "build", "test", "lint", "e2e", "storybook"
        ],
        "accessToken": "[CI_TOKEN_FROM_ENV]"
      }
    }
  }
}

GitHub Actions mit Nx Cloud

name: CI mit Nx Cloud Remote Cache

env:
  NX_CLOUD_ACCESS_TOKEN: ${{ secrets.NX_CLOUD_ACCESS_TOKEN }}

jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

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

      - run: npm ci

      - name: Nx SHAs setzen
        uses: nrwl/nx-set-shas@v4

      - name: Start CI run
        run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js"

      - name: Run affected targets
        run: |
          npx nx affected --target=lint --parallel=3
          npx nx affected --target=test --parallel=3
          npx nx affected --target=build --parallel=3

      - name: Stop CI run
        run: npx nx-cloud stop-all-agents

Distributed Task Execution (DTE)

Nx Cloud ermöglicht es, Tasks auf mehrere Agents zu verteilen. Statt einen großen CI-Runner zu nutzen, werden Tasks auf mehrere kleine Maschinen aufgeteilt und die Ergebnisse zusammengeführt:

# Verteilung auf 3 Agents konfigurieren
npx nx-cloud start-ci-run \
  --distribute-on="3 linux-medium-js" \
  --stop-agents-after="build"

# Eigene Agent-Konfiguration in .nx/workflows/agents.yaml

distribute-on:
  default:
    agent-count: 3
    resource-class: linux-medium-js
    environment:
      NX_CLOUD_ACCESS_TOKEN: ${{ secrets.NX_CLOUD_ACCESS_TOKEN }}
      NODE_ENV: test

Self-Hosted Remote Cache

Für Unternehmen mit Datenschutz-Anforderungen gibt es Alternativen zu Nx Cloud:

# nx-remotecache-minio (MinIO/S3-kompatibel)
npm install --save-dev nx-remotecache-minio

# nx.json für MinIO
{
  "tasksRunnerOptions": {
    "default": {
      "runner": "nx-remotecache-minio",
      "options": {
        "endpoint": "minio.enterprise.io",
        "port": 9000,
        "bucket": "nx-cache",
        "accessKey": "[MINIO_ACCESS_KEY]",
        "secretKey": "[MINIO_SECRET_KEY]",
        "cacheableOperations": ["build", "test", "lint"]
      }
    }
  }
}

✅ Typische Cache-Hit-Raten in Enterprise-Projekten Mit gut konfiguriertem Remote Caching und stabilen Abhängigkeiten erreichen Enterprise-Teams Cache-Hit-Raten von 60–85%. CI-Laufzeiten reduzieren sich dadurch von 30–45 Minuten auf 3–8 Minuten. Bei 50 CI-Runs pro Tag entspricht das einer Einsparung von ~300 Compute-Stunden pro Monat.

Claude Code als Nx-Experte nutzen

Claude Code versteht den gesamten Nx-Kontext und kann komplexe Operationen durchführen:

Praktische Claude Code Prompts für Nx

"Analysiere meinen Nx Workspace Graph und identifiziere zirkuläre Abhängigkeiten"
"Erstelle einen Custom Generator für unser Feature-Modul-Pattern mit Tests und Storybook"
"Optimiere meine nx.json für maximale Cache-Effizienz"
"Migriere alle unsere Projekte von Jest auf Vitest ohne die Nx-Konfiguration zu brechen"
"Füge Module Boundary Tags zu allen 47 Projekten hinzu und erstelle die passenden ESLint-Regeln"
"Analysiere welche affected Commands für diesen PR sinnvoll sind und erkläre warum"

Nx & Claude Code im Enterprise-Einsatz testen

Starte deinen kostenlosen Trial und erlebe, wie Claude Code komplexe Monorepo-Operationen in Sekunden durchführt — Generators, Dependency-Analysen, Caching-Optimierungen und mehr.

Kostenlos testen — Trial starten

Fazit: Nx + Claude Code = Enterprise Monorepo auf Autopilot

Nx ist 2026 das leistungsfähigste Tool für Enterprise-Monorepos. Die Kombination aus intelligenter Change Detection, Custom Generators, typisierten Executors, strikten Module Boundaries und Remote Caching gibt großen Teams die Kontrolle über komplexe Codebasen zurück.

Claude Code multipliziert diese Produktivität: Es liest Nx-Konfigurationen, generiert konforme Boilerplate, refaktoriert ganze Projekte und hilft beim Debugging komplexer Build-Probleme. Kein manuelles Nachschlagen mehr in der Nx-Dokumentation — Claude kennt die APIs, Patterns und Best Practices.

⚡

Nx Affected

Bis zu 91% schnellere CI-Läufe durch intelligente Change Detection.

🏗️

Custom Generators

Konsistente Projektstruktur erzwingen — kein Abweichen von Standards möglich.

🛡️

Module Boundaries

Architektonische Grenzen technisch durchsetzen, nicht nur dokumentieren.

☁️

Remote Cache

Cache-Hits über Teams und CI hinweg — builds werden nicht zweimal ausgeführt.

Für Unternehmen, die mit wachsenden TypeScript-Codebasen kämpfen, ist die Kombination aus Nx und Claude Code kein Nice-to-have mehr — sie ist strategische Infrastruktur.