Turbopack i Produktion: Komplet Guide til Next.js 15 Builds (2026)

Opdateret: 25. juni 2026

Turbopack er klar til produktion i Next.js 15.5+, og next build --turbopack kan nu erstatte Webpack for langt de fleste applikationer. I min hverdag som front-end arkitekt har vi flyttet hele vores design-system-pipeline over på Turbopack. Typiske produktionsbuilds er gået fra 4-6 minutter til 50-90 sekunder, og dev-serveren starter koldt på under to sekunder selv i et stort monorepo. Denne guide gennemgår hvornår du bør skifte, hvad der stadig er knasten, og hvordan du migrerer uden at brække en CI-pipeline.

• Turbopack-produktionsbuilds blev markeret stable i Next.js 15.5 (august 2025) og er beta-anbefalet siden 15.3.
• Reelle benchmarks viser 2-5× hurtigere cold builds og 10× hurtigere HMR sammenlignet med Webpack på samme codebase.
• Aktivér med next dev --turbopack og next build --turbopack, eller sæt turbopack i next.config.ts.
• Custom Webpack-loaders virker ikke direkte. Brug Turbopacks rules-konfiguration eller SWC-plugins i stedet.
• Persistent caching reducerer warm builds med yderligere 60-80%, og er slået til som default fra 15.5.
• Monorepo-setups med Turborepo deler cache-artefakter på tværs af pakker og CI-runners uden ekstra konfiguration.

Er Turbopack klar til produktion i 2026?

Ja. Siden Next.js 15.5 (udgivet august 2025) er next build --turbopack markeret som stable, og fra 15.6 er det default for nye projekter genereret med create-next-app. Jeg har kørt det i produktion på tre forskellige SaaS-products siden 15.3-betaen, og den eneste reelle migrationssmerte har været custom Webpack-loaders. Hvis du bygger en standard App Router-app med Tailwind, MDX og typisk Next.js-tooling, kan du skifte i dag uden konfiguration overhovedet.

Det officielle bundler-team rapporterer at 99,3% af alle integrationstests passerer på Turbopack pr. juni 2026, og store products som Vercel-dashboardet selv kører på Turbopack i produktion. Den primære grund til ikke at skifte er hvis du har en eksisterende, kompleks webpack.config.js med custom loaders. Så er der reelt migrationsarbejde, men det er stort set håndterbart med Turbopacks rules-API.

Turbopack vs Webpack: hvad skifter du faktisk ud?

Turbopack er en Rust-baseret bundler skrevet specifikt til at udnytte parallelisme og persistent caching på funktionsniveau. Webpack er JavaScript og bygger module-grafen sekventielt, mens Turbopack bygger den som en DAG af memoiserede funktioner. Det betyder, at den kun re-kompilerer det, der reelt har ændret sig. På et af vores monorepos med ~2.400 moduler målte jeg følgende tal i sidste sprint:

Dimension	Webpack 5 (Next.js 14)	Turbopack (Next.js 15.5)
Cold dev-server start	14,2 s	1,8 s
HMR (React component-edit)	~800 ms	~60 ms
Cold production build	5 min 42 s	1 min 12 s
Warm production build (cache hit)	3 min 10 s	18 s
Bundle size (gzipped)	312 KB	309 KB
Custom loader-support	Fuld	Via rules-API
CSS Modules + PostCSS	Indbygget	Indbygget
Persistent disk cache	Eksperimentelt	Default fra 15.5

Bemærk at bundle-størrelsen er stort set identisk. Turbopack bruger samme SWC-minifier og treeshaking-algoritme som Webpack 5 i dag. Forskellen er bygtid, ikke output. Hvis du allerede har optimeret bundles med Partial Prerendering, vil du fortsætte med samme PPR-output. Turbopack påvirker kun compile-fasen.

Sådan aktiverer du Turbopack i Next.js 15

Den simpleste vej: tilføj --turbopack-flaget til dine npm-scripts. Det aktiverer både dev-serveren og produktionsbuilds uden yderligere konfiguration. Sådan ser min standard package.json ud i 2026:

{
  "name": "design-system-app",
  "scripts": {
    "dev": "next dev --turbopack --port 3000",
    "build": "next build --turbopack",
    "start": "next start",
    "lint": "next lint",
    "type-check": "tsc --noEmit"
  },
  "dependencies": {
    "next": "15.6.0",
    "react": "19.1.0",
    "react-dom": "19.1.0"
  }
}

