# Deploying AI-Powered Laravel Apps: Queues, Streaming, Timeouts > Source: > Published: 2026-07-16 08:11:53+00:00 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](https://laravel-news.com/laravel-13) with [first-party AI primitives](https://laravel.com/docs/13.x/releases) and the framework now literally brands itself as being for ["Artisans and agents"](https://laravel.com). 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 ```