Laravel Hosting in 2026: How to Deploy Laravel Apps

Laravel is the framework most PHP teams reach for, but hosting it in production has always carried more weight than hosting a static site. A real Laravel deploy has to run database migrations, keep queue workers alive, cache config and routes, serve requests through PHP-FPM, and hold an APP_KEY secret. The question in 2026 is not can this run on a server, but which platform handles all of that from a single git push, without asking you to configure Nginx by hand or babysit a VPS.

This guide covers what to look for in Laravel hosting, how modern PHP deploys actually work, how to package Laravel with either Buildpacks or a Dockerfile, and how to run migrations, queues, and a managed database in production, including on a free tier.

The short answer: the best Laravel hosting in 2026 is a platform-as-a-service that builds your app straight from GitHub, runs php artisan migrate on deploy, keeps queue workers running as a separate process, and provisions managed PostgreSQL. Out Plane deploys Laravel with a permanent free Hobby tier, $20 in credit, no cold starts, and automatic HTTPS, without servers or YAML.

What Is Laravel Hosting?

Laravel hosting is the infrastructure that builds, runs, and serves a Laravel application in production, including PHP execution, HTTP routing, TLS, database migrations, queue workers, scheduled tasks, and a managed database. Because Laravel is a stateful, request-driven PHP framework rather than a single binary, the platform's process model and build pipeline matter as much as raw CPU.

That process model is what separates Laravel hosting from hosting a simple script. A production Laravel app is rarely one process. It is a web process serving HTTP, one or more queue workers draining jobs, and a scheduler firing cron-style tasks every minute. It needs writable storage for the cache and sessions, a database for its models, and often Redis for queues and locks. A good host gives you a clean way to run each of those without hand-rolling supervisord. The official Laravel documentation at laravel.com/docs/deployment describes the optimization and configuration steps a production deploy should perform.

What to Look for in Laravel Hosting

Laravel has more moving parts than a static app, so the platform around it decides how much operational work lands on you. Four things separate hosting you can grow on from hosting you migrate off in six months.

• Git-push deploys with a build step. You connect a repository, push, and the platform installs Composer dependencies, optimizes the autoloader, and ships the new version. No scp, no git pull on a server, no manual composer install.
• First-class background processes. Queue workers and the scheduler are not optional for real apps. The host must let you run php artisan queue:work as a long-lived process, separate from the web process.
• A managed database next to your app. Almost every Laravel app needs Postgres or MySQL plus Redis for queues and cache. Provisioning a managed database from the same platform, with backups handled for you, removes an entire class of work.
• Predictable pricing. Usage-based billing, with no surprise minimums, keeps the cost proportional to what your app actually serves.

If a host is missing any of these, you will feel it the first time your Laravel app has real traffic and a backed-up queue.

How Laravel Deploys Work on a Modern Host

A modern Laravel host builds your app from source and runs it as a container. The flow is the same whether you use Blade, Livewire, Inertia, or a headless API.

1. Connect your repository. The platform reads your composer.json, detects PHP, installs dependencies with composer install --no-dev --optimize-autoloader, and builds a production image.
2. Bind to the right host and port. Your web server must listen on 0.0.0.0 and the port the platform provides through the PORT environment variable. This one detail is the most common reason a first deploy builds fine but receives no traffic.
3. Run migrations and cache config on release. A release runs php artisan migrate --force and warms the config, route, and view caches so the first request is fast.
4. Push to deploy. Each push to your connected branch triggers a new build and a zero-downtime release.

On Out Plane, both Cloud Native Buildpacks and a custom Dockerfile are supported. A standard Laravel app deploys with almost no configuration because Buildpacks detect composer.json automatically, and a more involved runtime deploys exactly the way you define it.

Two ways to serve PHP: Buildpacks or a Dockerfile

There are two mainstream ways to serve Laravel in production, and a good host supports both.

The simplest is PHP-FPM behind Nginx, the classic pairing that handles concurrency well and is what most managed PHP images ship. The alternative is a self-contained Dockerfile where you control the exact PHP version, extensions, and web server. The Buildpack path gets you to production with zero config; the Dockerfile path gives you full control when you need a specific extension or a runtime like FrankenPHP or Octane.

Here is a production-ready multi-stage Dockerfile using PHP-FPM and Nginx. It binds to the platform PORT and runs migrations and cache warming at release time through an entrypoint.

FROM php:8.4-fpm-alpine

# System deps and PHP extensions for Laravel + PostgreSQL
RUN apk add --no-cache nginx bash postgresql-dev libzip-dev \
    && docker-php-ext-install pdo pdo_pgsql zip bcmath opcache

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

WORKDIR /app

