Laravel applications.
What a Laravel project gets out of the box: APP_KEY and production settings, SQLite until you add a database, migrations as the release command, a queue worker and the scheduler.
Laravel is recognised by laravel/framework in composer.json. You deploy it as it is — no server configuration, no extra files in the repository.
How it is built and run
- PHP — the lowest of 8.2, 8.3 and 8.4 that satisfies the
phprequirement incomposer.json(8.3 when it doesn't say). - Composer —
composer install --no-dev --optimize-autoloader. - Front-end assets — if
package.jsonhas abuildscript (Vite), it is run andpublic/buildis included. - On start —
storage:link, then the config, route and view caches are built. - HTTPS — your application sees HTTPS requests as secure, so
url(),asset()and redirects usehttps://without trusting proxies yourself.
Variables set for you
| Variable | Value |
|---|---|
APP_KEY | generated once at the first deploy and kept with your variables |
APP_ENV | production |
APP_DEBUG | false |
APP_URL | the application's address |
LOG_CHANNEL | stderr — so the Logs tab shows Laravel's log |
SESSION_DRIVER, CACHE_STORE | file |
Any of them can be replaced by a variable of your own with the same name — for example SESSION_DRIVER=redis once you add Valkey. See Environment variables.
The database: SQLite first
A new Laravel application without a database keeps its data in SQLite — Laravel's own default — in storage/app/database.sqlite on the application's disk. The file survives deploys and is included in the application's daily backups, so you can launch first and decide on a database later.
When you add PostgreSQL or MySQL to the project (Overview → Services → Add a service), the application switches to it with the next deploy, and the migrations run there. Data in the SQLite file is not carried over — export it first if you need it, and import it on the database's Data tab. See Databases.
Migrations — the release command
The recommended release command is php artisan migrate --force. It runs once on every deploy, before the new version receives visitors; if a migration fails, the current version keeps running. You can change it on the Processes tab. See Deploys.
Queue worker and scheduler
Out of the box, the Processes tab runs:
| What | Command |
|---|---|
| Background worker «queue» | php artisan queue:work --sleep=3 --tries=3 --max-time=3600 |
| Scheduled command, every minute | php artisan schedule:run |
They share the application's resources and restart with every deploy. Change or remove them on the Processes tab — for example, replace the worker with php artisan horizon when you use Horizon with Valkey.
For a heavy queue, run the worker as a separate background worker service with its own resources, and remove it from Processes. See Services of a project.
Valkey for cache, sessions and queues
Add Valkey to the project and set the drivers you want on the Variables tab, e.g.:
CACHE_STORE=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redisREDIS_HOST, REDIS_PASSWORD, REDIS_PORT and REDIS_CLIENT=phpredis are set for you.
WebSockets (Laravel Reverb)
Run Reverb as a web service from this project's code with the command php artisan reverb:start --host=0.0.0.0 --port=$PORT. It gets its own address.
Files and uploads
Files in storage/app — Laravel's local and public disks — stay on the application's disk between deploys and are backed up daily. Everything else in the project folder comes fresh from the repository with each deploy. For many or large files, use object storage with Laravel's s3 disk.