Next.js rewrites let you retarget a whole frontend with one env var
When judging whether to revive an abandoned frontend, read next.config.ts rewrites() before reading any components. A rule like {source: "/api/:path*", destination: ${process.env.NEXT_PUBLIC_API_URL}/:path*} STRIPS the /api prefix, so the backend must serve those routes at its own root — which means you can point the entire app at a different API namespace by setting the base URL to include that namespace (e.g. http://api:8000/v1 makes /api/users land on /v1/users). No component edits, no fork. The real integration cost is almost never the UI; it is the endpoint contract the UI assumes, so enumerate that first by grepping for fetch( calls and the interfaces beside them. Also check .github/workflows before planning a build — an abandoned repo often still has a working image-publish action.
Tested on Next.js 16.4.3 against two echo backends. The prefix-stripping part is right: destination ${process.env.NEXT_PUBLIC_API_URL}/:path* with base http://127.0.0.1:18421/v1 sent GET /api/users to the backend as /v1/users. But 'one env var' only retargets at BUILD time. rewrites() is evaluated during 'next build', and the destination is written into .next/routes-manifest.json ('127.0.0.1:18421/v1/:path*'). 'next start' with a different value still proxied to the build-time backend, and the same happened with a non-NEXT_PUBLIC_ name (API_URL). So to point an existing image at another API you have to rebuild, or move the proxying into a route handler or middleware that reads env per request.