Headless WordPress + Next.js

Split is the usual arrangement, and the one this stack's defaults assume: the Next.js frontend goes to a platform built for it, and WordPress keeps a PHP-capable host of its own, with the two talking over the public REST or WPGraphQL API. Railway and Render are the options that invert that, running both halves as services under one dashboard and one bill. Go split when each layer deserves a host that does its job well, and go single-platform when fewer moving parts matter more than a best-in-class fit for either half.

That stack pairs Next.js with a CMS designed to be headless from day one, so there is no WordPress codebase anywhere in it and the content API comes either from a vendor or from a container you run yourself. This stack keeps WordPress, which is the whole point: an existing content library, an editorial team already trained on the WordPress admin, and plugins the site depends on all carry over without a migration. Choose a headless-native CMS for a new site whose editorial workflow can be designed freely, and keep WordPress when moving off it would cost more than the new frontend gains.

The frontend half stays cheap: cached pages are served from the CDN however many visitors arrive, paid tiers are billed per seat at around $20 per developer per month, and only routes that render on every request add compute charges. WordPress is where growth shows up. Every revalidation and every uncached request lands on PHP and MySQL, so a small VPS that serves a static site comfortably will need more headroom, an object cache, or a move to managed WordPress hosting once incremental regeneration starts hitting the API at volume.

Yes. The frontend is ordinary Next.js running on Node, so it also runs as a service on Railway or Render, in a container on any VPS, or on AWS or GCP. What ties an app to a platform is not the framework but the platform-only features: on-demand revalidation, image optimisation, edge middleware and preview deployments all need extra work elsewhere. Build with build-time generation and incremental static regeneration rather than leaning on those services, and a later move is a deployment change rather than a rewrite.

Yes, and it is the detail most teams notice late. Media uploaded through the WordPress admin keeps WordPress's own domain, so the frontend pulls images from the WordPress origin while the Next.js CDN caches only the HTML around them. On an image-heavy site the WordPress host ends up serving a large share of the total bytes, which is a common reason a headless rebuild feels no faster than the site it replaced. The usual fixes are a CDN in front of the uploads directory or proxying the media path through the Next.js domain.