What Laravel is and when to use it

Laravel is a PHP framework for web applications, and a new Laravel 13 project shows its size at once: it installs 109 ComposerComposer: PHP's dependency manager. It reads composer.json, downloads the packages a project needs from Packagist and installs them into the vendor folder. More in “Install PHP, Composer and Laravel 13” packages and offers 122 ArtisanArtisan: Laravel's command-line tool, run as php artisan inside the project folder. Its commands create files (make:model), show what the app sees (route:list, about) and manage caches (config:cache). More in “Project structure, configuration and Artisan” commands before you have written a line of your own. Those packages answer the questions every PHP web app meets, from how a URL reaches your code to how a form is checked, who is logged in and what runs later.

Here you look inside a new project to see what Laravel adds to the PHP you know, pick a release from the official support table, compare Laravel with Symfony, a micro-framework and plain PHP, and separate the open-source framework from the commercial services sold beside it. Through the whole track you build Pathshala, a fictional manager for a coaching centre, with its batches, students, fees and notices; every person and record in it is invented.

Laravel answers the questions every web app asks

Pathshala’s first page, built in the next module, is a notice board: a guardian opens /notices and reads the centre’s notices. In plain PHP, as the php track builds pages with include and require, that one page already needs your own code for four jobs: matching the address to a script, reading the notices from the database, printing them so that no title can run as a script, and checking who may post a new one. Every web app repeats those jobs. A web frameworkweb framework: A set of libraries and conventions that does the work every web app repeats, such as sending each URL to the right code, writing pages, reading the database and checking input, so that you write only the part that is your own app. takes them over, so that the code you write is the part only your app has.

These are the jobs Laravel takes over, and the part of it that does each one:

The parts work together in a fixed order on every request. A request first passes through middlewaremiddleware: A class that sits between the web server and the controller. It can inspect or change a request, stop it with its own response, or pass it inward and then change the response on the way out. More in “How Laravel handles a request”, then the router calls your code, an EloquentEloquent model: A PHP class that stands for one database table, each of its objects for one row: the Notice model queries the notices table, and saving a Notice object writes its row. More in “Your first CRUD feature with Eloquent” model reads the rows and a BladeBlade: Laravel's templating language: an HTML file in resources/views with directives such as @foreach and the {{ }} echo tags, compiled to plain PHP. More in “Your first page: route, controller and view” view writes the page. Step through one guardian’s visit to the notice board, from the file every request enters by to the page that comes back, and watch where each row of the table takes its turn:

The split you just followed is model-view-controllermodel-view-controller (MVC): A way to split an app's code into models, which hold the data and its rules, views, which turn data into what the user sees, and controllers, which take a request and join the two.: the Notice model holds the data, the Blade view holds the HTML, and NoticeController joins the two for one request, while the router and the middleware decide whether that code runs at all. Laravel’s documentation describes two ways to use all this: as a full-stack framework that also renders the pages, which is how this track starts, or as the API backend of a JavaScript or mobile front end. Either way, every part has a fixed place in the project and a command that starts it. A new project lists those commands:

# In a new Laravel 13 project: how many Artisan commands it has, and the make: commands that write an app's parts.
from session import run

run("""
php artisan list --raw | wc -l
php artisan list make --raw
""", app=True)

$ php artisan list --raw | wc -l
     122
$ php artisan list make --raw
make:cache-table           Create a migration for the cache database table
make:cast                  Create a new custom Eloquent cast class
make:channel               Create a new channel class
make:class                 Create a new class
make:command               Create a new Artisan command
make:component             Create a new view component class
make:config                Create a new configuration file
make:controller            Create a new controller class
make:enum                  Create a new enum
make:event                 Create a new event class
make:exception             Create a new custom exception class
make:factory               Create a new model factory
make:interface             Create a new interface
make:job                   Create a new job class
make:job-middleware        Create a new job middleware class
make:listener              Create a new event listener class
make:mail                  Create a new email class
make:middleware            Create a new HTTP middleware class
make:migration             Create a new migration file
make:model                 Create a new Eloquent model class
make:notification          Create a new notification class
make:notifications-table   Create a migration for the notifications table
make:observer              Create a new observer class
make:policy                Create a new policy class
make:provider              Create a new service provider class
make:queue-batches-table   Create a migration for the batches database table
make:queue-failed-table    Create a migration for the failed queue jobs database table
make:queue-table           Create a migration for the queue jobs database table
make:request               Create a new form request class
make:resource              Create a new resource
make:rule                  Create a new validation rule
make:scope                 Create a new scope class
make:seeder                Create a new seeder class
make:session-table         Create a migration for the session database table
make:test                  Create a new test class
make:trait                 Create a new trait
make:view                  Create a new view

