The Laravel framework: a complete overview, pros, cons and limits

What the Laravel framework is for in 2026, where it is the best choice and where plain PHP or another stack wins: Laravel 13, pros and cons, Laravel or Symfony, a comparison with Django, Rails and NestJS, examples, limits and tips.

Stack and technologies Updated

In short

Laravel is a free open-source PHP framework for web applications, created by Taylor Otwell in 2011 and the most popular in the PHP world: about 16 million installs a month on Packagist. It comes with everything a product needs — routing, the Eloquent ORM, migrations, sign-in, queues, mail, cache, a scheduler and tests — plus first-party packages for subscriptions, real time, search and monitoring. Laravel 13 (March 2026) requires PHP 8.3 and adds an AI SDK, vector search and PHP attributes for middleware and queues. It is the strongest choice for SaaS, personal accounts, admin panels on Filament and APIs built by a small team. Its costs are weight and upgrades: a simple site does not need a whole framework, and each version gets security fixes for only two years.

Laravel at a glance

The main facts in one table — where the framework came from, what is inside and how long each version lives.

Type
A full-stack PHP framework for web applications
History
Taylor Otwell, 2011; a new major version every year in the first quarter
Developed by
The Laravel company and an open community; the paid services Cloud, Forge and Nightwatch fund the work
License
MIT — free, including commercial use
Architecture
MVC, a service container, the Eloquent ORM (Active Record), Blade templates; parts are built on Symfony components
Requirements
Laravel 13 — PHP 8.3 to 8.5, Composer
Front end
Blade, Livewire 4, or Inertia 3 with React, Vue or Svelte; starter kits with sign-in ready
Latest version
Laravel 13 (17 March 2026): AI SDK, vector search, JSON:API resources, attributes like #[Middleware] and #[Tries]
Support
Bug fixes for 18 months, security fixes for 2 years; Laravel 13 — until 17 March 2028
Popularity
About 16 million installs a month on Packagist; 85,000 stars on GitHub
Hosting
Any VPS with PHP; the company’s own Laravel Cloud, Forge and Vapor
Built on it
Statamic, Invoice Ninja, BookStack, Pixelfed, Filament

What Laravel is used for: 8 areas

Laravel is strongest where an app has users, roles, money and background work. Under each area — the packages it usually runs on.

  1. 01

    SaaS and subscriptions

    Sign-in, teams, plans, payments and trial periods — mostly ready packages.

    CashierSanctumPennant

  2. 02

    Personal accounts

    Orders, documents, notifications and settings for clients and partners.

    FortifyLivewireInertia

  3. 03

    Admin panels and CRM

    Tables, forms, filters and roles assembled from components in days, not weeks.

    FilamentNova

  4. 04

    APIs for apps

    APIs for mobile apps and partners with tokens, rate limits and JSON:API responses.

    API ResourcesSanctumPassport

  5. 05

    Online shops

    Shops with non-standard logic, where a ready platform gets in the way.

    LunarBagistoAimeos

  6. 06

    Content sites and CMS

    Sites with an editor where content and custom features live side by side.

    StatamicBlade

  7. 07

    Real-time interfaces

    Notifications, chats, live counters and dashboards over WebSockets.

    ReverbEcho

  8. 08

    AI features

    Assistants, generation and search by meaning through the AI SDK and pgvector.

    AI SDKScoutpgvector

Pros and cons of Laravel

Laravel trades lightness for a ready answer to almost every product question. That is both its main strength and its main cost.

Pros · 8

  • Everything included

    Sign-in, queues, mail, cache, files, a scheduler and tests work together out of the box.

  • Its own ecosystem

    Subscriptions, real time, search, monitoring and deployment from one team, in one style.

  • A fast start

    Starter kits give sign-in, registration and a profile on the first day.

  • Readable conventions

    Any Laravel developer finds their way in someone else’s project in hours.

  • Excellent documentation

    One of the clearest in the industry, plus Laracasts video courses.

  • Tests built in

    Fakes for mail, queues, HTTP and time make testing a product cheap.

  • Hosting without the routine

    Forge sets up servers, Laravel Cloud runs the app — or any VPS by hand.

  • A large market

    The most common PHP framework: developers and packages are easy to find.

Cons · 8

  • Heavy for simple sites

    Thousands of files and a full boot on every request — a landing page does not need that.

  • “Magic”

    Facades and magic properties hide types; static analysis needs Larastan.

  • Fat models

    Active Record mixes data and logic; in a large domain models grow to hundreds of lines.

  • An upgrade every year

    Security fixes last two years: a project that is not upgraded quickly drops out of support.

  • Package dependence

    An abandoned package can block the next upgrade of the whole project.

  • Slower than plain PHP

    The framework boots on every request; Octane keeps it in memory, but then state between requests becomes your concern.

  • More than shared hosting

    Queues need a worker, the scheduler needs cron, deployment needs Composer and the command line.

  • One company sets the course

    Decisions about the framework and its paid services are made in one place.

