What's New in Laravel — June 2026: Scale to Zero, AI Agents Get MCP & Route Metadata

The May roundup ended on a tease: a "What's New in Laravel Cloud" event was set for June 10, the AI SDK was inching toward the 1.0 it clearly has in its sights, and the queue worker primitives still had more to give. All three threads paid off — but the month's biggest story isn't a new framework method or a flashy package. It's an economic one.

In May, Laravel Cloud made your queues autoscale. In June, it made your whole app scale to zero — and did it without the latency penalty that has made "scale to zero" a trap on every other platform. Alongside that, the AI SDK learned to speak MCP, which quietly turns every Laravel agent into something that can plug into the wider tool ecosystem. And the framework kept its steady drumbeat across eight releases.

Here's everything that moved in June 2026 across laravel/framework, laravel/ai, laravel/mcp, and the wider ecosystem.

In This Article

The short version — if you only read one section:

• "Scale to zero" finally stopped being a trap. Laravel Cloud's whole stack — compute, database, cache — now idles to zero and wakes in under 500ms via checkpoint/restore, so the old habit of keeping everything warm "just in case" is now the expensive one.
• Your agents can borrow anyone's tools. The AI SDK learned MCP: point a Laravel agent at Nightwatch, GitHub, or an internal server and its tools drop straight into the same tools() array as the ones you wrote by hand.
• The framework compounded rather than reinvented. Route metadata, a native artisan dev command, Postgres transaction-pooler support, and JSON Schema upgrades all landed quietly across v13.13 to v13.17.
• The one thing worth doing this week: audit which of your staging, preview, and internal apps still need to run 24/7. For most of them, the honest answer just changed.

Scale to Zero: Your Whole Stack Now Sleeps to $0

Every agency runs a graveyard of environments that bill 24/7 and get used a few hours a week. Staging copies. Client preview deploys waiting on sign-off. Internal dashboards someone opens twice a day. We have plenty. Each one quietly burns compute around the clock to serve traffic that arrives in short bursts. Call it the always-on tax — the gap between what an app costs to run and what it actually does.

June is the month Laravel Cloud went after that tax directly.

Why it matters: "scale to zero" is not a new idea. The problem has always been the wake-up. If an idle app takes ten seconds to answer the first request, you can't use it for anything real — so you keep it running, and you keep paying. Laravel's original scale-to-zero implementation had exactly that flaw: when an app went idle, it was removed from the compute cluster entirely. The next request hit a proxy that had to schedule a workload, pull the app image, and boot every process from scratch. That round trip took about 10 seconds. Compute slept, but databases and caches kept running, so most teams never bothered.

The June rebuild fixes the wake-up at the root. The new scale-to-zero Flex compute uses checkpoint/restore — the same family of technology as CRIU (Checkpoint/Restore In Userspace), via the zeropod runtime. Instead of a cold boot on every request, the runtime writes a complete snapshot of the app's process state — memory pages, open file descriptors, the lot — to disk on the compute node. When a request arrives, it restores from that snapshot instead of starting over. Wake time drops to under 500 milliseconds — roughly 20× faster than the old path. While the app sleeps, the only thing running is the lightweight custom runtime that knows how to bring it back.

The part that makes this genuinely useful is that the whole stack moves together:

• Compute, MySQL, and Valkey wake as a unit — but not through a central orchestrator. Compute wakes on an incoming HTTP connection or a command execution. Once it's back, it opens normal client connections to the database and cache, and those TCP connections are what wake MySQL and Valkey. Your app doesn't need to know anything was asleep; it connects, and the dependency wakes.
• The cache comes back warm. Because the runtime restores Valkey's full in-memory state, the cache looks exactly as it did before sleeping. No cold-cache stampede on the first request after a quiet night — just the small initial TCP handshake.
• No request gets dropped under a thundering herd. When several requests land on a sleeping app at once, the first triggers the wake and the rest are queued and forwarded the moment it's ready.
• Scheduled tasks still run. A separate always-on scheduler, living outside your workload, wakes sleeping apps to run schedule:run. Your app doesn't have to be awake for the scheduler to know it has work.
• There's a safety net. If a checkpoint/restore wake fails, the system falls back to a cold start — slower, but never an error on the user's side.

