Next.js preferredRegion (deprecated)
This reference documents an officially deprecated option. It's included here for the practical reason every deprecated API reference exists: real production codebases still have it, and understanding what it did — and why it went away — matters for anyone maintaining an older Next.js project through an upgrade. If you're starting fresh, the short version is simple: don't use preferredRegion in new code, and remove it from old code when you encounter it.
What It Used to Do
preferredRegion let you specify which deployment region a route segment preferred to execute in, passing that preference through to your deployment platform:
export const preferredRegion = "iad1"; // string | string[]
- A string deployed the route to one specific region — region codes themselves were always platform-specific (Vercel's
'iad1'doesn't mean anything to a different host). - An array of strings deployed the route to all listed regions simultaneously — not one chosen from the list, all of them at once.
Inheritance followed a simple rule: an unspecified preferredRegion inherited from the nearest parent layout, cascading up to the root layout's default of 'auto'. A child segment's explicit value overrode its parent entirely rather than merging with it — setting preferredRegion on a nested page completely replaced whatever the layout above it had configured, rather than adding to it.
The Vercel-Specific Behavior
On Vercel specifically, region configuration historically only worked in combination with export const runtime = 'edge' — which is itself now deprecated (see the runtime reference for that separate deprecation). Under that now-deprecated combination, three special string values had platform-specific meaning beyond literal region codes: 'auto' (the default, using Vercel's own default region logic), 'global' (preferring deployment to all available regions), and 'home' (preferring the account's designated home region). Passing anything else unsupported threw a build error rather than silently falling back to a default.
Why It's Deprecated
The docs point directly to Next.js's official deprecation message for the full rationale, but the practical takeaway is straightforward: this option was tightly coupled to the now-deprecated Edge Runtime on the one platform (Vercel) where it had genuinely rich behavior. With Edge Runtime itself deprecated, the region-preference mechanism built specifically around it no longer has a coherent place in the current App Router configuration model.
What to Do If You Have This in Your Codebase
Remove the preferredRegion export from your route files. There isn't a direct drop-in replacement within Next.js's own configuration surface — region/deployment-topology decisions, to the extent your platform supports configuring them at all, now live at the platform-configuration level rather than as a per-route Next.js export. Check your specific deployment platform's current documentation for how it handles regional deployment preferences today, since that's genuinely platform-specific and outside what this Next.js-level config option was ever able to fully control on its own.
Key Takeaways
| Aspect | Detail |
|---|---|
| Status | Deprecated — remove it from route files |
| Historical values | A region string, or an array for multi-region deployment |
| Inheritance | Unset values inherited from the nearest parent layout; child values overrode rather than merged |
| Vercel-specific history | Special 'auto'/'global'/'home' values only worked alongside the now-deprecated Edge Runtime |
| Migration path | No direct Next.js replacement — check your deployment platform's current region-configuration docs |
The lesson worth carrying forward from this specific deprecation: configuration options tightly coupled to one platform's specific runtime model (here, Vercel's Edge Runtime) are exactly the kind of App Router feature most likely to get deprecated as that underlying model evolves. If you're building on infrastructure-adjacent config today, it's worth checking whether it's a genuinely portable, framework-level concept or a thin pass-through to one platform's current implementation details.