Laravel, Symfony or PHP without a framework

Laravel and Symfony solve the same problem differently. Laravel bets on conventions and speed: a lot happens by itself, and a small team ships a product quickly. Symfony bets on explicit configuration and separate components: more code up front, but large systems that live for ten years stay predictable. Laravel itself is partly built on Symfony components.

For sites, catalogues and admin panels without complex accounts modern PHP itself is enough: strict types, PDO and a small foundation of your own give a lighter project that does not need a yearly framework upgrade. Laravel pays off when the product needs its ecosystem — subscriptions, queues, real time and a team that already knows the conventions.

  • Laravel — SaaS, accounts, products with a team
  • Symfony — large long-lived systems
  • Plain PHP — sites, catalogues, admin panels

Laravel compared with Symfony, Django, Rails and NestJS

Five full-featured frameworks for the server side. The table compares approaches and ready parts rather than speed.

CriterionLaravelSymfonyDjangoRailsNestJS
Language PHP PHP Python Ruby TypeScript
Approach conventions, everything included components, explicit configuration everything included conventions over configuration modules and decorators
ORM Eloquent (Active Record) Doctrine (Data Mapper) Django ORM Active Record TypeORM or Prisma
Admin panel Filament or Nova EasyAdmin built in Avo or ActiveAdmin assembled separately
Queues built in, Horizon Messenger Celery or django.tasks Active Job, Solid Queue BullMQ
Real time Reverb Mercure Channels Action Cable WebSocket gateways
Entry bar low medium low low medium
Strongest at SaaS and accounts with a small team large long-lived systems admin-heavy products, data and AI fast product launches TypeScript teams and APIs

When to choose Laravel — and when not to

Thirteen typical tasks with a verdict. Where Laravel is not the best choice, the alternative is named.

  • SaaS with subscriptions

    Best fit

    Sign-in, teams, plans and payments are ready packages.

  • Personal account for clients

    Best fit

    Roles, documents and notifications without reinventing them.

  • Admin panel or CRM

    Best fit

    Filament assembles tables, forms and filters in days.

  • API for a mobile app

    Best fit

    Tokens, rate limits, validation and resources out of the box.

  • Booking service or marketplace

    Best fit

    Business rules, queues, notifications and payments in one place.

  • Product launch with a small team

    Best fit

    Conventions let two or three developers move fast.

  • Internal system with reports

    Best fit

    Queues and the scheduler build heavy reports in the background.

  • Online shop

    Works

    Lunar or Bagisto for unusual logic; a ready platform is faster for a typical shop.

  • Corporate site or landing page

    Works

    Works, but plain PHP or a static site is lighter and cheaper to maintain.

  • Chat and live notifications

    Works

    Reverb handles it; at very large scale — a separate service in Go or Node.js.

  • Blog or simple content site

    Pick another

    A ready CMS or a static site generator.

  • Machine learning and data analysis

    Pick another

    Python: Laravel can call it as a separate service.

  • Tens of thousands of requests per second

    Pick another

    Go or Rust for the hot path, Laravel for the rest.

The Laravel ecosystem: tools for common tasks

Much is built into the framework, the rest is installed through Composer. The middle column is what ships with Laravel itself.

TaskBuilt inPackages and services
Sign-in and access Auth, Gates, Policies Sanctum, Fortify, Socialite
Database Eloquent, migrations Scout
Front end Blade, Vite Livewire, Inertia
Admin panel — Filament, Nova
Queues Queues, Scheduler Horizon
Real time Broadcasting Reverb, Echo
Payments and subscriptions — Cashier
AI vector queries AI SDK, Boost
Tests PHPUnit, fakes Pest, Dusk
Style and checks — Pint, Larastan
Monitoring — Pulse, Telescope, Nightwatch
Speed cache, optimize Octane
Local environment artisan serve Herd, Sail
Hosting — Forge, Cloud, Vapor

The limits of Laravel: where it hits the ceiling

  1. Simple sites

    A landing page gets the weight of a whole framework and a yearly upgrade it does not need.

  2. Speed per request

    The framework boots on every request. Caching config and routes helps; Octane helps more, at the cost of watching state.

  3. Large domains

    With Active Record, complex business rules end up in models and controllers unless you add actions and services.

  4. Upgrades

    A project that skipped two versions needs several upgrades in a row — and its packages may not keep up.

  5. Hidden queries

    A relation used in a loop turns one page into hundreds of SQL queries.

  6. Huge real-time load

    Reverb works for most apps; hundreds of thousands of connections are more economical in Go or Node.js.