MySQL scale-to-zero is rolling out a little behind compute (Laravel described it as ready "in a few weeks" from the mid-June announcement), but the architecture is in place.

On the cost side, June paired the engineering with guardrails. There's a hard monthly spending limit you can set so a runaway loop or a traffic spike can't produce a surprise bill, a low-cost $5 Starter plan, and the new Flex compute sizes (512 MB, 1 GB, 2 GB) you opt into by redeploying. Laravel even shipped a "5 tips to save money on Laravel Cloud" piece and added the ability to provision a Cloud app — database, cache, credentials — straight from the Stripe CLI.

In practice, what changes for our team: that graveyard of always-on environments stops being a line item. A client preview deploy that gets opened during a weekly review can sit at zero the other six days and wake before the reviewer finishes reading the email. Internal tools, demo instances, the staging copy of a Laravel or Moodle LMS build — anything bursty — gets re-evaluated. The question flips from "can we afford to keep this warm?" to "is there any reason this shouldn't sleep?"

AI Agents Can Now Talk to MCP Servers

The most common question Laravel got about the AI SDK was a variation on one theme: can my agent talk to an MCP server? As of June, it can — and the way they built it is more interesting than a quick wrapper would have been.

Why it matters: the Model Context Protocol (MCP) is the standard way for AI models to connect to external tools and services. If your agent can consume MCP servers, it can use anything that speaks the protocol — Laravel Nightwatch, GitHub, Notion, an internal server your team runs — without you hand-writing an integration for each one. That's the difference between an agent that only knows the tools you coded and one that plugs into an entire ecosystem.

Laravel could have buried a small MCP helper inside laravel/ai and shipped it fast. They didn't, because MCP has real surface area — transports to negotiate, a handshake to perform, capabilities to advertise, and auth flows to handle. So June's release is really two features meeting in the middle:

1. An MCP client inside laravel/mcp (v0.8.0) that knows how to connect, negotiate the protocol version, authenticate, and call a server. It speaks the two transports that matter in practice — STDIO for local servers you run as a process, and streamable HTTP for remote servers — and supports bearer token, OAuth, and client-credentials auth, plus prompts and resources. 2. A thin integration in laravel/ai (v0.8.0) that lets an agent consume that client without any change to how agents already work.

That second piece is the elegant part. An agent already has a tools() method that returns the tools it can use. MCP tools just go in the same array, right next to your own:

1use Laravel\Mcp\Client;
2use Laravel\Mcp\Facades\Mcp;
3
4public function tools(): array
5{
6    return [
7        // A remote MCP server over HTTP, authenticated with a bearer token
8        ...Client::web('https://nightwatch.example.com/mcp')->withToken($token)->tools(),
9
10        // A named client you configured in a service provider (handy for OAuth servers)
11        ...Mcp::client('github')->tools(),
12
13        // A local MCP server you run as a process, over STDIO
14        ...Client::local('php', ['artisan', 'mcp:start'])->tools(),
15
16        // Your own hand-written tool, sitting right alongside the rest
17        new SendSlackMessage,
18    ];
19}

Under the hood, laravel/ai notices that some entries are MCP tools and wraps them to fit the agent's tool contract — translating the MCP input schema into Laravel's JSON Schema, calling the remote tool when the model asks, and normalizing whatever comes back. (v0.8.1 followed up by normalizing MCP tool schemas into the exact JSON Schema subset the SDK can deserialize, closing the gap on servers with unusual schemas.) The model has no idea which tools came over the wire and which you wrote yourself. They all look the same to it.

There's a nice symmetry on the server side, too. If you've already written MCP server tool classes — the ones an outside MCP host would call — you can hand those exact classes to an agent and reuse them directly, no client connection involved:

1use App\Mcp\Tools\CurrentWeatherTool;
2
3public function tools(): array
4{
5    return [
6        new CurrentWeatherTool,   // the same tool you expose to outside MCP clients
7        new SendSlackMessage,
8    ];
9}

Write the tool once; use it for both external clients and your own agents. Because the tool's request resolves through the container, dependency injection, $request->user(), and $request->validate() keep working exactly as they would anywhere else.

These MCP tools sit in the same tools() array as your own tools — and, since laravel/ai v0.6.8 back in May, alongside other agents exposed as tools. Tools, MCP servers, and sub-agents are all just entries in one list now, which is what makes genuinely composable agent systems practical in pure PHP. (Multi-agent orchestration deserves its own deep-dive; we'll give it one.)

Two practical notes from the release. First, caching: listing a server's tools is a round trip, so for a remote server behind OAuth you'll want to cache the tool list rather than pay for it on every prompt. The tools come back as plain data and rehydrate cleanly, so a cached list behaves exactly like a freshly fetched one.

Second, testing: you can test an agent that uses MCP without a live server at all. The SDK's faking layer lets you script the model's responses, and an MCP tool named search shows up as mcp_tools_search — so you assert against it exactly as you would a tool you wrote yourself.

In practice, where this lands for us: point a single ops agent at a client's Nightwatch instance (which exposes an MCP server), an internal MCP server wrapping their admin actions, and a Slack tool. "Look into the latest exception in the checkout flow and post a one-paragraph summary to #eng" then runs end to end — the agent browses Nightwatch's issues, pulls the stack trace, and calls the Slack tool, all through the same tools() array. None of it required us to write a Nightwatch integration. We wrote the Slack tool; the rest came from MCP.

The Framework Kept Moving: v13.13 to v13.17

Eight releases landed in June — v13.13.0 (June 2) through v13.17.0 (June 23), plus a v13.16.1 patch. Two additions stand out.

Route metadata (v13.17.0) makes it a first-class operation to attach arbitrary structured data to a route. You could always smuggle custom keys through the action array, but there was no supported way to attach structured data across the whole route-building pipeline. Now there is, with group cascading and dot-notation reads:

1Route::get('/users', [UserController::class, 'index'])
2    ->metadata(['head' => ['title' => 'Users']]);
3
4// Read it back off the resolved route, with an optional default:
5$request->route()->getMetadata('head.title');             // 'Users'
6$request->route()->getMetadata('head.author', 'Treesha'); // falls back to the default

Metadata set on a group cascades to every route inside it, and associative arrays merge recursively, so nested groups can layer values while lists and scalars replace inherited ones. It's stored under a dedicated metadata key on the route action, so it survives route:cache. In practice: this is the clean hook for per-route SEO defaults, feature flags, or layout hints that you previously kept in a parallel config array and looked up by route name — now it travels with the route definition itself.

php artisan dev (v13.16.0) gives the framework a native version of the composer dev pattern: one command that runs your server, queue worker, log tailing, and Vite concurrently. The win is extensibility — adding processes to composer dev was always fiddly, but now you register them from a service provider:

1DevCommands::artisan('reverb:start', 'reverb')->orange();
2DevCommands::register('stripe listen --forward-to ' . config('app.url'))->green();

It auto-detects your Node package manager (npm, yarn, pnpm, bun) and pointedly refuses to let vendor packages auto-register dev processes — a package can offer a helper you call from your own code, but it can't inject itself into your dev loop uninvited. (The v13.16.1 patch fixed an edge case where the dev command could stop itself from registering.)

The rest of the month's framework work, in brief:

• Bus::bulk() (v13.13.0) — dispatch many jobs in one call instead of looping dispatch().
• MariaDB vector index capability (v13.13.0) — native vector indexing for MariaDB, useful if your RAG or similarity-search workload lives there rather than in Postgres or a dedicated vector store.
• Postgres transaction pooler support (v13.17.0) — plays nicely with PgBouncer-style transaction pooling, which matters for serverless and high-connection-count deployments (the exact shape Scale to Zero encourages).
• Cache improvements — rememberWithState() (v13.15.0) and the ability to refresh cache locks (v13.17.0) for longer-running critical sections.
• JSON Schema deserializer upgrades — an array deserializer (v13.14.0), anyOf support (v13.16.0), and multi-type union support (v13.15.0–v13.17.0). These are quiet but strategic: they're the substrate the AI SDK leans on for structured output, so the framework and laravel/ai are improving in lockstep.

Quiet Security and DX Wins

Two security fixes in v13.15.0 are worth a prompt patch:

• Restricted allowed classes in routing unserialization (#60391) — narrows what can be unserialized during routing, closing an object-injection avenue.
• date_equals validation bypass fix (#60393) — a loose comparison let some inputs slip past the date_equals rule. If you rely on it for anything security-relevant (token expiry checks, for instance), update.

On the developer-experience side, the steady polish continued: typed translation accessors, whenFilledEnum() and improved whenEnum() on request data, withCookies() on responses, an array maintenance-mode driver that makes parallel testing cleaner, and schedule:pause now erroring out when scheduling is disabled instead of failing silently. None are headline features; together they're the accretion of small correctness wins that keep Laravel pleasant to live in.

Around the Ecosystem

Laravel Live Japan 2026 happened, and the June 17 recap is worth reading even if Tokyo wasn't on your calendar: the first-ever edition drew 550+ attendees from 40 countries, with live AI translation bridging the talks. It's also where the Nightwatch story got more stage time — the same observability work we walked through in our Nightwatch explainer earlier this month.

The community kept pace on the observability and AI-cost fronts, too. A cluster of self-hosted monitoring packages — Vigilance, Watchtower, and LaraOwl — circulated as lighter-weight alternatives for teams that want queue, schedule, and error visibility without a managed service. And USAIGE showed up to track token usage and cost for the Laravel AI SDK specifically — a fitting companion to June's broader theme of watching what your infrastructure actually costs.

What This Means for Teams Shipping Laravel

Step back and June points in two clear directions.

Cloud economics just inverted. With sub-500ms wakes, idle is no longer a latency liability, and with hard spending caps, it's no longer a financial risk either. If you make infrastructure decisions for the next few years, the default of "keep it warm just in case" deserves a fresh look — especially for the preview, staging, and internal apps that quietly dominate most agencies' compute bills. We're auditing ours.

AI is becoming infrastructure, not a feature. MCP support means a Laravel agent is now a participant in the broader tool ecosystem rather than a closed box. Combine that with the framework's JSON Schema work and the SDK's steady hardening, and "build the agent in PHP, next to the app it serves" is a more defensible architecture than it was even a month ago. The pieces — tools, MCP servers, sub-agents, structured output — are converging into one composable model.

The pace isn't slowing. MySQL scale-to-zero is landing imminently, the AI SDK keeps inching toward the 1.0 it's clearly built for, and the framework's structured-output and queue primitives still have room to run. We'll cover all of it in the July roundup.

Related reading:

• How Laravel Nightwatch Works: Why Your App Database Can't Be Your Observability Database
• What's New in Laravel — May 2026: Autoscaling Queues, AI Agents Without Python & Laravel Moat
• AI Agents in Production: Architecture, Tools & Lessons Learned
• What's New in Laravel 13: AI SDK, Vector Search & Beautiful UI

About the Author

Ritesh Patel

Co-Founder & CTO, Treesha Infotech

Co-founded Treesha Infotech and leads all technology decisions across the company. Full-stack architect with deep expertise in Laravel, Next.js, AI integrations, cloud infrastructure, and SaaS platform development. Ritesh drives engineering standards, code quality, and product innovation across every project the team delivers.

LinkedInUpwork