Laravel
Hosting

Laravel is the framework I see more often than any other on our platform. Roughly half the custom PHP applications we host for clients are Laravel apps. The reason is simple: it\'s good. The conventions make sense, the documentation is solid, the testing tools are built in rather than bolted on, and the developer experience genuinely beats most alternatives.

That said, hosting Laravel well is not the same as hosting WordPress well. WordPress is forgiving; Laravel rewards a properly configured environment and punishes a misconfigured one. The four things that separate a happy Laravel install from a sad one are: SSH access for Composer installs, queue workers for background jobs, cron for Laravel\'s scheduler, and OPcache tuned correctly.

"Laravel on shared hosting is fine for staging, hobby projects, and very small production sites. For anything serious - more than a few thousand active users, paying customers, real money - you want a managed cloud server. Not because Laravel needs it, but because production apps need things shared hosting deliberately doesn\'t do."

Mark McNeece, Founder, 365i Hosting

On our shared hosting from £5.99/mo, you get all four of those things working. SSH is available, Composer is installed, you can run `php artisan` commands directly, and queue workers can be set up via cron triggers. We pre-configure the document root to point at the `/public` directory so URLs work cleanly without exposing the rest of the application. For small Laravel apps and staging environments, this works really well.

Where I push people toward our managed cloud servers from £9.99/mo is once they cross a certain threshold. The marker I use is roughly 50,000 monthly active users, or any application taking real payment volume. At that scale you want supervisor managing your queue workers (so a crash gets restarted instantly, not at the next cron tick), you want Redis for cache and sessions (much faster than file or database drivers), and you want the ability to scale PHP-FPM workers explicitly rather than living within shared limits.

The other reality is that Laravel apps tend to grow features that need more than just PHP. Image processing benefits from Imagick or libvips. PDF generation often wants Puppeteer or wkhtmltopdf. Search wants Meilisearch or Typesense. Real-time features want Reverb or Laravel WebSockets. All of these are easy on a cloud server with root access; on shared hosting they range from "possible with workarounds" to "no".

I run our own internal tools on Laravel, and our managed cloud platform is where I host them. The pattern that works is: dev locally with Sail or Herd, push to a Git repo, deploy to a staging environment on shared hosting (cheap and good enough), then promote to a cloud server for production. That gives you environment parity with cost parity to match: pay for cloud only where it earns its keep.

One thing I always recommend regardless of plan: use a deployment tool. Laravel\'s ecosystem has Envoyer, Deployer, and Forge\'s deployment hooks. We support Git deploy on cloud servers and webhooks on shared. The day you start deploying via FTP is the day something breaks at 5pm on a Friday. Don\'t do it.