# Laravel 13's AI SDK Looks Easy in the Docs. Your Server Is the Hard Part.

> Laravel 13's AI SDK needs more than composer require: a supervised queue worker, pgvector or MariaDB 11.7+, and Reverb. Here is what your server must run.

Source: https://hanoo.io/blog/laravel-13-ai-sdk-hosting-requirements · Published 2026-11-01 · Updated 2026-11-01 · By the Hanoo team

Laravel 13 shipped with something the framework never had before: a first-party AI SDK. One unified API for text generation, agents with tools, image generation, audio, and vector embeddings — no more juggling three different provider packages with three different interfaces.

The quickstart in the docs takes about five lines of code. Getting it running correctly on a real server takes a bit more than `composer require`.

If you're planning to add AI agents, a document search feature, or a chatbot to a Laravel 13 app, here's what your hosting actually needs to support — and where people usually get stuck.

## What the AI SDK quietly assumes you already have

The SDK's headline features are built on top of infrastructure Laravel has supported for years, but that most small apps never turn on:

**A queue worker.** Any AI call made with `->queue()` — which you'll want for anything that calls an external model and shouldn't block a web request — needs a real queue worker running continuously, not just `php artisan queue:work` left open in a terminal that dies when you close your laptop.

**A WebSocket server, if you want live responses.** Streaming an agent's output back to the browser as it's generated (`->broadcastOnQueue()`) needs a WebSocket connection. That means Laravel Reverb, or a hosted alternative, running as its own persistent process alongside your app.

**A vector-capable database.** Semantic search — `SimilaritySearch`, embedding lookups, anything that lets an agent "remember" or search your documents — needs a `vector` column type. Laravel supports this two ways: PostgreSQL with the `pgvector` extension enabled, or MariaDB 11.7+, which has native vector support built in. Plain MySQL, or an older MariaDB version, supports neither — and on Postgres, `pgvector` has to be installed and turned on before your migrations will run.

**Migrations for conversation memory.** The trait that gives agents automatic conversation history needs its own migrations published and run. Easy to forget on a server where you don't have quick shell access.

None of this is exotic. It's the same checklist as any production Laravel app with jobs and broadcasting turned on. But it's exactly the checklist that a lot of small VPS setups and basic shared-hosting plans were never configured for, because until now, most Laravel apps didn't need all four at once.

## Where this usually goes wrong

If you're self-managing a server, the typical failure order is:

1. You install the SDK and it works locally — SQLite, Herd or Sail doing all the heavy lifting silently.
2. You deploy. The AI calls that aren't queued work fine, because they're synchronous.
3. You switch to `->queue()` for anything slow, and nothing happens — because `queue:work` isn't running as a supervised background process on the server, it's just a command you ran once over SSH and forgot about.
4. You try the similarity search feature. Error: no pgvector extension. Your managed MySQL database, or your Postgres instance that nobody configured with extensions, doesn't support it.
5. You add Reverb for streaming. Now you need a process manager watching three things instead of one — PHP-FPM, the queue worker, and Reverb — and if any of them crash silently, the AI feature just stops working with no obvious error in your logs.

Every one of these is solvable. None of them is hard individually. But stacked together, this is a half-day of server work most developers would rather not do every time they want to ship an AI feature.

## What "ready for this" actually means on a server

Before you reach for the AI SDK on a production app, check that your hosting gives you:

- A supervised queue worker that restarts itself if it crashes or the server reboots — not a `nohup` command you'll forget about.
- Postgres with `pgvector` enabled or MariaDB 11.7+, or a clear plan for where vector search will actually run if your database doesn't support it.
- A way to run a persistent WebSocket process (Reverb or equivalent) alongside your app, with its own process supervision.
- Shell or SSH access good enough to publish and run package migrations without a support ticket.

If your current host makes any one of these a multi-step fight, that's the real cost of adopting Laravel 13's nicest new feature — not the code, the ops.

## Where hanoo.io fits

This is the exact gap hanoo.io's control plane is built for: deploy your Laravel app to your own server, then run the queue worker and any other long-running process (Reverb included) as Supervisor programs from the dashboard, with the scheduler as a cron job beside them. You get their status and logs in one place, not something you set up by hand and hope survives a reboot. For vector search, managed MariaDB installs use the 11.8 LTS line, which meets Laravel's MariaDB 11.7+ requirement, so there's no extension to hunt down.

And if you're already using Claude, Cursor, or ChatGPT to write the agent code for your AI feature, hanoo.io's MCP server means the same assistant that wrote the code can also deploy it — no separate dashboard, no copy-pasting server details into a chat window.

Laravel made the AI SDK five lines of code. The hosting underneath it should be just as little work.

---

*Have a Laravel app that needs queues, a vector database, and a WebSocket server running together? [Try hanoo.io free](https://hanoo.io) — no credit card required.*