Artisan has 122 commands, and 37 of them start with make:, one for each kind of class an app is made of: make:controller, make:model and make:migration for the notice board, make:request for the rules of a form, make:job for slow work and make:test for a test, among others. Each one writes its file where the framework expects it, so the next developer, or you in six months, finds it where every other Laravel project keeps it.

Pick a major that still gets fixes, and the PHP it needs

Every recorded run in this track names its versions. The next session asks a new project for them, then shows the versions its composer.json allows:

# The Laravel and PHP versions a project runs, and the versions its composer.json allows.
from session import run

run("""
php artisan --version
php -r "echo PHP_VERSION, PHP_EOL;"
grep -E '"(php|laravel/framework)":' composer.json
""", app=True)

$ php artisan --version
Laravel Framework 13.34.0
$ php -r "echo PHP_VERSION, PHP_EOL;"
8.5.11
$ grep -E '"(php|laravel/framework)":' composer.json
        "php": "^8.3",
        "laravel/framework": "^13.17",

13.34.0 reads as major 13, minor 34, patch 0. Laravel and its packages follow semantic versioningsemantic versioning: A way of numbering releases as major.minor.patch: a new major version may break code written for the one before, a new minor adds features without breaking anything, and a patch only fixes bugs.: a major release, which Laravel ships once a year around the first quarter, may break code, while minor and patch releases, which may come as often as every week, should never break it. Packagist shows that pace in practice, since the framework went from 13.0.0 to 13.34.0 in 28 weeks. That is why the project asks for "laravel/framework": "^13.17": Composer reads a caret constraint as every release from 13.17.0 up to, but not including, 14.0.0, and the release notes tell projects to write such a constraint, as in ^13.0. The line "php": "^8.3" works the same way for PHP itself: 8.3 or any newer 8.x.

A major does not stay supported for long. The support policy gives every Laravel release 18 months of bug fixes and 2 years of security fixes, counted from its release, and its table also names the PHP versions each major runs on. Walk through the majors a project may meet:

The same table fits in a small program. laravel_support.php holds its four rows and a function that says where a major stands on a given day. The table gives the end of Laravel 13’s bug fixes as a quarter, not a day, so the function says that rather than guess, and a major the table does not hold yet, such as 14, is reported as unknown:

<?php

// Laravel's support table, from laravel.com/framework/docs/13.x/releases: the PHP versions each major release
// supports, the day it came out, and the last day of bug fixes and of security fixes. The table gives Laravel 13's
// end of bug fixes as a quarter, not a day, so that entry holds the quarter. Dates are written as YYYY-MM-DD,
// which compare correctly as plain strings.
const LARAVEL = [
    10 => ['php' => '8.1-8.3', 'released' => '2023-02-14', 'bugs' => '2024-08-06', 'security' => '2025-02-04'],
    11 => ['php' => '8.2-8.4', 'released' => '2024-03-12', 'bugs' => '2025-09-03', 'security' => '2026-03-12'],
    12 => ['php' => '8.2-8.5', 'released' => '2025-02-24', 'bugs' => '2026-08-13', 'security' => '2027-02-24'],
    13 => ['php' => '8.3-8.5', 'released' => '2026-03-17', 'bugs' => 'Q3 2027', 'security' => '2028-03-17'],
];

// The first and the last day of a quarter such as "Q3 2027".
function quarterDays(string $quarter): array
{
    [$q, $year] = sscanf($quarter, 'Q%d %d');
    $first = ['01-01', '04-01', '07-01', '10-01'][$q - 1];
    $last = ['03-31', '06-30', '09-30', '12-31'][$q - 1];

    return ["$year-$first", "$year-$last"];
}