# Install dependencies first for better layer caching
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-scripts --no-interaction

COPY . .

RUN composer dump-autoload --optimize \
    && chmod -R 775 storage bootstrap/cache

COPY docker/nginx.conf /etc/nginx/nginx.conf
COPY docker/entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

EXPOSE 8080
ENTRYPOINT ["/entrypoint.sh"]

The entrypoint runs your release-time tasks, then starts PHP-FPM and Nginx. The Nginx config listens on the injected PORT so the platform can route traffic to it.

#!/usr/bin/env bash
set -e

# Cache config, routes, and views for production speed
php artisan config:cache
php artisan route:cache
php artisan view:cache

# Apply database migrations without an interactive prompt
php artisan migrate --force

# Start PHP-FPM, then Nginx in the foreground on $PORT
php-fpm -D
sed -i "s/listen 8080/listen ${PORT:-8080}/" /etc/nginx/nginx.conf
nginx -g "daemon off;"

The --force flag on migrate is required in production. Without it, Laravel prompts for confirmation and the deploy hangs. Caching config and routes at release, not at build, keeps environment variables live because config:cache bakes whatever env() returns at the moment it runs.

For a full step-by-step walkthrough with a sample app, see how to deploy a Laravel application.

The APP_KEY and environment variables

Every Laravel app needs an APP_KEY to encrypt sessions, cookies, and signed URLs. Generate one locally and set it as an environment variable in your app settings. Never commit it, and never share it between environments.

php artisan key:generate --show

Copy the resulting base64:... string into your platform's environment variables, alongside the rest of a minimal production set.

APP_KEY=base64:your-generated-key-here
APP_ENV=production
APP_DEBUG=false
APP_URL=https://your-app.outplane.app
LOG_CHANNEL=stderr
SESSION_DRIVER=database
CACHE_STORE=redis
QUEUE_CONNECTION=redis

Setting LOG_CHANNEL=stderr sends Laravel's logs to standard error, which the platform captures and streams for you. Using the file driver for sessions and cache is unreliable in a containerized runtime, so point them at the database or Redis instead.

Running Migrations and Queue Workers

The two operations that trip up first-time Laravel deploys are migrations and queues, because both live outside the normal web request.

Migrations should run once per release, not on every request. Running php artisan migrate --force in your entrypoint or release command applies schema changes right before the new version starts serving. Because the platform releases with zero downtime, run migrations that are backward compatible so the old version keeps working until traffic cuts over.

Queue workers must run as their own long-lived process. On Out Plane, deploy a second service from the same repository with a different start command, so the web app and the worker scale independently.

php artisan queue:work --tries=3 --timeout=90 --sleep=3

Point QUEUE_CONNECTION at redis or database. Redis is the common choice because it is fast and supports delayed jobs cleanly. When you deploy new code, restart workers so they pick up the new version; a simple approach is to have the worker service redeploy on each push, the same as the web service.

The scheduler is the third process. Rather than a system crontab, run Laravel's scheduler as a resident worker.

php artisan schedule:work

This keeps schedule:run firing every minute inside the container, so your app/Console/Kernel.php schedule works without touching host cron.

Laravel Hosting Options Compared

Not every host handles Laravel's process model the same way. Here is how the common approaches compare on the things that actually matter for a PHP app in production.

Shared hosting is cheap but rarely gives you real queue workers or a modern PHP version. A VPS gives you total control at the cost of running everything yourself. Serverless can be economical for bursty traffic but fights Laravel's stateful, always-on assumptions and adds cold starts. A PaaS sits in the middle: git-push simplicity with room for background workers and a managed database.

Adding a Managed Database and Self-Hosted Redis

Almost every Laravel app needs a database, and most need Redis for queues, cache, and locks. On Out Plane you provision managed PostgreSQL alongside your app, then read the connection details from environment variables. Backups, point-in-time recovery, read replicas, and connection pooling are handled for you. Redis is not a managed engine, so run it yourself as a container with a persistent volume, or point Laravel's queue and cache at the database to stay fully managed.

Provision the database from the console, then set Laravel's connection variables.

DB_CONNECTION=pgsql
DB_HOST=your-database-host
DB_PORT=5432
DB_DATABASE=your-database-name
DB_USERNAME=your-database-user
DB_PASSWORD=your-database-password

REDIS_HOST=your-redis-host
REDIS_PORT=6379
REDIS_CLIENT=phpredis

Laravel speaks PostgreSQL natively through the pgsql driver, so no application changes are needed beyond the connection details. With QUEUE_CONNECTION=redis and CACHE_STORE=redis, your worker and cache share the same self-hosted Redis container, and the whole setup uses the same usage-based pricing as your compute.

