Somewhere in the Laravel app you're running right now, there's a good chance an HTTP call goes out to OpenAI, Anthropic, or a local model. A chat feature, a summarizer, an agent that triages support tickets. Laravel 13 shipped in March 2026 with first-party AI primitives and the framework now literally brands itself as being for "Artisans and agents". The application layer has never been easier.
The server layer is another story. An LLM call breaks almost every assumption your default server config makes. Requests that last 30 to 120 seconds instead of 200 milliseconds. Responses that arrive token by token instead of all at once. Failures that are retry-able but cost real money every time you retry them. Nobody's hosting docs cover this, so here's the guide we wish existed: the actual server-side ops of running LLM workloads on a Laravel VPS.
Your stack was tuned for short requests. Every layer between the browser and the LLM API has a timeout or a buffer, and nearly all of them are wrong for AI workloads:
Layer
Default
Why it breaks
PHP max_execution_time
A 45-second completion dies mid-request
Nginx fastcgi_read_timeout
Nginx returns a 504 while the model is still thinking
Nginx FastCGI buffering
On
Streamed tokens sit in a buffer; the user sees nothing, then everything
Laravel HTTP client
Long completions throw ConnectionException
Queue retry_after
A 2-minute job gets handed to a second worker and billed twice
That last row is the expensive one, and we'll spend a whole section on it. But first, the rule that prevents most of these problems from mattering at all.
Never make an LLM call inside a web request if you can possibly avoid it. A synchronous call ties up a PHP-FPM worker for the full duration of the completion. With the default pm.max_children
on a small VPS, a dozen users triggering AI features simultaneously can exhaust your entire FPM pool, and now your login page is timing out because your summarizer is slow.
Queued jobs fix the architecture. The web request dispatches a job and returns in milliseconds. A dedicated worker makes the slow call. The result comes back to the user via polling, broadcasting, or a stream (more on that below).
Here's a job skeleton with every LLM-specific concern handled:
php