function supportStatus(int $major, string $day): string
{
    $row = LARAVEL[$major] ?? null;
    if ($row === null) {
        // Older than the table: long out of support. Newer: not published yet, so the program does not guess.
        return $major < min(array_keys(LARAVEL)) ? 'end of life' : 'not in the table yet';
    }
    if ($day < $row['released']) {
        return 'not released yet';
    }
    if (str_starts_with($row['bugs'], 'Q')) {
        [$first, $last] = quarterDays($row['bugs']);
        if ($day < $first) {
            return 'bug fixes and security fixes';
        }
        if ($day <= $last) {
            return "bug fixes end during {$row['bugs']}";
        }
    } elseif ($day <= $row['bugs']) {
        return 'bug fixes and security fixes';
    }

    return $day <= $row['security'] ? 'security fixes only' : 'end of life';
}

<?php

require __DIR__ . '/laravel_support.php';

// Three days: the last day of Laravel 11's security fixes, the day after Laravel 12's bug fixes ended, and a day
// inside the quarter in which Laravel 13's bug fixes end.
foreach (['2026-03-12', '2026-08-14', '2027-08-02'] as $day) {
    echo "On $day:\n";
    foreach ([10, 11, 12, 13, 14] as $major) {
        $php = LARAVEL[$major]['php'] ?? '?';
        printf("  Laravel %d  PHP %-7s  %s\n", $major, $php, supportStatus($major, $day));
    }
}

On 2026-03-12:
  Laravel 10  PHP 8.1-8.3  end of life
  Laravel 11  PHP 8.2-8.4  security fixes only
  Laravel 12  PHP 8.2-8.5  bug fixes and security fixes
  Laravel 13  PHP 8.3-8.5  not released yet
  Laravel 14  PHP ?        not in the table yet
On 2026-08-14:
  Laravel 10  PHP 8.1-8.3  end of life
  Laravel 11  PHP 8.2-8.4  end of life
  Laravel 12  PHP 8.2-8.5  security fixes only
  Laravel 13  PHP 8.3-8.5  bug fixes and security fixes
  Laravel 14  PHP ?        not in the table yet
On 2027-08-02:
  Laravel 10  PHP 8.1-8.3  end of life
  Laravel 11  PHP 8.2-8.4  end of life
  Laravel 12  PHP 8.2-8.5  end of life
  Laravel 13  PHP 8.3-8.5  bug fixes end during Q3 2027
  Laravel 14  PHP ?        not in the table yet

The first day is the last of Laravel 11’s security fixes, when 13 was not out yet. By the second, 11 had reached its end of life and 12 had moved to security fixes only, and by the third, inside the quarter in which 13’s bug fixes end, 12 was out of support as well. Because a major arrives about once a year and keeps security fixes for two, two majors are in support most of the time, and a project still on a major more than two years after its release runs without security fixes.

PHP has support windows of its own, which the php track’s first lesson works through. PHP 8.3, the oldest that Laravel 13 accepts, receives security fixes until the end of 2027, a few months before Laravel 13’s own end in 2028, while PHP 8.5 keeps them until the end of 2029. So a new Laravel 13 project is best started on PHP 8.4 or 8.5.

Laravel, Symfony, a micro-framework or plain PHP: choose by the app

Laravel is not the only foundation for a PHP web app, and it is less separate from the others than it may look. This session counts the Symfony packages inside the new Laravel project:

# The Symfony packages a new Laravel project installs: how many, and which ones are components rather than
# polyfills or contracts. One composer call writes the names to a file, then wc and grep read it back.
from session import run

run("""
composer show --name-only 'symfony/*' > symfony-packages
wc -l < symfony-packages
grep -v -e polyfill -e contracts symfony-packages
""", app=True)

$ composer show --name-only 'symfony/*' > symfony-packages
$ wc -l < symfony-packages
      31
