Should I migrate my Next.js directory to OpenNext, Vinext, or TanStack for Cloudflare?
Asked by
MellowPine42
I run a directory that currently covers one country and want to expand it to multiple countries. The app uses Next.js and includes authentication, sign-up, reviews, bookmarks, and other user-generated features. It is currently hosted on a Singapore VPS, but I would prefer not to rent separate servers for each region or move the whole project to AWS. Cloudflare Workers seems attractive, although OpenNext and Vinext still appear relatively immature for production. I'm also considering TanStack and RedwoodSDK. Since most directory pages change infrequently, would migrating improve performance and simplify international hosting, or would it be better to keep the current setup?
Answers
Your current architecture may already be enough: one VPS, cached pages, and Cloudflare as the global layer. The directory content sounds ideal for ISR or long-lived edge caching, while user features can remain behind normal API endpoints. If you eventually move to Workers, pay close attention to authentication, session storage, database latency, and framework compatibility rather than focusing only on rendering speed.
Reply to this answer
The newer runtimes can work, but the migration risk may not be worth it for this application. One developer moved a Next.js app to Vinext and Cloudflare with relatively little effort, but complex sites and features such as partial prerendering can still be troublesome. OpenNext may be a safer option, while TanStack could be considered if you’re already planning a larger rewrite.
Reply to this answer
I wouldn’t migrate the whole app yet. Keep Next.js on the existing VPS and put Cloudflare in front as a CDN. A single server can serve users in multiple countries, especially when mostly static directory pages are cached at the edge. Keep reviews, bookmarks, and other user actions as centralized database-backed requests. Add a country field to your data model rather than deploying a separate app for each country.
Reply to this answer
First measure where the slowness actually comes from. If public pages are slow, cache country and listing pages at the edge with suitable revalidation. If reviews, bookings, or sign-ups are slow, those requests may still be waiting on the same centralized database, so moving rendering closer to users won’t eliminate that round trip. Test the app from the countries you plan to support using ordinary mobile connections before changing frameworks.
Reply to this answer
Add your answer
Answers are reviewed before publication.
SilverCactus28: That’s especially important for authentication and writes. Edge-rendering can help page delivery, but sessions, database access, and consistency still need a clear regional strategy.