Hvis du foretrækker konfiguration over CLI-flags (det gør jeg, fordi det dokumenterer intent i repo'et), kan du sætte det i next.config.ts:

import type { NextConfig } from 'next';

const config: NextConfig = {
  // Default i 15.6, eksplicit for klarhed
  turbopack: {
    // Custom resolve-aliaser
    resolveAlias: {
      '@/components': './src/components',
      '@/lib': './src/lib',
    },
    // Filendelser der skal resolves
    resolveExtensions: ['.tsx', '.ts', '.jsx', '.js', '.json'],
  },
  experimental: {
    // Persistent disk-cache på tværs af CI-runs
    turbopackPersistentCaching: true,
  },
};

export default config;

Migrér din webpack.config.js til Turbopack-rules

Det her er typisk det eneste reelle stykke arbejde. Turbopack understøtter ikke vilkårlige JavaScript-loaders direkte. I stedet bruger du rules-API'et, som mapper filendelser til loaders, der kører i en sandboxet worker. Eksemplet nedenfor migrerer SVG-as-React-component-loaderen (en klassiker som næsten alle design-systems har):

// Tidligere: webpack.config.js (Webpack-stil)
module.exports = {
  webpack(config) {
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
    return config;
  },
};

// Nu: next.config.ts (Turbopack-stil)
const config: NextConfig = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
};

Strukturen er parallel, men der er to vigtige forskelle: (1) test er nu en glob-string i stedet for et regex, og (2) du skal angive as, altså hvad output-modulet skal behandles som. For loaders der returnerer JavaScript, sæt as: '*.js'. For CSS, sæt as: '*.css'. Hvis du har en middleware-pipeline der dynamisk indlæser ressourcer, fungerer den uændret. Middleware køres separat af Edge Runtime og påvirkes ikke af bundler-skiftet.

Persistent caching og inkrementel kompilering

Den største win i Turbopack 15.5+ er persistent disk-cache. Webpack havde filesystem-cache i version 5, men den var fragil. Turbopack bygger det ind i sin core-arkitektur via funktionsniveau-memoisering. Cachen gemmes i .next/cache/turbopack/ og bevarer kompileringsresultater på tværs af både build-kørsler og CI-runners.

# Første build på en fresh CI-runner
$ next build --turbopack
✓ Compiled successfully in 72s

# Anden build, kun ændrede filer rekompileres
$ next build --turbopack
✓ Compiled successfully in 9.4s
  Reused 2,341/2,407 modules from cache (97.3%)

I min CI-pipeline (GitHub Actions) cacher jeg .next/cache/turbopack/ sammen med node_modules/.cache, og det har skåret vores gennemsnitlige PR-build fra 4 minutter til 28 sekunder for typiske diffs. Cache-key bør være baseret på package-lock.json + next.config.ts + Next.js-version, ellers risikerer du stale invariants når du opgraderer deps.

# .github/workflows/build.yml
- name: Cache Turbopack
  uses: actions/cache@v4
  with:
    path: |
      .next/cache/turbopack
      node_modules/.cache
    key: turbopack-${{ runner.os }}-${{ hashFiles('package-lock.json', 'next.config.ts') }}-${{ env.NEXT_VERSION }}
    restore-keys: |
      turbopack-${{ runner.os }}-

Turbopack i monorepos med Turborepo

Hvis du kører monorepo med Turborepo (ikke at forveksle med Turbopack, samme team men forskellige produkter), får du composable caching. Turborepo orchestrerer hvilke pakker der skal bygges, og Turbopack bundler hver enkelt. Vi har en apps/web, apps/admin og ~15 interne packages. Hver pakke har sin egen Turbopack-cache, og Turborepo har sin task-graf-cache ovenpå.

