Preview environments for Laravel + Next.js

Either works. We run your declared build (next build) and start the Node server, so whether you fetch data in App Router Server Components and route handlers or in getServerSideProps / API routes under the Pages Router, the preview behaves the same. The defaults below assume the App Router because that is where most new Laravel + Next teams are, but nothing here is App-Router-only.

Server Components and route handlers render inside the Node process on the same VPS as the API, so they call the API over an internal base URL — set a server-only variable such as API_INTERNAL_URL (e.g. http://127.0.0.1:8000) and read it in your server code. The browser never sees that value; client components use NEXT_PUBLIC_API_URL, which we point at the environment’s public HTTPS origin. Two URLs, one for the server hop and one for the browser, both injected automatically.

Each preview is a brand-new Node server with an empty Next data cache, so the first request to an ISR or revalidate route renders fresh against that environment’s seeded database — there is no stale cache carried over from another branch or from production. On-demand revalidation (revalidatePath / revalidateTag) and route handlers work normally, and the whole cache is discarded when the environment tears down.

We recommend it. With output: "standalone" in next.config, next build emits a self-contained .next/standalone server you can boot with node server.js — smaller, faster to start and well suited to running as the long-lived Node process behind the preview’s HTTPS URL. If you do not set it we simply run next start instead; both are supported.

Both patterns are covered. For token auth (JWT), the Next server attaches the bearer to its internal API calls and the browser stores/sends it as you already do. For Sanctum cookie auth, the API and frontend share the environment’s domain, so first-party cookies and CSRF flow cleanly; set SANCTUM_STATEFUL_DOMAINS and the session domain to the generated host, which we expose in the env. No third-party-cookie workarounds needed.

With the API. Each environment gets its own isolated MySQL or PostgreSQL instance that we migrate with php artisan migrate and seed on first boot, plus Redis for cache, sessions and queues. The Next.js service never talks to the database directly — it only ever calls the Laravel API, exactly like production.