$ grep -v -e polyfill -e contracts symfony-packages
symfony/clock
symfony/console
symfony/css-selector
symfony/error-handler
symfony/event-dispatcher
symfony/finder
symfony/http-foundation
symfony/http-kernel
symfony/mailer
symfony/mime
symfony/process
symfony/routing
symfony/string
symfony/translation
symfony/uid
symfony/var-dumper

31 of the 109 packages are Symfony’s, and once the polyfills and the contracts are left out, 16 components remain. Laravel’s own source shows how deep they go: its request and response classes extend those of http-foundation, Artisan is built on console, the router uses routing, and mail goes out through mailer. So the choice between foundations is less about whose code runs and more about how much is decided for you. Four are common:

• Laravel is a full-stack framework with one default for each job in the table above, wired together and started by Artisan. You pay for that in size and pace: 109 packages before the first route, and a major upgrade at least every two years to keep security fixes.
• Symfony describes itself as “a set of PHP Packages, a Web Application framework, a Philosophy, and a Community”. Its plain skeleton starts small, for a microservice, a console tool or an API, or you install the packages of a traditional web app in one go. A new minor comes every six months, and the last minor of each major line is a long-term supportLong-term support: a release that receives fixes for longer than the others of its line, so that an app can stay on it for years. release, with 3 years of bug fixes and 4 of security fixes.
• A micro-framework such as Slim is, in Slim’s own words, “a dispatcher that receives an HTTP request, invokes an appropriate callback routine, and returns an HTTP response”. You add the database layer, templates, validation and logins yourself, which keeps a few endpoints small and leaves a large app to you.
• Plain PHP is what the php track writes: nothing to install, and every step of a request in view. You also write and keep secure the routing, the escaping, the CSRFCross-site request forgery: another site makes a visitor's browser send a request, such as a form, to your app without the visitor meaning to. Apps refuse it by checking a secret token that only their own pages carry. checks and the logins, a good way to learn and a slow way to build a product.

Which one fits depends on the app and on the team that will keep it running. Pick an app, real or planned, and answer the two questions for it. Each answer rules options out or adds a caveat, and every verdict says why:

In short, an app with users, forms, a database and background work wants Laravel or Symfony: Laravel when the team welcomes one default per job and can upgrade every year or two, Symfony when the app should stay on one release line for years. A micro-framework or plain PHP suits a handful of endpoints, and plain PHP is the way to see how the web works underneath. Pathshala has users, fee records, forms and morning reminders, which is why this track builds it with Laravel.

The framework is open source, and the services around it are separate products

A new project is made of other people’s code, so it pays to know what the project asks for and what Composer installed in all:

# What the project asks for and what Composer installed in all. Two composer calls read the lock file and name the
# direct dependencies, then count every package the install pulled in.
from session import run

run("""
composer show --direct --name-only
composer show --name-only | wc -l
""", app=True)

$ composer show --direct --name-only
fakerphp/faker
laravel/framework
laravel/pail
laravel/pao
laravel/pint
laravel/tinker
mockery/mockery
nunomaduro/collision
phpunit/phpunit
$ composer show --name-only | wc -l
     109

The project asks for 9 packages directly, 2 to run the app and 7 for development, and Composer installed 109 in all. A production build drops the development tools, and the licence summary names the terms under which that code arrives:

# The production-only count and the licence summary. Composer prints how many packages a deploy carries without the
# development tools, then its licence summary of everything installed.
from session import run

run("""
composer show --name-only --no-dev | wc -l
composer licenses --format=summary
""", app=True)

$ composer show --name-only --no-dev | wc -l
      76
$ composer licenses --format=summary
 -------------- ------------------------
  License        Number of dependencies
 -------------- ------------------------
  MIT            77
  BSD-3-Clause   31
  GPL-2.0-only   2
  GPL-3.0-only   2
  Apache-2.0     1
 -------------- ------------------------

Without the development tools, 76 packages are left to deploy. The summary counted 113 licences for those 109 packages, because nette/schema and nette/utils list three licences each, and Composer’s schema says that a list means a choice between them: both can be used under BSD-3-Clause. The rest are under the MIT, BSD-3-Clause or Apache-2.0 licence. The framework’s own LICENSE file is the MIT licence, which lets you use, copy, change and sell what you build, as long as the copyright and licence notice stay with the copies.