8 tips for a Laravel project that lives long

  1. 01

    Upgrade every year

    Laravel 11 lost security fixes in March 2026, 12 loses them in February 2027. One version at a time is cheap.

  2. 02

    Larastan at a high level

    Static analysis sees through facades and magic properties.

  3. 03

    No lazy loading in development

    Model::preventLazyLoading() turns every hidden 1 + N query into an error.

  4. 04

    Heavy work in queues

    Mail, reports and imports go to the background; Horizon shows what is stuck.

  5. 05

    Validation in form requests

    Rules live next to the request, not scattered across controllers.

  6. 06

    Logic in actions, not controllers

    A controller receives and answers; the work is done by a class you can test.

  7. 07

    Caches on production

    php artisan optimize after every release: config, routes, views and events from cache.

  8. 08

    Fewer packages

    Each package is a future upgrade risk; take only maintained ones.

What Laravel looks like in work: 3 examples

A model with a readable query, a controller with data checks and a background job. Checked by tests on Laravel 13 and PHP 8.5.

A model and a query

The status is stored as a string and read as an enum; the paid scope makes the query read like a sentence, and with() loads the buyers in one extra query.

app/Models/Order.php
<?php

namespace App\Models;

use App\Enums\OrderStatus;
use Illuminate\Database\Eloquent\Attributes\Scope;
use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Order extends Model
{
    protected $fillable = ['user_id', 'status', 'total'];

    protected function casts(): array
    {
        // a string in the database, an enum in the code
        return ['status' => OrderStatus::class];
    }

    public function user(): BelongsTo
    {
        return $this->belongsTo(User::class);
    }

    #[Scope]
    protected function paid(Builder $query): void
    {
        $query->where('status', OrderStatus::Paid);
    }
}

// paid orders for 30 days with buyers: 2 SQL queries instead of 1 + N
// Order::paid()->where('created_at', '>=', now()->subDays(30))
//     ->with('user')->latest()->get();

A controller with data checks

The attribute limits requests from one address; the rules turn wrong data into a 422 answer with a message for each field.

app/Http/Controllers/LeadController.php
<?php

namespace App\Http\Controllers;

use App\Models\Lead;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;
use Illuminate\Routing\Attributes\Controllers\Middleware;

// no more than 5 requests a minute from one address
#[Middleware('throttle:5,1')]
class LeadController
{
    public function store(Request $request): JsonResponse
    {
        // a bad field → 422 with a message for each field
        $data = $request->validate([
            'name'   => ['required', 'string', 'min:2', 'max:80'],
            'email'  => ['required', 'email'],
            'budget' => ['nullable', 'integer', 'min:0'],
        ]);

        $lead = Lead::create($data);

        return response()->json(['id' => $lead->id], 201);
    }
}

A background job

The email goes through the queue: the visitor does not wait for the mail server, and a failure is retried by itself.

app/Jobs/SendInvoice.php
<?php

namespace App\Jobs;

use App\Mail\InvoiceMail;
use App\Models\Order;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
use Illuminate\Queue\Attributes\Backoff;
use Illuminate\Queue\Attributes\Tries;
use Illuminate\Support\Facades\Mail;

#[Tries(3)]
// if the mail server fails: again in 10 s, then in 60 s
#[Backoff(10, 60)]
class SendInvoice implements ShouldQueue
{
    use Queueable;

    public function __construct(public Order $order) {}

    public function handle(): void
    {
        Mail::to($this->order->user)->send(new InvoiceMail($this->order));
    }
}

// in the controller: the answer goes at once, the email in the background
// SendInvoice::dispatch($order);

Questions about Laravel

Laravel or plain PHP?

Plain PHP for sites, catalogues and admin panels; Laravel for SaaS, accounts and products that need queues, subscriptions and real time.

Laravel or Symfony?

Laravel for speed with a small team, Symfony for large systems with long support and explicit configuration.

Is Laravel slow?

Slower than plain PHP per request, but fast enough for most products with caches. The usual bottleneck is hidden database queries, not the framework.

Which version should I use?

Laravel 13 with PHP 8.4 or 8.5. Laravel 12 still gets security fixes until 24 February 2027.

Is Laravel free?

Yes, under the MIT license. Optional paid services are Laravel Cloud, Forge, Vapor, Nova and Nightwatch.

What hosting does Laravel need?

A VPS with PHP 8.3 or newer, Composer, a queue worker and cron for the scheduler — or Laravel Cloud, which does it for you.

Livewire or Inertia?

Livewire for interfaces in PHP and Blade with almost no JavaScript; Inertia when the team writes the front end in React, Vue or Svelte.

Can Laravel do AI?

Yes: Laravel 13 has an AI SDK for text, images, audio and embeddings and vector search with pgvector. Training models stays in Python.

Online form

Projects
on Laravel

I build on Laravel when a project needs its ecosystem — SaaS, personal accounts, admin panels on Filament — and take over existing Laravel projects: upgrades, speed-ups, fixes. Tell me about the task — I answer within one working day and will say honestly whether you need Laravel or plain PHP is enough.

Or write to [email protected]