Laravel Hosting Requirements and Server Setup Guide (2026)

Laravel's server requirements look short on paper, which is how people end up deploying to £2/month shared hosting and discovering that emails never send, scheduled tasks never run, and composer install is blocked. The framework itself is undemanding; it is the operational requirements — workers, cron, process control — that separate hosting that runs Laravel from hosting that merely serves PHP.

This guide covers both layers: the hard requirements, the server setup that makes a Laravel app production-ready, and what to look for in a host. If you would rather not assemble it yourself, our app hosting platform provides the full stack — PHP, workers, scheduler, SSL — preconfigured; everything below applies whether you use it or build your own VPS.

What PHP version and extensions does Laravel need?

Current Laravel releases require PHP 8.2 as a minimum, and running the newest stable PHP your host offers (8.3 or 8.4) is worthwhile for performance alone. Check your exact Laravel version's documentation, but the extension list has been stable for years:

• Required extensions: Ctype, cURL, DOM, Fileinfo, Filter, Hash, Mbstring, OpenSSL, PCRE, PDO, Session, Tokenizer, XML. Most PHP builds include the majority by default; php -m lists what is installed.
• Practically required: BCMath (used by several common packages), the PDO driver for your database (pdo_mysql or pdo_pgsql), GD or Imagick for image handling, and zip for Composer.
• Strongly recommended: OPcache (a large, free performance win on every request) and phpredis if you use Redis.

You also need Composer available on the server — or a deployment process that uploads a locally built vendor directory. Hosts that block long-running processes or CLI access make even that awkward, which is an early sign you are on the wrong tier.

Which database and cache should you use?

Laravel's Eloquent ORM supports MySQL/MariaDB, PostgreSQL, SQLite and SQL Server. Any of the first three is a fine default: MySQL remains the most common in tutorials and shared environments, while PostgreSQL is an excellent choice for new projects (our managed vs self-hosted PostgreSQL guide covers who should run it). SQLite — now Laravel's out-of-the-box default — is genuinely production-viable for small, single-server apps.

For cache, sessions and queues, Redis (or Valkey) is the standard answer once you outgrow the database drivers: it is faster, keeps queue load off your database, and unlocks features like Horizon for queue monitoring. It is not required on day one — the database drivers work — but plan for it.

Why do queue workers and the scheduler rule out basic shared hosting?

This is the section that catches people out, so it deserves detail:

• Queue workers are long-running processes. Anything you dispatch to a queue — emails, notifications, report generation — is executed by php artisan queue:work, a process that must run continuously and be restarted if it dies. That means a process supervisor (conventionally Supervisor on a VPS, or the platform equivalent). Basic shared hosting kills long-running processes, so queued jobs silently never run.
• The scheduler needs one cron entry. Laravel's scheduled tasks all hang off a single system cron line: * * * * * php /path/artisan schedule:run. No cron access (or cron limited to hourly) means no scheduled commands, no queue pruning, no scheduled backups.
• The web root must be public/. Laravel expects the document root pointed at its public directory — never the project root, which would expose .env. Hosts that force a fixed public_html layout require workarounds that are a recurring source of security mistakes.
• Writable storage. storage/ and bootstrap/cache/ must be writable by the PHP process — the classic 500-error-on-first-deploy is a permissions problem here.

What does a production Laravel server look like?

A conventional single-server setup, whether you build it or a platform provides it:

On sizing: Laravel itself is light, but a realistic small production server runs Nginx, PHP-FPM, a database, Redis and one or two workers simultaneously — 1 GB of RAM is the practical floor, 2 GB is comfortable. CPU rarely matters before traffic does.

What belongs in your deployment checklist?

1. composer install --no-dev --optimize-autoloader — dev dependencies stay out of production.
2. Set APP_ENV=production, APP_DEBUG=false and a generated APP_KEY in .env — debug mode in production leaks credentials in stack traces.
3. Cache everything cacheable: php artisan config:cache route:cache view:cache (or the combined optimize command).
4. Run php artisan migrate --force as part of the deploy, not by hand.
5. Restart workers on every deploy with php artisan queue:restart — running workers keep old code in memory otherwise, which produces baffling bugs.
6. Build frontend assets (npm run build) in CI or locally; Node.js is a build-time dependency, not a server one.

What about Laravel Octane?

Octane keeps your application booted in memory between requests using a long-running server (FrankenPHP, Swoole or RoadRunner), trading PHP's traditional request isolation for a substantial throughput gain. It is an optimisation, not a requirement — most Laravel apps never need it — but if you plan to use it, it adds one more hosting constraint to the list: the ability to run and supervise a persistent application server, which again rules out conventional shared hosting.

How should you choose between hosting types?

Basic shared hosting: workable only for toy projects that use no queues and no scheduler — and given the workarounds needed, rarely worth it. A plain VPS: full control and the cheapest resources, in exchange for owning every layer above — setup, hardening, patching, and the 3 a.m. restarts. A managed app platform: the stack above provided and maintained for you, deploys from Git, workers and cron as configuration rather than server administration. The right choice tracks the same logic as choosing a host for a Next.js app: pay with time on a VPS, or with money on a platform, and be honest about which you have more of.

The bottom line

Laravel's requirements are simple to state and easy to get wrong: modern PHP with the standard extensions, Composer, a database, and — non-negotiably — real support for queue workers, cron and a public/ web root. Verify those four operational items before you pay for hosting, and most Laravel deployment horror stories become someone else's.