The same goes for Laravel’s first-party packagesfirst-party package: A package made and maintained by the same team as the framework it extends, such as Laravel's Sanctum or Horizon, which an app installs with Composer only when it needs it., which its team keeps beside the framework and an app adds with Composer when it needs one: Sanctum for API tokens, Fortify and Socialite for logins, Passport for an OAuth2 server, Horizon for a queue dashboard, Reverb for WebSockets, Octane for keeping the booted app in memory, Pulse and Telescope for watching an app, Scout for search, Cashier for subscription billing, Pennant for feature flags, Pint for code style, Sail for containers and Tinker for an interactive shell. Packagist lists every one of them under the MIT licence.

The company behind Laravel also sells products of its own, and these are what cost money. None of them is needed to build, run or deploy a Laravel app, and nothing in this track uses one:

Nova is the one that differs from the rest. It arrives through composer require like any package, but under a commercial licence that is bought, so it belongs on the list of what a project costs. The others are services outside your code: a Laravel app runs on a server of your own that has PHP 8.3 or newer, the PHP extensions the framework needs and a web server, which is where the deployment guide starts.

Practise: versions, foundations and licences

Three things to try on your own computer once the next lesson has installed PHP and Composer:

1. Copy laravel_support.php and support_window.php, add a fourth day to the list, the day after Laravel 13’s security fixes end, and write down every line you expect before you run php support_window.php.
2. In a Laravel project of your own, run composer show --direct and composer licenses --format=summary, then explain every licence the summary lists and which package brought it.
3. Take an app you know, such as a club’s sign-up form or a shop’s order page, answer the two questions of the table above for it, and write one sentence that defends the foundation it leaves you with.

Then test yourself here; each answer comes with the reason it is right, or with what it misses:

Interview questions

For a first job: what does a framework such as Laravel do for a PHP app that you would otherwise write yourself?

It takes over the work every web app repeats. Its router maps each URL and HTTP method to the code that answers it, and middleware runs checks, such as the CSRF token of a form, before that code runs. Blade writes the HTML and escapes every value printed between double braces, Eloquent turns database rows into objects, and migrations keep the tables in files. The validator checks input against rules, authentication and authorization decide who is logged in and what they may do, queues move slow work out of the request, and test helpers send fake requests to the app. Artisan generates the classes and runs the tasks. In plain PHP each of these is code you write and keep secure yourself; with Laravel you write the app’s own logic on top of them.

And one on versions: in Laravel Framework 13.34.0, what does each number say, and which kind of release may break your code?

Laravel follows semantic versioning, major.minor.patch. 13 is the major: a new one comes about once a year and may contain breaking changes, so moving from 12 to 13 is an upgrade you plan and test. 34 is the minor, counting the releases since 13.0 that added features, and 0 is the patch, counting bug-fix releases within 13.34. Minor and patch releases can come every week and should never break code, which is why composer.json asks for a caret range such as ^13.0: it accepts every 13.x release and stops before 14.0.

Two longer questions of the start-here bank grow out of this lesson, one about moving an app off a major that gets no fixes and one about a build that changed under a caret range:

Key takeaways

• Laravel is a full-stack PHP framework that takes over the jobs every web app repeats: routing and middleware, Blade pages whose double braces escape every value, Eloquent and migrations, validation, logins, queues, test helpers and Artisan with its 37 make: generators.
• Each Laravel major gets 18 months of bug fixes and 2 years of security fixes, so a new project starts on Laravel 13 with PHP 8.4 or 8.5 inside its 8.3 to 8.5 range, and its caret constraint takes every 13.x release while stopping before 14.
• Laravel is built on 16 Symfony components; choose it for apps with users, forms and background work when the team accepts one default per job and regular upgrades, Symfony for a long stay on one release line, and a micro-framework or plain PHP for a few endpoints or for learning.
• The framework and its first-party packages are MIT-licensed, the GPL lines in Composer’s report are a choice beside BSD-3-Clause, and what costs money are optional services such as Cloud, Forge and Nightwatch, plus Nova’s commercial licence.