Laravel or NestJS for a new backend

A greenfield service, nothing inherited, two reasonable answers. The comparisons online mostly list what both can do, which is nearly everything, and therefore decide nothing.

Here is what differs.

One ships infrastructure, the other ships structure

This is the real distinction and it is not close.

Laravel ships the infrastructure. Authentication, password resets, queues with retries and a failed-jobs table, a scheduler, mail with templates and drivers, a file storage abstraction, validation, an ORM with migrations, events, broadcasting, rate limiting. First-party, documented together, tested together, upgraded together.

NestJS ships the structure. Modules, dependency injection, a request pipeline, a clear way to organise code. Everything else you select and assemble yourself: Passport or your own JWT handling, BullMQ for queues, a cron library, a mailer, an ORM.

For the common shape of product — users, an admin area, background work, scheduled reports, notifications — Laravel's head start is measured in weeks, and they are weeks of work nobody finds interesting. For a service whose job is narrow, that same bundle is mostly things you will never call.

One language, and what that is actually worth

The strongest argument for NestJS is not the framework. It is that the server speaks the same language as the browser.

export type CreateLead = { source: "web" | "phone"; name: string; phone: string };
export type LeadResponse = { id: number; status: "new" | "contacted" | "won" | "lost" };

Imported by both the API and the front end. Change the contract and the front end's build fails at compile time, in CI, before anyone deploys it.

With a PHP backend you get there through an OpenAPI schema and generated clients. That works. It is also a generation step that can be skipped, run against the wrong branch, or drift quietly for a week. Not a disqualifier, but a real difference in how much of your correctness the compiler is willing to own.

Operations differ more than the code does

PHP-FPM handles a request and the process state goes away. No memory accumulates between requests, a leak is bounded by a single request, and the deployment model is ancient in the good sense: well understood, well documented, hard to surprise.

A Node service is one long-running process. Faster for workloads that benefit from warm state and persistent connections, and also perfectly capable of holding a leaked reference for as long as it runs. That failure mode is real and has its own investigation procedure, which I went through in finding a Node memory leak in production.

Neither is hard to run. The question is which one your team already runs, because the second platform is always the one that gets neglected.

The conditions that settle it

Take Laravel when the product needs the standard set and you would rather configure it than assemble it, when the team knows PHP or you hire somewhere PHP hiring is strong, and when you want queues, scheduling and mail working on day one instead of week three.

Take NestJS when the team is already TypeScript including the front end, when shared contracts between client and server are worth real money on this particular product, when the service is primarily real-time or streaming or websocket-heavy, or when you are deep enough in the JavaScript ecosystem that one toolchain is worth something on its own.

And take whichever you already run when the honest answer is that both fit, which is most of the time. A second runtime in a small team costs more than either framework saves: two deployment paths, two dependency-update habits, two sets of production instincts, and one of them always stale.

Three arguments that are not arguments

Raw performance does not. Both are far faster than the database call sitting in the middle of the request, and the number that moves your p95 is the query plan. Learning to read one is better-spent effort than any benchmark of the HTTP layer.

"PHP is legacy" does not either. It is typed, fast and actively developed. The honest version of that concern is ecosystem direction: new libraries, particularly around AI tooling, tend to appear in JavaScript and Python first, and that is a real thing to weigh if you expect to need them.

Framework structure does not decide it either. NestJS's module system is genuinely good and Laravel imposes nothing comparable, but a disciplined Laravel codebase and a NestJS codebase end up organised similarly. The comparison between the two Node options is a separate question with its own answer.

Keep the choice reversible

Whatever you pick, the thing that keeps the decision cheap is the same.

HTTP layer        controllers / routes — translation only
Application       plain classes, no framework imports
Data access       a repository with an interface

Keep the domain in classes that import nothing from the framework and a migration later is a rewrite of the thin outer layer rather than of the product. Keep business logic in controllers and the framework stops being a choice and becomes a cage, which is the same failure mode in either language.

Where I land

Laravel is the faster path to a complete product, because the boring infrastructure is already in the box and assembling it yourself buys you nothing a user will notice.

NestJS is the better fit when the team is TypeScript end to end and shared contracts are worth real money.

Most of the time, though, the deciding input is neither framework. Run what your team already knows how to operate at 3am. Then keep the domain logic in plain classes, and the answer you did not pick stays available.