Dedicated Server for Laravel: What Production Hosting Actually Needs

Laravel runs fine on shared hosting for development or a very low-traffic app, but production Laravel has specific infrastructure requirements that shared hosting structurally cannot provide, which is where a dedicated server (or at minimum a VPS with root access) becomes necessary rather than optional.

Persistent Queue Workers

Any Laravel app using queued jobs (email sending, image processing, notifications, anything dispatched via Bus::dispatch or a job class) needs a long-running worker process (php artisan queue:work) supervised to restart automatically if it crashes. Shared hosting's process limits and lack of persistent background processes make this structurally impossible without workarounds. On a dedicated server, Supervisor (or systemd) manages the worker process directly, restarting it on failure and allowing multiple worker processes for parallel job processing.

PHP-FPM Pool Tuning

Default PHP-FPM settings are conservative and rarely match real traffic patterns. The three settings worth tuning specifically for a Laravel app are pm.max_children (total concurrent PHP processes, sized against available RAM divided by average process memory footprint), pm.max_requests (restarting workers periodically to avoid memory leaks accumulating over the process lifetime), and OPcache settings (opcache.enable, adequate opcache.memory_consumption, and critically opcache.validate_timestamps=0 in production so PHP does not re-check every file's modification time on every request).

Redis, Not Just for Cache

Laravel's default file-based cache and session drivers work but do not scale past a single server and add filesystem I/O overhead under load. Redis as the cache, session, and queue driver removes that I/O overhead entirely (operating in memory) and is a prerequisite for horizontal scaling later if the app ever needs to run across multiple app servers behind a load balancer.

Scheduled Tasks via Cron

Laravel's task scheduler (php artisan schedule:run) needs exactly one cron entry running every minute, which then internally decides what actually needs to execute based on each scheduled task's own frequency definition in the app's code. This is a single, simple cron entry, but it needs a real server cron, which is straightforward on a dedicated server and can be more fragile on constrained shared hosting cron implementations.

A Realistic Sizing Starting Point

A small-to-mid Laravel production app (a business admin panel, a moderate-traffic customer site) runs comfortably on 2-4 vCPU cores and 4-8GB RAM, with NVMe storage mattering more than raw CPU count for database-heavy apps. Sizing grows from there based on concurrent user count and how database-query-heavy the app's actual workload is, not simply "site traffic" in isolation.

Frequently Asked Questions

Does Laravel require a dedicated server, or is VPS enough?

A VPS with root access covers most Laravel apps' actual requirements (queue workers, cron, Redis); a dedicated server becomes relevant specifically when you need guaranteed, non-shared CPU and I/O for consistent performance under heavy concurrent load.

What breaks first if PHP-FPM is left at default settings under real traffic?

Usually pm.max_children being too low causes requests to queue and time out under concurrent load, well before CPU or RAM are actually exhausted — a config problem masquerading as a capacity problem.

Is Supervisor required, or can queue workers just run manually?

Supervisor (or an equivalent process manager) is effectively required for production — a manually started worker process dies on server reboot or any crash with no automatic restart, silently stopping all queued job processing until someone notices.