7 min read / , ,

Why I Moved Everything from Laravel to Next.js

TLDR I moved my whole portfolio from Laravel to Next.js for one language end to end, React Server Components, and edge deploys, after a falling-out with the Laravel ecosystem made the decision easier.

I spent years building on Laravel. It was my default for everything: side projects, client work, my own apps. I knew it deeply, I contributed to it, and I genuinely liked it. Then over the past year I moved my entire portfolio off Laravel and onto Next.js. Every project. Better Auth instead of Laravel's auth, Prisma and Postgres instead of Eloquent, Stripe wired in directly, deployed on Cloudflare and a self-hosted Coolify box instead of a PHP host.

This is not a "Laravel is dead" post. Laravel is excellent and still the right tool for plenty of teams. This is the honest version of why I, specifically, moved, including a personal reason I'll be upfront about. If you are weighing the same migration, I want you to be able to use my reasoning, not just my conclusion.

The technical case

Let me start with the part that is purely about engineering, because that is the part you can actually borrow.

One language, end to end

This is the big one. With Laravel and a React frontend, I was writing PHP on the server and TypeScript in the browser, and constantly translating between them. Two type systems, two sets of conventions, two mental contexts I had to switch between dozens of times a day. Validation rules in PHP, then again in the form. An Eloquent model shape in PHP, then a hand-maintained TypeScript interface that mirrored it and drifted out of sync the moment I forgot to update it.

On Next.js it is TypeScript from the database query to the rendered button. The type that comes out of a Prisma query flows through a Server Component into the markup, and if I change the shape of the data, the type error shows up at every place that consumed it. One language, one type system, one set of habits. The cognitive saving is larger than I expected. I stopped paying the context-switch tax.

React Server Components

I rebuilt FragHub, a data-heavy stats site, on the App Router specifically for React Server Components, and that experience sold me on the model. Components run on the server by default, fetch data directly, and ship HTML. No separate API layer, no client fetch hooks for content that just needs to render, and crucially, crawlers get real content in the initial HTML instead of an empty shell. I wrote that rebuild up separately, but the short version is that RSC closed the gap between "interactive React app" and "server-rendered, indexable pages" without the usual bolt-on machinery. Laravel with Inertia gets you part of the way, but RSC is a cleaner model for the kind of content sites I build.

Edge and serverless deploys

My portfolio is a lot of small apps, not one big one. Laravel wants a persistent PHP process and, realistically, a server to babysit. Next.js fits the way I actually deploy now: some apps go to Cloudflare Workers and Pages and run at the edge with no server to maintain, others run as containers on a Coolify box behind a Cloudflare Tunnel. Static marketing sites are a static export to a CDN. The deployment target can match the app instead of every app needing the same PHP host. For a fleet of small projects at zero or low traffic, that flexibility is worth a lot, and the edge options are genuinely cheaper to run.

The React ecosystem

I was already writing React for every frontend. Moving the whole stack into that ecosystem meant the component libraries, the rendering model, the tooling, and the deployment platforms all assume the thing I am already doing. Better Auth for authentication, Prisma for the database, Stripe's well-supported JavaScript SDKs, all first-class citizens in this world. Fewer adapters, fewer "how do I bridge PHP and JS for this" problems. The pieces are designed to fit together.

The honest counterpoints

I am not going to pretend this is one-sided. Laravel still wins on real things:

  • Batteries included. Laravel hands you queues, a scheduler, migrations, auth, and a mature ORM out of the box. On Next.js I assembled equivalents myself: Better Auth, Prisma, a job runner. That is more decisions and more wiring.
  • Eloquent is lovely. Prisma is good, but Eloquent's ergonomics for complex queries and relationships are genuinely excellent, and I miss them sometimes.
  • Stability. The Laravel upgrade path is calm and predictable. The React and Next.js world moves faster and asks more of you to keep up.

If you are a team that values convention and a stable, complete framework, Laravel is a defensible choice and may be the better one. The migration only pays off if the things I listed above, one language, RSC, edge deploys, the React ecosystem, are things you actually want.

The personal reason, stated plainly

There is a personal reason too, and I would rather name it than pretend the decision was purely technical.

I contributed a large volume of pull requests to Laravel's open-source projects. Real fixes, tested and verified, the kind of work I write up on this site. That contribution did not land the way I hoped. A batch of my PRs were rejected and flagged as spam. Whatever the intent on the other side, the experience soured me on the ecosystem and on building my work on top of its paid projects. I am not going to relitigate the specifics or point fingers. People made their calls, I made mine.

What I will say is that it changed the calculus. When you have invested years in a tool and given back to its community, that relationship is part of why you stay. When that relationship breaks, the technical reasons to move that were always there, the ones above, suddenly had nothing emotional holding them back. So I moved.

I am keeping this measured on purpose. I do not think the people involved are bad people, and I am not interested in a feud. But I would be lying if I framed the migration as purely a clean-room technical evaluation. The falling-out lowered the cost of leaving, and the technical case did the rest.

What I'd tell a developer weighing the same move

If you are sitting where I was, here is the practical version.

Do it if you are already writing React for your frontends, you want one language and one type system across the stack, your projects are content-heavy and need to be indexed (RSC genuinely helps here), and you want flexibility in where you deploy, including the edge. The end-to-end TypeScript story alone is worth the move for a solo developer juggling many projects.

Think twice if you rely on Laravel's batteries-included completeness, your team is productive and happy with the convention-over-configuration model, or your app is a large monolith where a stable, opinionated framework is a feature, not a constraint. You will be re-assembling things Laravel gives you for free, and that is real work.

Either way, migrate one project first. I did not big-bang the whole portfolio. I rebuilt one app, learned the boundaries of Server Components, hit the caching surprises, wired up Better Auth and Prisma and Stripe once, and then carried the patterns forward. By the third project the stack was muscle memory. Do not commit your whole portfolio to a stack you have not shipped one real app on.

I am happy with the move. Not because Laravel is bad, it is not, but because Next.js fits how I build today: one language, server-rendered content that crawlers can see, and deploys that match each app instead of forcing every app into the same shape. The personal chapter made it easier to leave. The engineering made it worth staying gone.