By Bogdan Sandu · Updated September 11, 2026
What Is a Laravel Cheat Sheet
A Laravel cheat sheet is a single page reference to the framework's syntax, Artisan commands and conventions, organised so that a working developer finds the right snippet in seconds instead of re-reading a chapter of the documentation. Some people write it as one word, Laravel cheatsheet; both mean the same thing.
This Laravel cheat sheet covers 28 sections and 305 snippets for Laravel 12 and 13, from installing the framework to deploying it. Every snippet that needs Laravel 11 or newer carries a version badge, and the L10 mode switch hides those for older applications. Each section is a set of cards, each card a set of copyable examples with a one line description, an optional expected output, and a short explanation of why the feature behaves the way it does.
It is written for developers who already know PHP and want the Laravel way of doing something without a detour through the docs. Read it top to bottom as a map of the framework, or use the search box and the level filter to jump straight to the line you need.
How It Differs From the Documentation
The official documentation explains; this page reminds. Every entry is the shortest working form of a feature, placed next to the mistake people usually make with it, and the whole framework fits on one scrollable page with one search box. When a snippet is not enough, the documentation is one link away and this page tells you which chapter to open.
What This Laravel Cheat Sheet Covers
The 28 sections follow the order in which a Laravel application is built, and each link below jumps to that section of the reference above.
- Foundations: installation, project structure and environment, Artisan CLI commands, the service container, providers and facades, Laravel routing, controllers and middleware.
- Request and UI: requests and validation rules, responses and redirects, Blade templates and components, Livewire and Inertia.
- Database: the query builder, Laravel migrations, Eloquent models, Eloquent relationships, and factories and seeders.
- Application: authentication and authorization, APIs and Sanctum, cache, session and config, and file storage.
- Background work: Laravel queues and jobs, events and notifications, and scheduling.
- Quality and help: testing with Pest, helpers and Laravel collections, debugging and tooling, security and deployment, and common errors and translation tables for developers coming from Rails, Django or Express.
What Laravel Is
Laravel is a PHP web framework built around a simple bet: most web applications need the same twenty things, so ship all twenty and make them pleasant to use. Routing, an ORM, authentication, validation, queues, caching, mail, scheduling, file storage and a test suite all come in the box, wired together and documented in one place.
Taylor Otwell released version 1 in 2011. Laravel 11 arrived in March 2024 with a much slimmer application skeleton, Laravel 12 followed in February 2025 with new starter kits, and Laravel 13 shipped on March 17, 2026, requiring PHP 8.3 and adding an AI SDK, JSON:API resources and attribute driven configuration. The framework follows a yearly major release cadence, with bug fixes for 18 months and security fixes for two years, so 12 is on security fixes only and 11 has reached end of life.
The design borrows openly from Rails: convention over configuration, an expressive ORM, generators for everything. If you name things the way Laravel expects, most classes are a few lines long. If you fight the conventions, you write configuration instead.
Where It Fits
- Full stack apps with server rendered Blade views, or Livewire for interactivity without writing JavaScript.
- Single page apps through Inertia, which lets React or Vue pages receive props straight from a controller, no API layer needed.
- JSON APIs for mobile apps and third parties, with Sanctum for tokens and API resources for the response shape.
- SaaS products, using Cashier for Stripe or Paddle billing, Jetstream for teams, and Horizon for the queue dashboard.
- Internal tools and admin panels, often with Filament, which generates a full admin UI from Eloquent models.
The Laravel Request Lifecycle
A Laravel request passes through public/index.php, bootstrap/app.php, the service providers, three layers of middleware, the router and finally your controller, and the response travels back out through the same middleware in reverse. Understanding that path explains most of the framework.
Every request hits public/index.php, which loads Composer's autoloader and boots the application from bootstrap/app.php. Since Laravel 11 that one file configures the router, the middleware stack and the exception handler. Service providers run next, registering bindings in the container, and then the request enters the middleware pipeline.
Global middleware runs first, then the group for the route, web or api, then anything attached to the route itself. Each piece can inspect the request, modify it, or stop it and return a response early. That is how authentication refuses a guest before your code runs.
The router matches the URL, resolves route model bindings by querying the database, and calls your controller with its dependencies injected from the container. Whatever the controller returns is turned into a response object, passed back out through the middleware in reverse order, and sent to the browser.
public/index.php
-> bootstrap/app.php configure routing, middleware, exceptions
-> service providers register bindings, boot the app
-> global middleware
-> route group middleware web or api
-> route middleware
-> router match URL, bind models
-> controller dependencies injected
-> response back out through the middleware
Eloquent, the Query Builder, and When to Use Which
Laravel gives you two ways to talk to the database, and they are layers rather than alternatives.
The query builder, reached through DB::table(), is a fluent way to write SQL that works the same on MySQL, Postgres, SQLite and SQL Server. It returns plain objects. It is fast, it has no opinions, and it is what you want for reports, aggregates and bulk updates.
Eloquent sits on top of it. A model class maps to a table, and every query builder method still works on it, but the results come back as model instances with relationships, attribute casting, accessors, events and soft deletes. This is where application logic belongs.
The practical rule: reach for Eloquent by default, and drop to the query builder when you would otherwise be loading thousands of models just to sum a column.
The N+1 Problem
This is the performance mistake every Laravel developer makes once. Load a list of orders, then read $order->user->name inside the loop. Each access runs its own query, so 100 orders become 101 queries.
// 101 queries
$orders = Order::all();
foreach ($orders as $order) {
echo $order->user->name;
}
// 2 queries
$orders = Order::with('user')->get();
Eager loading with with() fetches the related rows in one extra query. Turn on Model::preventLazyLoading() in development and Laravel throws an exception the moment it happens, which is far better than finding it in the slow query log six months later.
What Changed in Laravel 11, 12 and 13
Laravel 11 replaced the HTTP and console kernels with a single bootstrap/app.php file, Laravel 12 added new starter kits, and Laravel 13 raised the PHP floor to 8.3 and introduced an AI SDK and attribute driven configuration. If you learned Laravel before 2024, the folder structure will look emptier than you remember.
- bootstrap/app.php now holds middleware, exception handling and routing configuration. The HTTP and Console kernels are gone.
- routes/console.php is where scheduled tasks live. There is no Console Kernel with a schedule method.
- Service providers collapsed to a single AppServiceProvider. Event listeners are discovered automatically.
- routes/api.php is not there until you run
php artisan install:api, which also installs Sanctum.
- Default middleware is inside the framework and customised through methods on the Middleware object rather than files in your project.
- SQLite is the default database for a fresh install, and the migrations for sessions, cache and jobs ship in the box.
- Health checks at
/up, per second rate limiting, and the casts() method on models were all added in 11.
Laravel 12 kept the skeleton and shipped new starter kits built on React, Vue and Livewire, with authentication and a component library included. Most Laravel 10 code runs on 12 without changes.
Laravel 13, released March 17, 2026, raises the floor to PHP 8.3 and again keeps breaking changes minimal. The visible additions:
- Laravel AI SDK, a first party API for text generation, tool calling agents, embeddings, image and audio generation, and vector stores, provider agnostic.
- JSON:API resources that produce specification compliant responses with relationship inclusion and sparse fieldsets.
- Attributes everywhere:
#[Middleware] and #[Authorize] on controllers, #[Tries], #[Backoff], #[Timeout] and #[FailOnTimeout] on jobs, plus more across Eloquent, events, validation and testing.
- Queue::route, central routing of job classes to connections and queues.
- Cache::touch, extend a TTL without rewriting the value.
- PreventRequestForgery, the CSRF middleware now also checks request origin.
- Vector search with
whereVectorSimilarTo against PostgreSQL and pgvector.
Every snippet on this page that needs Laravel 11 or newer carries a version badge, and the L10 mode switch in the toolbar hides them if you are maintaining an older application.
Queues, and Why Everything Slow Belongs in One
A web request should do exactly enough work to respond, and nothing else. Sending email, generating a PDF, calling a payment provider, resizing an upload: each of these can take seconds, and the user is staring at a spinner for every one of them.
A queued job moves that work to a separate worker process. The request pushes a job description onto Redis or a database table and returns immediately. The worker picks it up, runs it, and retries it if it fails. The user sees a page in 50 milliseconds instead of 4 seconds, and a flaky third party API no longer takes your site down with it.
Three things to get right: run workers under Supervisor so they restart after a crash, call queue:restart on every deploy so they pick up new code, and give jobs a tries limit with a failed method so a bad job ends up in the failed jobs table instead of looping forever.
Testing Is Not Optional
Laravel makes tests cheap enough that skipping them is a choice rather than a constraint. A feature test boots the application, sends a request through the full middleware stack, and asserts on the response, the database and anything that was dispatched. It runs in milliseconds against an in memory SQLite database.
The fakes are what make it practical. Mail::fake(), Queue::fake(), Event::fake() and Storage::fake() replace the real service with a recorder, so you can assert that a receipt was queued to the right address without a mail server anywhere in sight.
it('queues a receipt when an order is placed', function () {
Mail::fake();
$user = User::factory()->create();
$this->actingAs($user)->post('/orders', ['sku' => 'A1', 'qty' => 2])
->assertRedirect();
Mail::assertQueued(OrderReceipt::class, fn ($m) => $m->hasTo($user->email));
});
Pest is the default test runner since Laravel 11. It is PHPUnit underneath with a lighter syntax, and every PHPUnit assertion still works. Its architecture tests are worth adopting early: a handful of rules such as no dd() in committed code and controllers never touching DB directly will catch more review comments than any linter.
Common Laravel Mistakes
These ten mistakes account for most of the Laravel bugs that reach production, and every one of them is easy to avoid once you know it exists.
- Calling env() outside config files. It returns null once config is cached. Read from
config() instead.
- Loading relationships in a loop. The N+1 problem. Use
with(), and turn on lazy loading prevention in development.
- Setting $guarded to an empty array everywhere. That disables mass assignment protection. Validate with a form request, then pass
validated().
- Putting business logic in controllers. A controller should validate, call something, and respond. Move the something into an action class, a service, or the model.
- Forgetting queue:restart after a deploy. Workers keep running the old code until they are restarted.
- Running migrations without --force in production. The command silently refuses, and the deploy looks green.
- Using file sessions or cache on more than one server. Users get logged out at random. Use Redis or the database driver.
- APP_DEBUG true in production. Error pages leak environment variables and stack traces to anyone who triggers one.
- Query methods on a loaded collection.
$user->orders is a Collection, $user->orders() is a query. Only the second one accepts where.
- Raw SQL built with string interpolation. Every
DB::raw("... $input") is an injection risk. Use bindings.
How to Learn Laravel Well
The fastest way to learn Laravel is to build something small end to end and let the framework's conventions decide the shape of the code, with this cheat sheet open beside the editor.
- Install it and build something small end to end: a route, a migration, a model, a form with validation, a test. The whole loop takes an afternoon.
- Read the official documentation for each subsystem before reaching for a package. Most of what you need is already there.
- Watch Laracasts for the mental models. The free Laravel path is enough to become productive.
- Use
php artisan tinker constantly. It answers most questions faster than a search.
- Turn on
Model::shouldBeStrict() in development. The framework will tell you about mistakes you did not know you were making.
- Read the source. Everything is in
vendor/laravel/framework, it is well written, and the editor will jump straight to it.
For the pieces around Laravel, our PHP cheat sheet covers the language itself, the SQL cheat sheet covers what Eloquent generates, the Docker cheat sheet covers what Sail runs on, the Git cheat sheet covers the workflow around every deploy, and the Tailwind cheat sheet covers the styling every starter kit ships with.
How This Laravel Cheat Sheet Is Maintained
This page is written and maintained by Bogdan Sandu for TMS Outsource, a software development agency that ships PHP and Laravel work for clients. The current revision was checked against the Laravel 13 release notes and documentation on September 11, 2026, and the version badges reflect that check. The plan is to revise it with each major Laravel release; the date in the byline at the top of this article shows the last revision. Corrections are welcome through the contact details in the footer.
Laravel Questions People Actually Ask
The questions developers search for most about Laravel and about this cheat sheet, answered in a few sentences each.
What is Laravel used for?
Laravel is a PHP web framework for building anything that speaks HTTP: full stack applications with server rendered Blade views or Inertia, JSON APIs for mobile and single page apps, SaaS products, e-commerce backends, admin panels and internal tools. It ships with routing, an ORM, authentication, queues, caching, mail, scheduling and a testing framework, so most of the plumbing is already written.
What is the difference between Eloquent and the query builder?
The query builder is a fluent, database agnostic way to write SQL, returning plain objects or arrays. Eloquent sits on top of it and maps tables to model classes, adding relationships, casting, events, scopes and soft deletes. Use Eloquent for application logic and the query builder for reports, bulk operations and anywhere you do not need model behaviour.
What is the N+1 query problem in Laravel and how do I fix it?
N+1 happens when you load a list of models and then access a relationship on each one inside a loop. Every access fires its own query, so 100 posts with authors becomes 101 queries. Fix it by eager loading with the with method, for example Post::with('author')->get(), which fetches the authors in one extra query. Model::preventLazyLoading() in development throws an exception whenever it happens.
When should I use a queue in Laravel?
Queue anything the user does not need to wait for: sending email, generating PDFs, calling third party APIs, resizing images, syncing data. The request returns immediately and a worker process picks up the job. Jobs implement ShouldQueue and are dispatched with the dispatch helper. Run workers with php artisan queue:work and supervise them so they restart after deploys and crashes.
What changed in Laravel 13?
Laravel 13 was released on March 17, 2026 and requires PHP 8.3. It keeps breaking changes to a minimum, so most Laravel 12 applications upgrade with little or no code change. It adds a first party AI SDK for text generation, agents, embeddings, images and audio, JSON:API resources, queue routing by job class with Queue::route, Cache::touch to extend a TTL, origin aware request forgery protection, vector similarity queries against pgvector, and PHP attributes for controller middleware and authorization and for job tries, backoff and timeout. Laravel 11 introduced the slim skeleton with bootstrap/app.php and routes/console.php, and Laravel 12 shipped the React, Vue and Livewire starter kits.
Is this Laravel cheat sheet up to date?
Yes. It was revised on September 11, 2026 against the Laravel 13 release notes and documentation. It covers Laravel 12 and 13, every snippet that needs Laravel 11 or newer carries a version badge, and the L10 mode switch in the toolbar hides those snippets for older applications. The date in the article byline changes with every revision.
Can I download this Laravel cheat sheet as a PDF?
Yes. The page has a print stylesheet, so your browser's print command with Save as PDF produces a clean copy: the dark theme switches to a print palette, every expected output and explanation is expanded, and the search box, navigation and footer are left out. Collapse the sections you do not need first, or run a search, and only what is still visible is printed.
How do I deploy a Laravel application?
On the server run composer install with no dev dependencies, copy a production .env with APP_DEBUG set to false, run php artisan migrate with the force flag, then cache configuration, routes, views and events with php artisan optimize. Point the web server document root at the public directory, run queue workers under Supervisor, and add the scheduler to cron with a single entry that runs php artisan schedule:run every minute. Laravel Forge and Vapor automate all of this.