Laravel in 2026: still a good choice?

Yes, for most web applications and SaaS products Laravel is a good choice in 2026. The framework gets a new major version every year with a fixed support window, PHP is actively maintained, and one project gives you what an ordinary web application needs. It is less convenient when your whole team already writes TypeScript, or when your product is mostly data and AI work.

What Laravel does well

Laravel ships with a lot: an ORM, migrations, queues, scheduled tasks, mail, notifications and authentication. A small team can get a working product out quickly without first choosing ten separate packages and wiring them together.

Every Laravel project also looks like the next one. A new developer knows where the controllers, jobs and policies live. In a distributed team that cuts onboarding time and makes reviews easier.

The framework keeps up, too. Laravel 13 came out on 17 March 2026 with a first-party AI SDK for text generation, agents and embeddings, and with vector search on PostgreSQL using pgvector. The official starter kits come in React, Vue, Svelte and Livewire flavours. The React kit uses Inertia, React 19, TypeScript and Tailwind. So you can build a modern frontend and keep the backend in Laravel.

The release cycle

Laravel releases a new major version every year, around the first quarter. Each version gets 18 months of bug fixes and 2 years of security fixes. Bug fixes for Laravel 12 ended on 13 August 2026; security fixes continue until 24 February 2027. Laravel 13 requires PHP 8.3 or later.

PHP itself gives each version two years of active support followed by two years of security fixes only. For PHP 8.2 those end on 31 December 2026.

My advice is to plan the yearly Laravel upgrade as regular work, so it does not become a project you keep postponing. Check now which Laravel and PHP versions run in production. If you are on Laravel 12 or PHP 8.2, you have a few months left.

How I would set up a new Laravel project

• The latest Laravel version on a supported PHP version, the same locally and in production.
• Postgres as the database if you expect search features or vectors. Otherwise MySQL is fine too.
• Static analysis with PHPStan or Larastan, and Pint for code style, both in CI.
• Tests with Pest or PHPUnit for every API route and every job.
• Anything slow, such as mail, exports and calls to external APIs, goes into a queue.
• Model::preventLazyLoading() switched on outside production, so an N+1 query throws an error in development instead of becoming a slow page in production.

Hosting needs little: PHP behind a web server, one or more queue workers, and a cron entry that runs the scheduler every minute. That works as well in a Docker container as on a plain VPS. Do make sure the workers restart after every deploy, or they keep running the old code.

Where Laravel fits less well

If your whole team writes TypeScript and wants to share types between frontend and backend, one language is simpler. In that case you are more likely to end up with Next.js, TypeScript and Postgres.

If your product is mostly model training, data pipelines or heavy computation, that work belongs in Python. Laravel can still be the web application around it.

With many long-lived realtime connections, the classic PHP model, where every request starts fresh, is a weaker fit. Laravel has its own answers for that, but test them under your real load before you commit.

Finding and assessing developers

There is no shortage of candidates. In the 2025 Stack Overflow Developer Survey almost 19 percent of respondents used PHP and about 9 percent used Laravel. PHP is also easy to start with, so the level varies a lot.

So test for what sets an experienced Laravel developer apart. Does the candidate know the framework's conventions? Do they write tests, know when something belongs in a queue, and spot an N+1 query? Ask them to review an existing controller, which tells you more than an algorithm puzzle.

We work with Laravel ourselves. For Zibber, a real estate photography platform built on Laravel and Vue, we reviewed the existing technical setup and tackled performance and scalability bottlenecks. Our technology page lists the other stacks we work with.

Older Laravel applications

If you still run a Laravel 8 or older application that has not been touched in years, that is your biggest risk, because those versions stopped receiving security fixes long ago. Upgrade one version at a time, and put tests on the most important flows before you start.

That kind of work needs developers who know both old and new Laravel. Maarten covers how to find and keep them in finding developers for older stacks.

Sources

• Laravel 13.x: Release Notes
• Laravel 13.x: Starter Kits
• Laravel 13.x: Eloquent Relationships, Preventing Lazy Loading
• PHP: Supported Versions
• Stack Overflow Developer Survey 2025: Technology