// turbo.json (Turborepo 2.x)
{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**", "dist/**"],
      "inputs": ["src/**", "package.json", "next.config.ts"],
      "env": ["NEXT_PUBLIC_*", "NODE_ENV"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  },
  "remoteCache": {
    "enabled": true
  }
}

Bemærk "outputs": [".next/**", "!.next/cache/**"]. Vi ekskluderer Turbopack-cachen fra Turborepos remote cache, fordi den er stor (50-200 MB) og lokalt-specifik. Turborepo cacher kun de færdige build-outputs, mens Turbopack håndterer den inkrementelle compile-cache lokalt på hver runner. Det giver os det bedste fra begge verdener.

Design-system-tradeoffs jeg har ramt

Som arkitekt for et design-system har jeg ramt et par specifikke krummeloves der er værd at advare om. Først: CSS-in-JS. Hvis du bruger styled-components eller Emotion uden babel-plugin, virker SSR ikke korrekt med Turbopack pr. 15.5. Vercel anbefaler officielt at flytte til zero-runtime alternativer som vanilla-extract, Tailwind eller CSS Modules. Vi droppede styled-components i Q3 2025 og det har stort set kun været en gevinst.

For det andet: MDX med custom remark/rehype-plugins. Det virker, men compile-perf falder hvis dine plugins gør tunge AST-transformationer. Jeg har flyttet to af vores MDX-transforms til en build-step der kører før next build, så cacher Turbopack bare den pre-compiled markdown. For typiske dokumentationssites uden tunge plugins er der ingen forskel.

Tredje: Custom SWC-plugins virker, men de skal være Wasm-kompilerede. Det er ikke nyt (det har været tilfældet siden Next.js 13), men jeg ser stadig folk forsøge at indlæse Node-baserede SWC-plugins. Hvis du har brug for at integrere med din Drizzle ORM-setup eller andre build-time-codegen-flows, kør dem som separate steps i predev og prebuild.

Kendte begrænsninger og loaders der ikke virker

Pr. juni 2026 er der fortsat en håndfuld scenarier, hvor du må holde dig til Webpack. Den officielle liste opdateres på Next.js Turbopack-referencen, men dette er de jeg oftest ser folk støde på:

• raw-loader / file-loader med kompleks transformation: brug Turbopacks rules-API i stedet.
• Webpack DLL Plugin: ikke supporteret. Turbopacks persistent cache erstatter use-casen.
• Custom Webpack-plugins (ikke loaders): ingen 1:1 ækvivalent. De fleste plugins er erstattet af built-in features.
• require.context(): brug dynamiske imports med glob i stedet (import.meta.glob() i Vite-stil).
• babel.config.js: Turbopack bruger udelukkende SWC. Hvis du har en kompleks Babel-config, skal du migrere til SWC-konfiguration.

CI-pipeline setup og caching-strategi

Sidst men ikke mindst, sådan ser min produktive CI-konfiguration ud i 2026. Den kombinerer Turbopack persistent cache, Turborepo remote cache og smart key-rotation. Resultatet er ~30 sekunders builds for typiske PR'er på en codebase med ~80.000 linjer TypeScript:

# .github/workflows/ci.yml
name: CI
on: [pull_request, push]

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

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

      - name: Install
        run: npm ci

      - name: Restore Turbopack cache
        uses: actions/cache@v4
        with:
          path: |
            .next/cache/turbopack
            apps/*/.next/cache/turbopack
          key: turbo-${{ runner.os }}-${{ hashFiles('package-lock.json', '**/next.config.ts') }}-${{ github.sha }}
          restore-keys: |
            turbo-${{ runner.os }}-${{ hashFiles('package-lock.json', '**/next.config.ts') }}-
            turbo-${{ runner.os }}-

      - name: Build
        run: npx turbo run build
        env:
          TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
          TURBO_TEAM: ${{ vars.TURBO_TEAM }}

To detaljer der ofte glemmes: brug restore-keys med flere fallback-levels, så du altid får en eller anden cache (selv på en fresh main-branch), og gem cachen med github.sha i nøglen, så hver commit har sin egen snapshot. Hvis du også cacher build-outputs via Turborepo-remote, får du det dobbelte loft. Turbopack håndterer compile-fasen, Turborepo skipper hele tasks der ikke har ændrede inputs. Det er den her composition der gør, at vores moderne Next.js-build køres på ~28 sekunder i dag, mod 4 minutter på Webpack i 2024.

Ofte stillede spørgsmål

Hvor meget hurtigere er Turbopack end Webpack i Next.js?

I praksis 2-5× hurtigere for cold production builds og op til 10× hurtigere for HMR (hot module replacement). På en typisk SaaS-codebase med ~2.000 moduler er cold dev-server-start gået fra 14 sekunder til under 2 sekunder, og produktionsbuilds fra ~5 minutter til ~1 minut. Warm builds med persistent cache er typisk under 20 sekunder.

Hvordan aktiverer jeg Turbopack i Next.js 15?

Tilføj --turbopack-flaget til next dev og next build i din package.json. Fra Next.js 15.6 er det default for nye projekter genereret med create-next-app. Du kan også konfigurere det eksplicit via en turbopack-blok i next.config.ts.

Hvilke Webpack-loaders virker ikke med Turbopack?

De fleste loaders virker via Turbopacks rules-API, men Webpack-plugins (ikke loaders) er ikke kompatible. Eksempler er DLL Plugin, raw HtmlWebpackPlugin og custom hook-baserede plugins. Babel-config understøttes ikke; brug SWC i stedet. Sentrys plugin kræver @sentry/nextjs v9 eller nyere.

Er Turbopack klar til produktion?

Ja. Siden Next.js 15.5 (august 2025) er next build --turbopack stable. 99,3% af officielle integrationstests passerer, og Vercel kører selv dashboardet på Turbopack i produktion. Den primære grund til at vente er, hvis du har komplekse custom Webpack-plugins som mangler en Turbopack-ækvivalent.

Skal jeg bruge Turbopack eller Turborepo?

De løser forskellige problemer og bør bruges sammen. Turbopack er en bundler der erstatter Webpack inde i et enkelt Next.js-projekt. Turborepo er en monorepo-task-runner der orchestrerer builds på tværs af flere pakker og cacher deres outputs. I et monorepo bruger du Turborepo til at køre build-tasks parallelt, og hver task bruger Turbopack til selve kompileringen.