Cost, Free Tier, and Scaling

Laravel apps are long-running and stateful, so a free tier that never sleeps matters more than for a burst-friendly serverless function.

Out Plane's Hobby tier is permanent and free, with no monthly minimum, and new accounts also receive $20 in credit with no card required. Because there are no cold starts, a free Laravel app answers the first request immediately rather than after a warm-up. A low-traffic app, an internal tool, or a personal SaaS runs continuously within the tier. You only pay once usage grows past what Hobby covers, and paid Pro usage is pay-as-you-go, so a quiet app stays cheap. For current numbers see the pricing page.

Scaling is handled by raising the instance count, and the platform load-balances across instances automatically. Keep the web process stateless by storing sessions, cache, and queues in managed PostgreSQL or self-hosted Redis rather than local disk, and your app scales horizontally without sticky sessions. Choose an EU region, Nuremberg or Helsinki, for EU data residency when your team needs its data to stay in Europe.

If you need a specific PHP runtime and extensions, a host with first-class Docker hosting builds from your Dockerfile so you ship the exact runtime you tested locally, with no drift between development and production.

Deploying Laravel on Out Plane

Putting it together, a production Laravel deploy takes three steps.

1. Connect your GitHub repository at console.outplane.com. The platform detects PHP and installs Composer dependencies.
2. Set your environment variables and port. Add APP_KEY, APP_ENV=production, your database and Redis details, set the web port to what your server binds, and add a release command that runs php artisan migrate --force.
3. Deploy the web service, then add a worker. Deploy the web app, then add a second service from the same repository with php artisan queue:work as its start command for background jobs.

Once the status shows Ready, your app is live on a .outplane.app URL with automatic HTTPS. Map a custom domain and the platform provisions its certificate for you.

Ready to deploy? Host your Laravel app on Out Plane with $20 in free credit and no credit card required. See the full breakdown on the pricing page.

Frequently Asked Questions

What is the best hosting for a Laravel app?

The best Laravel hosting for most teams is a platform-as-a-service that builds from GitHub, runs migrations on release, supports separate queue-worker processes, and provides a managed database. It removes server management while keeping full control of your code. Out Plane offers this with a permanent free tier, managed PostgreSQL, and pay-as-you-go billing.

Is there free hosting for Laravel?

Yes. Out Plane's Hobby tier is a permanent free tier with no monthly minimum, plus $20 in trial credit and no credit card required. Because there are no cold starts, a low-traffic Laravel app can run continuously at no cost, unlike time-limited trials that expire. You only pay once your usage grows past what the Hobby tier covers.

How do I deploy a Laravel app?

Connect your GitHub repository, set your APP_KEY and database environment variables, make sure your web server listens on 0.0.0.0 and the injected PORT, and add a release command that runs php artisan migrate --force. The platform installs Composer dependencies with Buildpacks or your Dockerfile and releases with zero downtime. Every later push deploys the new version automatically.

How do I run Laravel migrations on deploy?

Run php artisan migrate --force as a release command or in your container entrypoint so it executes once per deploy, before the new version serves traffic. The --force flag skips the interactive confirmation that would otherwise hang a non-interactive deploy. Write backward-compatible migrations so the previous version keeps working during the zero-downtime cutover.

How do I run Laravel queue workers in production?

Run php artisan queue:work as a long-lived process separate from the web app. On Out Plane, deploy a second service from the same repository with the worker command as its start command, so the web and worker scale independently. Point QUEUE_CONNECTION at your managed database or a self-hosted Redis container, and redeploy the worker on each push so it picks up new code.

Do I need a Dockerfile to host Laravel?

No. Cloud Native Buildpacks detect your composer.json, install dependencies, and serve PHP with zero configuration. A custom Dockerfile is optional and useful when you need a specific PHP version, an extension like pdo_pgsql, or a runtime such as FrankenPHP or Octane. Out Plane supports both, so you can start with Buildpacks and add a Dockerfile later.

Can I host Laravel with PostgreSQL?

Yes. Laravel speaks PostgreSQL natively through the pgsql driver, so you only set the connection variables. On Out Plane you provision managed PostgreSQL alongside your app and read the credentials from environment variables. Backups, point-in-time recovery, read replicas, and connection pooling are handled for you, and the database uses the same usage-based pricing as your compute.

Why does my Laravel app show a 500 error after deploying?

The most common causes are a missing APP_KEY, a database that is unreachable, a missing PHP extension like pdo_pgsql, or cached config that references an unavailable environment variable. Check the application logs first, confirm APP_KEY is set, verify your database credentials, and make sure you cache config at release time rather than build time so live environment values are used.