MasterPHP.in
Sign in Sign up
Laravel Tutorial

Laravel Folder Structure Explained (Deep Dive)

When you create a new Laravel project, you're immediately faced with a dozen folders and files. For beginners, this is confusing — not because the structure is complex, but because it's unclear where real work actually happens.

In practice, most development happens in just a few directories. The challenge is knowing which folder is responsible for what, and what goes wrong when you misuse them.

This guide walks through the key folders you’ll use daily, with practical context so you don’t just memorize the structure — you understand how to work inside it.


How Laravel Is Organized (Quick Mental Model)

Before diving into folders, here’s the simplest way to think about Laravel:

Responsibility Folder Business Logic app/ Routing routes/ UI (Frontend) resources/ Configuration config/ Database database/ Public Access public/

If you remember this mapping, navigating any Laravel project becomes significantly easier.


app/ — Where Your Application Logic Lives

This is the core of your project. Most of your time will be spent here.

Inside it:

  • Models/ handle database interaction using Eloquent
  • Http/Controllers/ process requests and return responses
  • Http/Middleware/ filter incoming requests
  • Providers/ register services and boot application logic

In a typical request lifecycle, a route calls a controller, which interacts with models — all inside this folder.


Pro Tip (with consequence):

Avoid putting business logic directly inside controllers.

If you do, controllers become large and tightly coupled, making them hard to test and reuse. Over time, even small changes will break unrelated features because logic is scattered instead of centralized.


routes/ — Entry Point for All Requests

This is where Laravel decides how to respond to a URL.

Key files:

  • web.php — handles browser-based routes (sessions, views)
  • api.php — handles stateless API requests

Example:

Route::get('/home', [HomeController::class, 'index']);

Routes should only define what happens, not implement the logic.


resources/ — User Interface Layer

This folder contains everything related to what users see.

  • views/ — Blade templates for rendering UI
  • css/ and js/ — frontend assets

Blade templates allow you to combine HTML with dynamic data.


Pro Tip (with consequence):

Avoid embedding complex PHP logic inside Blade views.

If you do, your UI layer becomes unpredictable and debugging becomes difficult because presentation and logic are mixed together.


database/ — Structure and Data Management

This folder controls how your database is built and populated.

  • migrations/ — define table structure
  • seeders/ — insert default or test data
  • factories/ — generate fake data for testing

Example commands:

php artisan migrate
php artisan db:seed

Pro Tip (with consequence):

Never manually edit your database schema in production.

If you skip migrations, your team environments will fall out of sync, leading to bugs that are difficult to reproduce and fix.


config/ — Application Settings

Contains configuration files for different parts of Laravel.

Examples:

  • Database connections
  • Mail setup
  • Caching behavior

Most values are connected to the .env file.

Pro Tip (with consequence):

Do not hardcode environment-specific values in config files.

If you do, moving between local, staging, and production environments will break your application unexpectedly.


public/ — The Only Publicly Accessible Folder

This is the entry point of your application.

  • index.php boots Laravel
  • Stores publicly accessible assets like images and compiled frontend files

Everything outside this folder is protected from direct access.

Pro Tip (with consequence):

Never expose files outside the public directory.

If misconfigured, sensitive files like .env can become accessible, leading to serious security risks.


storage/ — Runtime and Generated Files

Used for storing:

  • Logs
  • Cached data
  • Uploaded files
  • Compiled templates

Important command:

php artisan storage:link

This links storage files to the public directory.

Pro Tip (with consequence):

If you don’t link storage properly, uploaded files will not be accessible via the browser, causing broken images and downloads in production.


bootstrap/ — Application Initialization

Responsible for starting Laravel.

  • cache/ stores optimized files for performance

This folder is rarely modified during development.

Pro Tip (with consequence):

Deleting cached files incorrectly can cause configuration or route issues to behave unpredictably, especially in production environments.


vendor/ — Third-Party Dependencies

Contains all Composer-installed packages, including Laravel itself.

This folder is auto-managed.

Rule:

Never modify anything inside vendor/.

Consequence if ignored:

Any changes will be overwritten on the next Composer update, and debugging issues becomes extremely difficult because core behavior is altered.


.env — Environment Configuration

Stores sensitive and environment-specific data:

  • Database credentials
  • API keys
  • App environment settings

Example:

APP_ENV=local
DB_DATABASE=laravel

Pro Tip (with consequence):

Never commit .env to version control.

If exposed, attackers can gain access to your database, APIs, and internal services.


Final Note

Laravel’s structure isn’t just about organization — it enforces separation of concerns. Once you understand what each folder is responsible for, you stop guessing where code should go and start building with confidence.

Share this tutorial