Hosting and Maintenance for Laravel Applications

A Laravel application is not a brochure site, and hosting that treats it as one breaks in predictable ways: the scheduler never runs, queued work piles up silently, and a deploy leaves the app in maintenance mode at five on a Friday.

The parts shared hosting gets wrong

Queue workers

Workers are supervised, so a worker that dies is restarted rather than quietly stopping. Long running jobs get a queue that will not kill them partway through, which is a mistake worth avoiding: a default worker configuration that terminates long jobs will fail your largest ones and succeed with everything else, so it looks like a bug in your code.

The scheduler

One cron entry calling the scheduler, running as the right user, with its output captured somewhere you can read it. If a scheduled task fails we would rather you heard it from us.

PHP version

Set per site, so upgrading one application does not require coordinating with every other thing on the box.

Deploys, staging and getting back

Each site can have a staging copy on the same server with its own database. You can publish staging over production when you are satisfied, and roll back if the result is not what you expected. The rollback is the part that matters, and it is the part most arrangements leave out.

Caching, data and secrets

• In-memory caching available per site for cache, sessions and queues.
• Databases backed up individually and offsite, with grants captured too, so a restore produces a working application and not just a set of tables.
• Your environment file is refused at the edge. Requests for .env, .git and the usual list of credential filenames are blocked before they reach the application. This is not theoretical: it is among the most common requests we see across every site we host.

What you can see

Your team gets My Cloud Manager accounts showing uptime, response times, recent deploys and the state of each environment, with roles so that read only access is actually read only. Monitoring checks that the application responded, not merely that a cached page was returned.

Where we are a good fit, and where we are not

We suit applications that want a managed server and a person to call: internal tools, client portals, line of business applications, sites with a few hundred thousand requests a month. If you need autoscaling across regions, or you are deploying dozens of times a day through your own pipeline, a platform built for that will serve you better and we will say so.

Laravel is a trademark of Laravel Holdings Inc. We are an independent hosting provider and are not affiliated with, endorsed by, or sponsored by them.