Why Laravel Is My Primary Backend Stack (Docs, Trust, and Supply-Chain Reality)

My default backend choice

When I ship a web product or an API for a Flutter app, my default stack is Laravel. That is not nostalgia for PHP. It is a practical preference for documentation quality, a coherent first-party ecosystem, and a dependency model that usually keeps my lockfile smaller and more auditable than a typical Node backend.

Choosing Laravel does not make an app “unhackable.” Supply-chain risk exists in every ecosystem. What I care about is reducing unnecessary attack surface while still shipping quickly—and being honest about where Laravel is weak.

Documentation that actually ships features

Laravel’s docs are one of the main reasons I stay. Auth, queues, mail, validation, Eloquent, jobs, broadcasting, and deployment patterns are explained in one place with conventions most Laravel apps already follow. Official docs live at laravel.com/docs.

Good docs matter for security too: fewer mystery copy-paste snippets, fewer random packages pulled in “just to finish today,” and a clearer path for the next developer (or future me) to reason about the system.

First-party packages vs micro-package culture

A large part of a typical Laravel app’s critical path comes from packages maintained by the Laravel team or long-standing PHP maintainers:

• Framework core (routing, Eloquent, validation, queues)
• Sanctum — API / SPA token auth
• Horizon — Redis queue monitoring
• Cashier — billing
• Scout — search
• Socialite — OAuth
• Reverb — first-party websockets

Composer still has community packages—of course it does—but day-to-day web needs are often covered without assembling a deep tree of tiny utilities. npm’s strength is also its risk profile: a huge registry, very small packages, and deep transitive trees. That model is productive for JavaScript, and it is why maintainer phishing and malicious republishes show up so often in security news.

Real npm supply-chain incidents (read these)

• event-stream / flatmap-stream (2018) — ownership transfer led to a malicious dependency targeting crypto wallets.
• ua-parser-js compromise (2021, Mandiant) — account hijack shipped malware via a widely downloaded package.
• chalk / debug and related packages (September 2025) — phishing-based maintainer takeover; packages with enormous weekly downloads briefly shipped wallet-hijacking code.
• Shai-Hulud and related npm campaigns (Sonatype) — credential theft and self-propagating package poisoning.

None of this means “never use Node.” I use Node for Vite and frontend tooling every day. It means I treat a large npm tree as a security surface that needs lockfiles, MFA, and skepticism.

Honest caveat: PHP and Composer are not immune

In May 2026, community Laravel translation packages under laravel-lang were hit by a git tag-rewrite style compromise. Packagist has been hardening release immutability and account security in response.

• Laravel-Lang Composer compromise (Phoenix Security)
• Packagist’s Composer supply-chain security update

My claim is narrower than “Laravel can’t get supply-chain attacked.” For the apps I build, Laravel’s first-party core plus a shorter Composer graph usually gives me a clearer trust boundary. I still commit composer.lock, prefer known maintainers for auth/payments/crypto, and treat MFA on Packagist/GitHub as mandatory.

How I lock this down day to day

1. Commit composer.lock for applications; deploy with composer install --no-dev, not casual composer update.
2. Review lockfile diffs in PRs the same way I review application code.
3. Prefer first-party Laravel packages before inventing a custom dependency graph.
4. Enable MFA on GitHub, Packagist, npm, and hosting panels.
5. After a public incident in a dependency I use: compare lockfile hashes, rebuild from known-good commits, rotate CI secrets if pipelines could have been poisoned.

Realtime was a gap—Reverb closes a lot of it

Laravel used to feel weaker than Node for websocket-heavy products. That gap is much smaller with Laravel Reverb (see also reverb.laravel.com). Install path on modern Laravel: php artisan install:broadcasting, then run php artisan reverb:start.

For some chat, gaming, or extreme concurrency designs, a dedicated Node realtime layer can still be better. Reverb means I no longer need that split for many apps that only need live notifications or dashboard updates.

Where Node is still king

• JavaScript/TypeScript frontend build pipelines and many SSR frameworks
• Edge/serverless JS runtimes
• Realtime or event-heavy services where the team already thinks in async JS
• Niche libraries that simply exist first on npm

Popularity is not a bug. My preference for Laravel is about fit for the backends I ship.

When I would not choose Laravel

• The team is entirely TypeScript and already owns a solid Nest/Fastify codebase
• The product is primarily a realtime collaborative editor or game socket farm
• You need a specific ecosystem (e.g. heavy ML serving) that is clearly Python/Go first

Stack loyalty is expensive. Laravel is my default, not my religion.

A concrete backend checklist for a new Laravel app

When I start a product backend, this is the boring sequence I follow before I invent architecture:

1. Create the project on a supported PHP version and commit the fresh tree with composer.lock.
2. Decide auth early: session (web) vs Sanctum tokens (mobile/API) vs both.
3. Turn on queues from day one even if the driver is database locally—so “email in the request” never becomes a habit.
4. Add Horizon only when Redis is real; do not pretend you need it on day one.
5. Write Form Requests for every mutating endpoint that clients will hit.
6. Keep policies next to models for anything that is not “the user only edits their own row.”
7. Document the API contract for Flutter (or any client) in one place—even a short markdown file beats tribal knowledge.

That checklist is intentionally dull. Dull backends are the ones that still work after the third feature rush.

Common objections I hear

“PHP is slow.” For typical CRUD and API products, application design dominates. I have seen slow Node apps and fast Laravel apps. Measure.

“The ecosystem is dying.” Laravel’s release cadence, first-party packages, and commercial ecosystem (Forge, Cloud, Nightwatch-style tooling depending on era) do not look like a dying stack to me. Judge by whether you can hire and ship.

“Composer is as bad as npm.” Not structurally identical. npm’s micro-package culture creates a different blast radius. Composer still needs discipline—see the laravel-lang incident—but my day-to-day critical path stays shorter.

Further reading

• Laravel 13.x documentation
• Reverb docs
• Composer basic usage (lockfiles)

How this site fits the story

This portfolio itself is a Laravel app with Vite on the frontend. That dual reality is normal: Laravel for the product server, JS tooling where the browser demands it. The point is not purity—it is putting the critical business path on a stack I can secure and maintain.