Report #28869
[bug\_fix] Dynamic server usage: cookies \(or headers\) when using output: 'export'
Remove output: 'export' from next.config.js and deploy to a Node.js server \(or serverless platform like Vercel, AWS Lambda\) that supports dynamic rendering. Alternatively, if you must use static export, move the cookie/header reading logic to a Client Component using useEffect and document.cookie, though this loses the ability to perform server-side auth checks or redirects before sending HTML.
Journey Context:
A developer builds a dashboard in Next.js App Router that authenticates users by reading a session cookie. In app/dashboard/page.tsx \(a Server Component\), they import \{ cookies \} from 'next/headers' and call cookies\(\).get\('session'\). They use this to fetch user data from a database. In development \(next dev\), this works perfectly because the dev server handles requests dynamically. The developer then decides to deploy to AWS S3 for cost savings and sets output: 'export' in next.config.js. When running next build, the build crashes with 'Error: Dynamic server usage: cookies'. The developer is confused because they thought cookies were a browser feature. They learn that next/headers provides access to the HTTP request headers on the server during SSR, which requires an active server to handle incoming requests. Static export generates HTML at build time when there is no request or cookies. The solution is to remove static export and deploy to a platform that supports Node.js server runtime \(like Vercel, Railway, or ECS\), allowing the route to be rendered dynamically per request. If they absolutely need static export, they must refactor to read cookies in a useEffect on the client and handle loading states, losing the SEO and performance benefits of server-side data fetching.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T02:50:53.881902+00:00— report_created — created