Create Laravel 13 project from scratch
Laravel is a PHP framework built around the Model View Controller pattern, designed to make web development more organized and less repetitive. It has become one of the most widely used frameworks in the PHP ecosystem, and its yearly major releases keep bringing refinements to routing, database handling, testing, and application structure. Laravel 13 continues that pattern with a required PHP version bump, additional PHP attributes for controllers and queues, and a first party AI SDK, while leaving most day to day development patterns unchanged. Creating a new Laravel 13 project begins with installing PHP, Composer, and Laravel itself, followed by a short round of configuration that prepares the application for development.
Prerequisites
Before creating a Laravel 13 project, the development machine needs PHP 8.3 or newer, since support for PHP 8.2 was dropped with this release, Composer installed globally, and access to a database system such as MySQL, PostgreSQL, or SQLite. Running php -v in a terminal confirms the active PHP version before starting the installation, since Composer will refuse to install Laravel 13 against an unsupported PHP version.
Recommended articles:
Installation
With PHP, Composer, and a database in place, creating a new Laravel 13 project comes down to a single Composer command. Composer downloads the Laravel skeleton application together with its dependencies and places everything inside a new directory named after the project.
composer create-project laravel/laravel:^13.0 laravel13_project
The command above creates a directory called laravel13_project containing a working Laravel application, complete with its own composer.json, autoloaded classes, and a default .env file. Composer resolves the requested framework version against the constraint ^13.0, so running the command again later still picks up patch and minor releases within Laravel 13, without jumping to Laravel 14 once that becomes available.
Configuring Laravel
A newly created Laravel project already has working defaults for routing, sessions, and logging. The environment file, storage directories, and database connection are the parts most commonly adjusted before development starts.
Environment variables
Environment variables hold values that differ between machines or that should never be committed to source control, such as database credentials, API keys, and mail server settings. Laravel keeps these values in a .env file located at the project root, and the create-project command generates one automatically from the bundled .env.example template. Application specific values, including the app name, environment, and debug mode, live in config/app.php and read most of their defaults directly from these environment variables. Adjusting the .env file to match the target environment, local, staging, or production, is usually the first configuration step after installation.
Laravel also reads parts of this file through the config:cache command during deployment, so keeping variable names consistent between .env.example and .env prevents missing key errors later. Renaming or removing a variable that a config file still references produces null values at runtime instead of an explicit error, which makes small naming mistakes harder to catch.
Setting folder permissions
The storage and bootstrap/cache directories store logs, compiled views, and cached configuration files, and Laravel needs write access to both in order to function correctly. On a fresh installation these directories usually have permissions set by the operating system's default umask, which is not always sufficient once the application runs behind a web server.
Navigate to the root of the Laravel project.
Grant write permissions to the
storageandbootstrap/cachedirectories:sudo chmod -R 775 storage bootstrap/cache
Change the ownership of these directories to match the web server's user, typically
www-dataon Debian and Ubuntu systems running Nginx or Apache:sudo chown -R www-data:www-data storage bootstrap/cache
Setting the correct owner alongside the correct permissions matters, since chmod alone does not change who owns the files. Without matching ownership, the web server process can still be denied write access even though the permission bits look correct, which tends to surface as failed log writes or blank error pages instead of a clear message.
Databases and migrations
Once the application can read its environment file and write to its storage directories, the next step is preparing a database. The default .env file generated by Laravel points to a SQLite database, and Laravel automatically creates a database/database.sqlite file the first time migrations run, without requiring a separate database server.
Switching to MySQL or PostgreSQL means updating the DB_CONNECTION, DB_HOST, DB_DATABASE, DB_USERNAME, and DB_PASSWORD variables in the .env file to match the target server. Once the connection details are correct, running the migration command creates the tables defined by the application's migration files:
php artisan migrate
Laravel tracks which migrations have already run in a dedicated migrations table, so running the command again only applies files that have not been executed yet.
Starting the development server
With the project configured, Laravel's built in development server provides a way to preview the application without setting up nginx or Apache locally. From the project root, the following Artisan command starts the server:
php artisan serve
The terminal stays attached to the running process and prints the local address the application is reachable at, typically http://127.0.0.1:8000. Requests to that address are handled by PHP's built in web server through Artisan, which suits local development but is not intended for production traffic.
Stopping the server is done with the Ctrl+C combination, which returns control of the terminal.
0 Comments