DEV Community: Hafiz

Pest 5 TIA: Run Only the Tests Your Code Change Touched

Hafiz — Thu, 30 Jul 2026 05:22:01 +0000

Nuno Maduro announced Pest 5 on stage at Laracon US yesterday, and one feature is worth your attention today: the Tia Engine. TIA stands for Test Impact Analysis, and the pitch is simple enough to sound too good to be true. A Laravel suite that took 10 minutes now finishes in around 4 seconds, because Pest reruns only the tests your latest change could actually break and replays cached results for everything else.

This shipped yesterday, so this is a walkthrough of how it works from the docs and the release, not a battle-tested war story. I'll be clear about what's proven and what you'll want to verify on your own suite. But the mechanism is well documented, the numbers come from Pest directly, and the setup really is a one-flag start. Here's what TIA does, how to turn it on, the CI trick that makes it fast for your whole team, and the catch nobody mentions in the announcement tweets.

What Test Impact Analysis Actually Does

The idea behind TIA isn't new (large monorepos at Google and Meta have done impact analysis for years), but it's new to have it built into a PHP testing framework you already use. The concept: most of your test suite is irrelevant to any given change. You edit one model, and 765 of your 774 tests couldn't possibly behave differently. Running all 774 is wasted time. TIA figures out which handful actually depend on what you touched, runs those, and reconstructs the rest from cache.

The first run builds a baseline: Pest records a dependency graph of which tests exercise which files. Every run after that is a replay. Pest diffs your working tree against the baseline and reruns only the affected tests. The output tells you exactly what happened:

Tests:    774 passed (2658 assertions, 7 affected, 2 uncached, 765 replayed)
Duration: 3.92s

Read that line: 7 tests actually ran because their dependencies changed, 2 ran because no cached result existed yet, and 765 were served from cache. Four seconds instead of ten minutes.

The part I found most reassuring in the docs: a replay isn't a shortcut that skips coverage. Pest stores what each test covered, down to lines and branches, so a replayed run reports the same coverage as a full run. Your --coverage report, coverage thresholds, and --min all behave as if every test executed. You get the speed without lying to your coverage gate.

Turning It On

One flag on any Pest invocation:

./vendor/bin/pest --parallel --tia

There's one hard requirement, and it's the thing that'll trip people up: TIA needs a code coverage driver, either PCOV or Xdebug, installed and enabled. Pest uses it to record which files each test touches while building the baseline. No coverage driver, no dependency graph, no TIA. If you already run coverage in CI you have this; if you've never installed PCOV locally, that's your first step.

The other requirement is the bigger gate: Pest 5 requires PHP 8.4 or higher. It's built on PHP 8.4 and PHPUnit 13. If you're on an older PHP version, TIA is a reason to plan the upgrade, not something you can try this afternoon. (If you're mid-migration on the framework side, my Laravel 12 to 13 upgrade guide covers that half.)

If you'd rather not type the flag every time, configure it in tests/Pest.php:

pest()->tia()
    ->always()     // run TIA on every invocation, no --tia flag
    ->locally()    // but only on local machines, skip on CI
    ->baselined()  // fetch the shared baseline from CI when missing
    ->filtered();  // narrow PHPUnit to only affected test files

The always()->locally() pairing is the sensible default for most teams: fast replays while you work, full runs on CI where you want every test to execute for real. An explicit --tia always wins, and --no-tia disables it for a single run.

How TIA Decides What To Rerun

This is where it stops being magic and starts being understandable, and understanding it is what tells you whether to trust it. TIA maps different file types to tests in different ways:

For PHP source files, the coverage driver does the work. Change app/Models/User.php and Pest reruns only tests that touched User. For migrations, Pest intersects the change against the tables each test queried during the baseline, so a column rename in the users migration reruns only tests that hit the users table. Blade templates rerun only the tests that rendered them. If you're on Inertia, Pest walks Vite's module graph to trace which pages import a changed component and reruns only the tests that server-side-rendered those pages.

Then there's the honest fallback. Config files, route files, fixtures, anything outside the recorded graph triggers a broader pattern. Edit config/app.php and Pest reruns the entire suite, because it can't statically prove which tests depend on it. That's the correct behavior, and it's a good sign: TIA errs toward running too much rather than missing a regression. Some changes rebuild the graph itself, like composer.lock, phpunit.xml, and Node lockfiles.

The Detail That Sells It: Cosmetic Edits Run Nothing

Here's the feature that makes TIA feel different from a dumb file-timestamp cache. Pest normalizes file content before comparing. PHP files get whitespace, line comments, and docblocks stripped before hashing. Blade strips its {{-- --}} comments. JS, TS, Vue, and Svelte lose their comments too.

The practical result: a comment-only edit, a Prettier reformat, a Pint pass, or a README tweak produces an identical hash. The file never enters the changed set. Zero tests run. If you've ever watched your full suite grind through CI because someone reformatted a file, you understand why that matters.

Sharing the Baseline: The CI Trick

Recording the baseline takes as long as one full suite run, which on a large project is minutes. Paying that on every developer's machine, and every fresh checkout, would undercut the whole point. Pest's answer: record the baseline once in CI, and have everyone else download it.

You enable fetching with pest()->tia()->baselined() in tests/Pest.php (preferred for teams). When Pest finds no local graph, it uses the GitHub CLI to pull the pest-tia-baseline artifact from your latest successful baseline workflow, validates it against your project state, and adopts it if it matches. Every developer's first --tia run then replays immediately, paying no record cost.

The workflow that produces that artifact, dropped into .github/workflows/tia-baseline.yml:

name: TIA Baseline
on:
  push: { branches: [main] }
  schedule: [{ cron: '0 3 * * *' }]
  workflow_dispatch:
jobs:
  baseline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - uses: shivammathur/setup-php@v2
        with: { php-version: '8.4', coverage: xdebug }
      - run: composer install --no-interaction --prefer-dist
      - name: Run tests
        run: ./vendor/bin/pest --parallel --tia --coverage --fresh
      - name: Resolve TIA baseline path
        id: baseline
        run: echo "path=$(./vendor/bin/pest --baseline)" >> "$GITHUB_OUTPUT"
      - name: Upload TIA baseline
        uses: actions/upload-artifact@v4
        with:
          name: pest-tia-baseline
          path: ${{ steps.baseline.outputs.path }}
          include-hidden-files: true
          retention-days: 30

Two things to know here. ./vendor/bin/pest --baseline prints the absolute path to the TIA storage directory (~/.pest/tia/<project-key>/), which is what the upload step bundles. And include-hidden-files: true is required, because that directory is dot-prefixed and Actions skips hidden files by default. Fetching relies on the GitHub CLI being installed and authenticated, so it's GitHub-only for now; on any failure Pest falls back to recording locally and tells you why. If you don't have a Pest CI pipeline yet, my GitHub Actions guide for Laravel is the place to start before wiring this in.

The Catch Nobody's Tweeting About

The announcement numbers are real, but here's what to keep in mind before you assume your suite drops to 4 seconds tomorrow.

TIA's speedup is proportional to how well-isolated your tests are. If most of your tests are unit tests touching a handful of classes, a small change reruns almost nothing and you get the headline numbers. If your suite is mostly full feature tests that boot the whole app and hit the database, more of them qualify as "affected" by any given change, and the win shrinks. The 10-minutes-to-4-seconds figure describes a well-structured suite, not a guaranteed outcome for every codebase.

There's also a trust question worth being deliberate about. TIA is deciding not to run tests. That's the entire point, and the coverage-fidelity design is reassuring, but this is day-one software. The safe pattern is exactly what the config nudges you toward: always()->locally() for fast local replays, and full untia'd runs on CI as the source of truth. Let TIA speed up your inner loop first. Trust it to gate your deploys only once you've watched it behave on your real codebase for a while. That's not skepticism about Pest; it's how you'd adopt any tool that skips work on your behalf.

What Else Shipped in Pest 5

TIA is the headline, but the release bundled several first-party plugins that matured across the Pest 4 cycle. Worth knowing they exist:

The Agent plugin gives AI coding agents a single command to verify a change actually works against your real suite, and with the Browser plugin, in a real browser too. Evals let you score LLM output and AI-generated results from inside your test suite, mixing deterministic checks with AI scorers. And PHPStan and Rector are now built in, so static analysis and automated refactoring live alongside your tests instead of as separate tooling. If you're still on Pest 4, my complete Pest 4 testing guide still applies for the fundamentals; Pest 5's testing API is the same, with these plugins layered on top.

FAQ

Do I need to change how I write tests to use Pest 5 TIA?

No. TIA works with your existing tests unchanged. You add the --tia flag (or configure it in tests/Pest.php) and Pest builds the dependency graph automatically from a normal run. Your test files, expectations, and structure stay exactly as they are.

Does TIA reduce my code coverage numbers?

No, and this is the clever part. When Pest caches a test it stores the exact lines and branches that test covered, so a replayed run reports the same coverage as a full run. Coverage thresholds, the --coverage report, and --min all behave as if every test executed from scratch.

What happens when I change a config or route file?

Pest reruns the entire suite. Files outside the recorded dependency graph, including config and route files, can't be statically traced to specific tests, so TIA falls back to running everything rather than risk missing a regression. It errs toward safety.

Can my whole team skip the slow first baseline run?

Yes, if you're on GitHub. Record the baseline once in a CI workflow, upload it as the pest-tia-baseline artifact, and enable pest()->tia()->baselined(). Each developer's first --tia run downloads that baseline and replays immediately instead of recording locally. It relies on the GitHub CLI, so it's GitHub-only for now.

Should I trust TIA to gate my production deploys?

Be cautious at first. TIA shipped at Laracon US 2026, so it's brand new. The sensible adoption path is always()->locally(): fast replays while you develop, full runs on CI as your source of truth. Once you've watched TIA behave correctly on your real suite over time, you can decide whether to lean on it further.

Does Pest 5 TIA need a specific PHP version?

Yes. Pest 5 requires PHP 8.4 or greater and is built on PHPUnit 13. TIA also needs a coverage driver (PCOV or Xdebug) to record the baseline. If you're on an older PHP version, upgrading is a prerequisite.

Wrapping Up

TIA is the kind of feature that changes a daily habit rather than adding one. The slow test suite you run less often than you should, or gate behind a coffee break, becomes something fast enough to run after every save. Add --tia, make sure you've got PHP 8.4 and a coverage driver, and let it speed up your local loop first. Wire up the CI baseline once your team wants the shared graph. And keep your CI running the full suite untia'd until you've earned trust in the replays on your own codebase.

Laravel Scout in 2026: Meilisearch vs Typesense vs Algolia vs Database Driver

Hafiz — Mon, 27 Jul 2026 06:41:24 +0000

Laravel Scout gives you full-text search on your Eloquent models with one trait and a config value. What it doesn't give you is an opinion. The docs list five drivers (Algolia, Meilisearch, Typesense, database, and collection) and treat them as interchangeable. They're not. The driver you pick decides whether search costs you nothing, a fixed monthly fee, or a bill that grows every time your product succeeds.

I've shipped Scout with three of these drivers across client projects and my own products. This post is the comparison I wish existed: what each driver actually does, what it costs at real usage levels, and a straight answer on which one to pick.

What Scout Actually Abstracts

Quick grounding for anyone who hasn't used it. Scout syncs your models to a search index automatically. Add the Searchable trait, and every create, update, and delete flows through to your search engine via model observers:

use Laravel\Scout\Searchable;

class Post extends Model
{
    use Searchable;

    public function toSearchableArray(): array
    {
        return [
            'title' => $this->title,
            'body' => strip_tags($this->body),
        ];
    }
}

Searching is one line: Post::search('pgbouncer')->paginate(15). The abstraction is the whole point: your application code stays identical across all five drivers, which means the driver decision is about operations and money, not code.

One setting that isn't optional in production: 'queue' => true in config/scout.php. Without it, every model save blocks on an HTTP call to your search engine. Push index updates through your queue workers and the write path stays fast. And a detail that surprises people: even with queueing off, Algolia and Meilisearch index asynchronously on their side. Your job finishing doesn't mean the record is searchable yet. Write your tests accordingly.

The Four Real Contenders

The collection driver filters records in PHP after pulling them all from the database. It exists for local development and works everywhere, including SQLite. It's not a production option, so it's out of the comparison. That leaves four.

The database driver runs full-text indexes and LIKE clauses against MySQL or PostgreSQL. No new infrastructure, no sync problems (it queries your actual tables), no cost. Also: no typo tolerance, no relevance tuning worth the name, no facets.

Meilisearch is an open-source engine written in Rust. Sub-50ms responses, typo tolerance, faceting, and highlighting out of the box with almost no configuration. Its defaults are good enough that most projects never touch relevance settings. Self-host it free (MIT license) or use Meilisearch Cloud.

Typesense is the closest thing Meilisearch has to a twin: open-source, typo-tolerant, instant search, written in C++. It differentiates on operational predictability. Typesense Cloud gives you a dedicated cluster priced by RAM and CPU per hour, with no per-record or per-operation charges at all. It also has more mature vector and geo search than Meilisearch.

Algolia is the incumbent hosted service. The most polished dashboards, the best frontend libraries (InstantSearch), AI re-ranking, and enterprise features nobody else matches. You pay for it with usage-based pricing that scales with your traffic.

Feature Comparison: Where They Actually Differ

On core search quality (typo tolerance, prefix matching, ranking) Meilisearch, Typesense, and Algolia are closer than their marketing suggests. All three return results in tens of milliseconds and handle "labrvel" finding "laravel" without configuration. For a typical SaaS search box, users can't tell them apart.

The differences live at the edges. Algolia leads on merchandising and AI features: synonyms management, A/B testing relevance, personalization. If you're building e-commerce search where a 2% conversion lift pays for the tooling, that matters. Typesense leads on vector search and its Search Delivery Network, which replicates your index across regions like a CDN. Meilisearch leads on getting to good results with the least configuration of the three.

The database driver isn't playing the same sport. It matches words, roughly in the order your database returns them. Search for "posgres" and you get nothing, because there's no typo tolerance. For a public-facing product search, that's disqualifying. For an admin panel where your team searches customers by name or email, it's completely fine, and I'd argue anything more is over-engineering.

The Money: What Search Actually Costs

This is where the comparison stops being close, so let's do real math. All prices verified this week; search providers change pricing often, so treat these as July 2026 numbers.

Algolia has a free Build tier (10,000 search requests a month) that's generous for prototyping. The paid Grow plan is pay-as-you-go: $0.50 per 1,000 search requests and $0.40 per 1,000 records beyond the included 10,000 requests and 100,000 records. Grow Plus, which adds the AI features, jumps to $1.75 per 1,000 requests.

Meilisearch Cloud starts at $30/month for the Build plan and climbs into the hundreds at the million-document tier. Self-hosting is free under MIT.

Typesense Cloud bills the cluster, not the usage: pick RAM and CPU, pay per hour it runs. The smallest configurations work out to roughly $7-25/month, and you can throw as many searches at it as the hardware handles. Self-hosting is free.

The database driver costs zero. Your database is already running.

Now the worked example. Say your app does 500,000 searches a month across 250,000 records, a realistic mid-sized SaaS:

Algolia Grow: 490,000 billable requests ($245) plus 150,000 extra records ($60) lands around $305/month. Every new user who searches makes next month's bill bigger. Meilisearch Cloud at that document count sits in its higher tiers, roughly the $200-300/month range. Typesense Cloud handles that load comfortably on a small dedicated cluster in the $25-70/month range, and the bill doesn't move when traffic doubles until the hardware runs out. Self-hosted Meilisearch or Typesense on a basic Hetzner or DigitalOcean instance: about €5-10/month for the server, and the real cost is you being the person who gets paged.

That's a 30x spread for the same feature. The pricing model matters more than the sticker price: Algolia charges you for growth, Typesense charges you for capacity, self-hosting charges you in responsibility.

When the Database Driver Is Honestly Enough

The advice you'll find everywhere is "just use Meilisearch," and it's not wrong. But I want to defend the boring option, because I keep seeing projects run a search server for workloads that don't need one.

Use the database driver when all of these are true: your searchable dataset is under roughly 100,000 rows, your users are internal or forgiving (admin panels, back-office tools, MVPs), and you're searching short fields like names, emails, and titles. MySQL and Postgres full-text indexes are fast at this scale, and a proper index is the only tuning you'll ever do. You skip a service, a sync pipeline, a deploy dependency, and a monthly bill.

Move up when users start expecting typo tolerance, when you need facets and filters on the search page, or when search becomes part of the product rather than a utility. You'll feel the moment. And because Scout abstracts the engine, the migration is a config change plus php artisan scout:import, not a rewrite. That's the quiet superpower of building on Scout even when you start on the database driver.

My Recommendation

For most Laravel apps in 2026: self-hosted Meilisearch if you already run a VPS, Typesense Cloud if you don't want to.

Meilisearch wins the self-host case because it's the least operational search server I've run: one binary, sane defaults, and it sits happily in 512MB of RAM for small datasets. If you deploy with Docker or manage a Hetzner box already, adding it costs you an evening. Typesense wins the managed case because resource-based pricing means your search bill is a known number, and known numbers are worth a lot to a bootstrapped product. A SaaS charging monthly should not have a cost line that scales per-search.

Pick Algolia when its extras are the point: merchandising tools, the InstantSearch frontend stack, AI ranking for an e-commerce catalog where relevance is revenue. It's the best product of the three and priced like it knows.

And pick the database driver more often than the internet suggests. Half the Scout setups I've reviewed could have been a full-text index.

One operational note whichever engine you choose: if you're running Octane or serious queue concurrency, keep Scout's queue on and give indexing jobs their own queue name. A bulk import re-indexing 100K models on the same queue as your password-reset emails is a bad afternoon.

FAQ

Can Laravel Scout do semantic or vector search?

Scout itself is engine-agnostic, so it depends on the driver. Typesense has the most mature vector search of the three engines; Meilisearch's is newer and improving fast. If semantic search is central to your product, that's a different architecture conversation than a search box, and I've covered the options in my guide to full-text, semantic, and vector search in Laravel.

Which Scout driver is fastest?

For end-user perception, Meilisearch, Typesense, and Algolia are all effectively instant (tens of milliseconds) on typical datasets. The database driver is fast at small scale and degrades as tables grow and queries lean on LIKE. If you're choosing between the three engines on latency alone, you're optimizing the wrong variable; choose on cost model and features.

Does switching Scout drivers require code changes?

Almost none, and that's Scout's best feature. Your models, toSearchableArray(), and search calls stay the same. You change SCOUT_DRIVER, add the new engine's credentials, and run php artisan scout:import to build the index. The exceptions are engine-specific features like Typesense's schema definitions or Algolia-specific query options, which you'd need to recreate or remove.

Is the database driver production-ready?

Yes, within its limits. It uses real full-text indexes on MySQL and PostgreSQL rather than naive LIKE scans, and it can't drift out of sync because it queries your actual tables. What it lacks is typo tolerance, ranked relevance, and facets. Internal tools and small catalogs: absolutely. Public product search where users type fast and expect Google-ish forgiveness: use a real engine.

Do I need Scout at all, or can I use Meilisearch directly?

You can use any engine's SDK directly, and for complex multi-index setups some teams do. Scout earns its place through the automatic model syncing and the driver abstraction that makes engines swappable. For the common case of "make these models searchable," writing your own sync layer is reinventing a wheel Scout ships for free.

Wrapping Up

Scout's driver choice is a cost-model choice wearing a technical costume. The database driver is free and underrated for internal tools. Self-hosted Meilisearch is the sweet spot for developers who already run servers. Typesense Cloud buys you a predictable bill. Algolia buys you the most product for the most money, priced per unit of your own growth. Start boring, and let Scout's abstraction make the upgrade a config change instead of a project.

Setting up search for a Laravel app, or trying to cut an Algolia bill that grew faster than revenue? I've done both and I'm happy to talk through your setup. Get in touch.

Laravel Telegram Bot: How I Cleared My YouTube Watch Later with AI Summaries

Hafiz — Thu, 23 Jul 2026 12:28:54 +0000

My YouTube Watch Later had 42 videos in it. I'd watched maybe ten. X bookmarks were worse because I couldn't even remember why I'd saved half of them. Every platform has a save button, and every save button leads to the same place: a list nobody ever opens again.

The obvious fix is "build something that syncs those lists and reminds you." I tried. That version is impossible, and knowing why shapes the whole design. So I built the opposite: a Telegram bot backed by a small Laravel app that replaces the save button instead of syncing it. I forward a link, it fetches the content, summarizes it with the AI SDK, and then, once a day, it forces me to decide: watch, snooze, or archive.

I've been running it for ten days. Here's the build, including the security bug that almost shipped and the fallback path that fires way more often than I expected.

Why You Can't Sync Watch Later (So Stop Trying)

The dream version of this tool connects to your accounts and pulls your saved items. Two hard walls and one soft one:

YouTube's Data API deliberately excludes the Watch Later playlist. Access was removed years ago and never came back. You can read any playlist except that one.

Facebook's saved items have no API at all.

X bookmarks are the soft one. They do have an API, and since April 2026 reading your own data costs $0.001 per item, so pulling a thousand bookmarks runs about a dollar. But you still need a paid developer account with credits loaded and an OAuth flow to get there, and it only solves X. YouTube and Facebook stay shut either way.

This is why no existing tool does real sync. The workaround is to own the capture step: don't read their list, become the list. On mobile that's the native share sheet, which already has Telegram in it. Share, tap the bot, done. On desktop it's a bookmarklet that POSTs the current URL to the app. Either way, the platform's save button never gets touched again.

The Architecture

The stack is deliberately boring: Laravel 13, SQLite in WAL mode, the database queue driver, and the Telegram Bot API called through plain HTTP. No Telegram SDK package. The bot surface is four methods (sendMessage, editMessageText, answerCallbackQuery, setWebhook), and a thin service class wrapping Laravel's Http client covers them in about 60 lines. Zero extra infrastructure: no Redis, no Node process, no third-party queue.

There's also no frontend. Telegram is the UI, which means the tool works on mobile, desktop, and web from day one without me writing a single screen.

The flow from save to digest looks like this:

The webhook does three jobs: it accepts new links, it answers commands like /stats, and it handles the button presses coming back from digest messages. Everything slow happens in a queued job, so the bot always answers in under a second with "Saving..." before the real confirmation arrives.

Cleaning URLs Is Half the Feature

The first thing the SaveUrl action does is canonicalize. The same video arrives as youtube.com/watch, youtu.be, a Shorts URL, or any of those with tracking junk attached (si=, utm_*, the X s= and t= params). All of them collapse to one canonical form, so saving the same video twice gets caught as a duplicate instead of cluttering the inbox. Timestamps survive the cleaning because "watch from 18:30" is information I actually want.

One small decision I like: re-saving something already watched or archived revives it back to the inbox. If I cared enough to save it twice, it's relevant again.

Fetching Content Without Scraping Anything

For YouTube, oEmbed gives me the title and channel for free, no API key. Duration comes from the Data API's videos.list if a key is present, and gets skipped when it's not. Transcripts are best-effort against the caption endpoints.

For X, the public oEmbed endpoint at publish.twitter.com returns the tweet text and author for any public tweet. No auth, no paid tier. That's the entire "X integration."

Everything else falls through to an article fetcher that grabs the title tag and meta description. Not glamorous, works fine.

Then the queue job hands whatever content it collected to the AI SDK with a schema-validated structured output request: a two-to-four sentence summary plus three to five lowercase tags, returned as strict JSON. If you haven't used structured outputs in the SDK yet, the smart assistant tutorial covers the pattern; it's the same idea here with a smaller schema.

The app runs DeepSeek by default because summaries are a cheap-model task, but the provider is configuration, not code. Two env vars switch it to Anthropic or OpenAI, and the same swap works for local models through Ollama if you want summaries that cost nothing. Since the SDK went stable, this kind of provider independence is the main reason I keep reaching for it in side projects.

The "Probably:" Fallback Fires More Than You'd Think

Here's the honest part. YouTube transcript fetching fails constantly. Captions are disabled, auto-captions aren't exposed, the endpoint shape shifts. I expected transcripts to be the normal path and the fallback to be rare. Ten days of real usage says it's closer to the other way around.

So the fallback is a first-class feature, not an error state. When there's no transcript, the model summarizes from the title and channel alone, and the summary is prefixed with "Probably:" so I know it's an educated guess rather than a digest of the actual content. Treating low confidence as something to label instead of hide turned out to be the right call. A guessed summary still answers the only question that matters at digest time: do I still care about this?

If I later want real transcripts, the escape hatch is downloading captions server-side per video. That's a v2 problem. For deciding watch-or-archive, "Probably:" is enough.

One Item a Day, Three Buttons

Every evening at 19:00 the scheduler picks exactly one item and sends it with its summary and three inline buttons: Watch, Snooze 7d, Archive.

The selection logic matters more than it looks. Due snoozes win first, oldest snooze first. Otherwise it picks from the inbox: never-surfaced items first, then whatever was surfaced longest ago. That rotation means ignoring a digest doesn't show you the same item every day forever, which is exactly the failure mode that makes reminder apps unbearable.

The buttons edit the original message in place. Tap Watch and the message updates to show the plain URL so it unfurls and I can tap through. Tap Archive and it becomes one line. No app, no tab, a two-second decision inside a chat I already have open.

And because guilt is the actual product being fought here: anything untouched for 90 days gets auto-archived by a weekly job. The clock keys on updated_at, so snoozing counts as engagement and resets it. The list can only shrink.

A /stats command replaces the dashboard I refused to build. Inbox count, watched, archived, watch rate, age of the oldest item. One message. That's the whole confession.

The Bug That Almost Shipped: hash_equals('', '')

The first live smoke test caught something the 47 passing tests didn't. With a fresh .env where the secrets weren't filled in yet, every authenticated endpoint let everyone in.

The webhook check compared the configured secret against the header Telegram sends. The ingest endpoint compared the configured token against the bearer token. Both used hash_equals(). And hash_equals('', '') returns true, because an empty string does equal an empty string. Blank config plus absent header equals open endpoint, on a public VPS.

The tests never caught it because every test sets the secrets. Real config drift is exactly the case your test suite doesn't model.

The fix is a rule worth stealing for any personal tool: fail closed when config is blank. Every auth check now short-circuits to a 403 if the configured secret is empty, before any comparison runs, with regression tests pinning it. If a required secret isn't set, the correct behavior is "nothing works," never "everything works."

What I Deliberately Didn't Build

No user accounts, no dashboard, no Chrome extension, no Facebook support, no multi-tenancy. This is a single-user tool on my own VPS, and every one of those features would have turned a weekend build into a month of speculation about users who don't exist yet.

That's also my honest recommendation if you build one: resist the SaaS reflex. The value here is that it's yours, it's small, and it costs nothing to run. SQLite plus the database queue on a box you already have is the whole bill. If strangers start asking to use it, that's a different project and a different decision, and it should be made then, with real people asking, not upfront.

FAQ

Why can't it just read my existing YouTube Watch Later list?

Because the API doesn't allow it. YouTube removed Watch Later access from the Data API years ago, and no official way back exists. Any tool claiming to sync it is scraping, which breaks routinely. Replacing the save action is the reliable path.

What happens if I don't configure an AI provider?

Links still get saved with full metadata (title, channel, duration). The bot just says no summary is configured. The AI layer is optional, not a dependency.

Why Telegram instead of WhatsApp?

Telegram's Bot API is free, instant to set up, and supports inline buttons and message editing, which the digest depends on. WhatsApp's Business API costs money and requires approval. This isn't close.

Does it handle X bookmarks?

It replaces them rather than reading them. The bookmarks API is affordable now (roughly a dollar per thousand of your own items since April 2026), but it needs a funded developer account and an OAuth flow, and it only covers X. The public oEmbed endpoint returns any public tweet's text for free, so forwarding a tweet link gets you the same summarize-and-resurface treatment with no account at all.

How does it decide which item to resurface?

Due snoozes first, then never-surfaced inbox items oldest-first, then the item that's gone longest without being shown. Ignoring the digest rotates the backlog instead of repeating one item, and anything untouched for 90 days archives itself.

Watch Rate Over Library Size

Ten days in: 12 sitting in the inbox, 7 watched, 3 archived, one snoozed. That's a 70% watch rate on the things I've actually decided about, and I'll be honest that the number flatters me. These are still the early days and the sample is ten decisions. Ask again in a month when the novelty has worn off.

The whole thing is on GitHub at hzeeshan/watch-later if you want to run your own. It's a single-user tool by design, so expect to spend ten minutes on a bot token and a cron entry rather than a signup form.

Laravel PostgreSQL Connection Pooling: Native PgBouncer Support Is Here

Hafiz — Wed, 22 Jul 2026 10:31:23 +0000

Laravel PostgreSQL connection pooling used to mean one thing: workarounds. If you've ever run Laravel against Supabase, Neon, or a self-hosted PgBouncer, you know the ritual. Set PDO::ATTR_EMULATE_PREPARES, install a community package to patch boolean bindings, keep a second connection config for migrations, and hope nobody on the team forgets which one is which.

That ritual is over. Laravel 13.17 shipped framework-level support for Postgres transaction poolers. One config flag, an optional direct block, and the framework handles everything the pooler requires. Emulated prepares, boolean binding, routing migrations around the pooler. All of it.

This post covers what the feature does, why the problem existed in the first place, the exact setup for Supabase, Neon, and self-hosted PgBouncer, and which of your old hacks you can now delete.

Why Postgres Connections Are Expensive

If you come from MySQL (like most Laravel developers), this problem probably never bit you. MySQL handles connections with lightweight threads. Postgres forks an entire OS process per connection, and each one eats roughly 5-10MB of RAM on the server. The default max_connections on most Postgres setups sits around 100.

Now do the math for a typical Laravel deployment. PHP-FPM opens a fresh database connection for every request. A moderately busy app with 50 concurrent requests is already holding 50 Postgres processes. Add a queue worker or three, a scheduler, and a second app server, and you're staring at FATAL: too many connections in your logs.

Octane makes this worse, not better. Persistent workers hold their database connection for their entire lifetime. 32 Swoole workers means 32 permanent Postgres processes, most of them idle at any given moment. There's a years-old GitHub discussion of Octane users hitting exactly this wall and hand-rolling PgBouncer setups to survive it.

The fix isn't more connections. It's a pooler.

What a Transaction Pooler Actually Does

A pooler like PgBouncer is a lightweight middleman between your app and Postgres. Your app opens hundreds of cheap connections to the pooler. The pooler multiplexes them over a small set of real Postgres connections, maybe 20.

In transaction mode (the mode that matters here), a real connection is borrowed only for the duration of a single transaction. The moment your transaction commits, that connection goes straight back into the pool for the next request. This is how Supabase's Supavisor serves thousands of clients, how Neon's pooler endpoints work, and how AWS RDS Proxy keeps Lambda functions from melting a small RDS instance.

Transaction mode has one big catch: it breaks server-side prepared statements. Your next query might execute on a different real connection, one that never saw the PREPARE. The same goes for session-level features like SET commands and LISTEN/NOTIFY. That catch is the entire reason Laravel needed framework support.

The Old Pain: What We All Had to Do Before 13.17

Before this release, running Laravel through a transaction pooler meant assembling your own solution from three parts.

First, you disabled server-side prepares by adding PDO::ATTR_EMULATE_PREPARES => true to your connection's options array. That made queries pooler-safe.

But it introduced a second bug: with emulated prepares, Laravel sends PHP booleans to Postgres as 1 and 0 instead of 'true' and 'false', and Postgres rejects them. Entire community packages exist purely to patch this. Their whole job is a custom PostgresConnection class that reformats boolean bindings. If you have one of those in your composer.json, you already know.

Third, migrations and DDL can't run through a transaction pooler at all. So you kept a second connection config pointing at the real database host and remembered to pass --database=pgsql_direct to every migrate call. Every deployment script grew a little ritual around it. Forget once and your migration hangs or fails in a way that takes twenty minutes to diagnose.

None of this was hard, exactly. It was just fragile, undocumented tribal knowledge that every team rediscovered the painful way.

What Laravel 13.17 Ships

PR #60425 (merged June 21, shipped in v13.17.0) moves all of that into the framework. Yes, the same release that gave us route metadata. 13.17 was a good week. Interesting detail: Laravel Cloud has had internal pooled-connection handling since 2025, but it was private plumbing. This PR is the first time it's a public, documented API that any Laravel app can use.

Here's the whole configuration:

'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE'),
    'username' => env('DB_USERNAME'),
    'password' => env('DB_PASSWORD'),
    // ...
    'pooled' => env('DB_POOLED', false),
    'direct' => array_filter([
        'host' => env('DB_DIRECT_HOST'),
        'port' => env('DB_DIRECT_PORT'),
        'username' => env('DB_DIRECT_USERNAME'),
        'password' => env('DB_DIRECT_PASSWORD'),
        'sslmode' => env('DB_DIRECT_SSLMODE'),
    ]),
],

The main connection points at your pooler. The direct block points at the real database. With pooled => true, the framework does four things automatically:

Emulated prepares turn on for the pooled connection. Direct connections keep native prepares. You never touch PDO::ATTR_EMULATE_PREPARES yourself again.

Boolean bindings get fixed. Under emulated prepares, Postgres now receives 'true' and 'false' strings instead of integer literals. Delete the community patch package.

Schema operations route around the pooler. Migrations, schema:dump, schema load, db:wipe, db:show, and db:table all use the direct connection without you passing any flags. Your deployment script gets simpler, not more complicated. The full command list lives in the Laravel Artisan Commands reference if you want to check what else touches the schema.

php artisan db defaults to direct. When pooled mode is on and a direct endpoint exists, the interactive database CLI connects directly, which is what you want for poking at the schema. Pass --pooled if you specifically want to inspect behavior through the pooler.

And when your own application code needs the real connection (say, a LISTEN/NOTIFY listener or a long-running cursor), append the ::direct suffix:

DB::connection('pgsql::direct')->statement('LISTEN order_events');

Backward compatibility is clean. Without pooled => true, nothing changes. Existing ::read and ::write suffixes keep their meaning. Adding a direct block alone doesn't reroute anything.

Setting It Up With Real Providers

The config shape is identical everywhere. The only thing that changes is where the pooled and direct hosts come from.

Supabase

Supabase gives you two connection paths. The direct connection runs on port 5432 at your project's database host. The transaction pooler (Supavisor) runs on port 6543 at a regional pooler host. Both are on your project's Connect page.

DB_HOST=aws-0-eu-central-1.pooler.supabase.com
DB_PORT=6543
DB_POOLED=true
DB_DIRECT_HOST=db.yourproject.supabase.co
DB_DIRECT_PORT=5432

Your app traffic flows through Supavisor. Your migrations hit the database directly. No custom connection classes, no session-mode compromises.

Neon

Neon exposes the pooler through a hostname suffix: take your endpoint host and add -pooler to it. Same credentials for both.

DB_HOST=ep-cool-name-123456-pooler.eu-central-1.aws.neon.tech
DB_POOLED=true
DB_DIRECT_HOST=ep-cool-name-123456.eu-central-1.aws.neon.tech

If you're on Neon specifically for the scale-to-zero pricing, this pairing matters more than it looks. Pooled connections are what let a tiny compute instance handle bursty traffic without connection churn waking it into a bigger bill.

Self-Hosted PgBouncer

Run PgBouncer with pool_mode = transaction in pgbouncer.ini, point DB_HOST at the PgBouncer port (usually 6432), and point the direct block at Postgres itself on 5432. That's it. All the ignore_startup_parameters and prepared-statement tuning advice you'll find in old tutorials was written for the pre-13.17 world. The framework handles the client side now.

One honest note for Octane users: a pooler doesn't reduce how many connections your workers open. It makes those connections cheap. 32 workers still hold 32 client connections, but they multiplex over a fraction of the real Postgres processes, which is the resource that actually runs out.

How to Verify It's Actually Working

Don't trust the config, check the behavior. Three quick tests after enabling pooled:

First, confirm your app traffic goes through the pooler. Run a request, then check active server connections from a direct session:

SELECT count(*) FROM pg_stat_activity WHERE datname = 'your_database';

Under load, that number should stay small and stable (your pool size) while your app happily serves far more concurrent requests. If it climbs with concurrency, you're not actually connecting to the pooler endpoint.

Second, confirm schema routing. Run php artisan db:show. It should report the direct host, not the pooler host. Then run a throwaway migration on staging and watch it complete without hanging. That's the automatic routing doing its job.

Third, if you had the boolean problem before, hit a code path that writes a boolean column. On 13.17 with pooled => true it just works. No exception about invalid input syntax for type boolean, no patch package in sight.

Should You Turn This On?

If you're on Supabase, Neon, RDS Proxy, or any managed Postgres with a pooler endpoint: yes, and this feature removes the last good excuse not to. The old objection was that pooler setups in Laravel were fragile hand-rolled things. That objection died in 13.17.

If you're self-hosting Postgres for a small app with steady traffic, you don't need a pooler yet. A single server with PHP-FPM and modest concurrency lives comfortably inside default connection limits. Add PgBouncer when you see connection pressure, not before. Database indexing will buy you more performance per hour invested until then.

The setup where I'd call it non-negotiable: Octane on Postgres, or anything serverless. Persistent workers and scale-to-zero databases are both connection-hungry patterns, and transaction pooling is the standard answer in every ecosystem, ours included.

One thing to check before enabling it on an existing app: emulated prepares change how query plans are cached server-side, and code that relied on session state between queries (temporary tables, SET commands, advisory locks held across requests) will behave differently through a pooler. That's pooler physics, not a Laravel limitation. Audit for those patterns first. Multi-tenant apps that switch databases per tenant should test carefully too, since tenant connection strategies often assume dedicated connections.

FAQ

Which Laravel version do I need for native pooler support?

Laravel 13.17 or newer. The feature landed via PR #60425 and shipped in v13.17.0 in late June 2026. If you're still on Laravel 12, the upgrade to 13 is worth it for this alone if you run Postgres in production.

Does this work with MySQL or MariaDB?

No. The pooled option is specific to the PostgreSQL driver, because the problem it solves (process-per-connection cost plus prepared statements breaking under transaction pooling) is specific to Postgres. MySQL's threaded connection model doesn't need this.

Do I still need packages that patch PgBouncer boolean bindings?

Not on 13.17+. Correct boolean binding under emulated prepares is now framework behavior. Remove the package, remove any custom PostgresConnection class you copied from a gist, and remove PDO::ATTR_EMULATE_PREPARES from your connection options. The framework sets it for pooled connections automatically.

What happens to migrations if I don't configure a direct block?

Then there's nothing to route to, and schema operations go through your main connection like before. If that connection is a transaction pooler, DDL can fail or hang, exactly as it always did. The direct block is what makes the automatic routing possible, so treat it as required whenever pooled is true.

Does pooling change anything for read/write connection splits?

No. Explicit ::read and ::write suffixes and the --read/--write CLI flags keep working exactly as before and aren't rerouted to the direct connection. The ::direct suffix is a separate, additional routing option.

Wrapping Up

This is one of those features where the code change in your app is five lines of config and the actual win is everything you get to delete: the options array hack, the patch package, the second migration config, the deploy-script flags, and the tribal knowledge explaining why they all exist. Laravel apps on Supabase and Neon just got noticeably simpler to run, and Octane on Postgres finally has a first-party answer to connection exhaustion.

Filament Billing: The Missing Stripe Admin Layer for Your Panel

Hafiz — Mon, 20 Jul 2026 06:02:55 +0000

You wired up Laravel Cashier, connected Stripe, and your app takes payments. Subscriptions get created, webhooks fire, the subscriptions table fills up. Everything works.

Then a customer emails asking to cancel. Or you want to know what your MRR actually is this month. Or someone's payment failed and you need to see who's past due.

Where do you go? Not your admin panel. Cashier doesn't put anything there. You open the Stripe dashboard, or you write a tinker one-liner, or you build a one-off resource every single time. The billing runs fine, but managing it lives outside the tool you built everything else in.

That gap is the whole reason I built Filament Billing. It's a commercial plugin that adds the operator side of billing to your Filament panel: plans, subscriptions, and an MRR widget, all reading from the Cashier tables you already have.

What Cashier gives you, and what it doesn't

Cashier is really good at what it does. It handles the Stripe API calls, the subscription lifecycle, the webhook parsing, the proration math. If you've set up billing with it before (and if you haven't, my Stripe integration guide walks through the whole thing), you know it takes care of the hard parts.

But Cashier is a library, not an interface. It writes stripe_status to your database when a webhook arrives. It does not give you a screen to see that status. It cancels a subscription when you call ->cancel() in code. It does not give your support person a button to do it.

So most teams end up in one of three places. They pop open the Stripe dashboard for everything, which means context-switching out of their own app and giving more people Stripe access than they'd like. They write throwaway tinker commands, which works until you need it at 11pm and can't remember the syntax. Or they build custom Filament resources by hand, which is fine the first time and annoying the fifth.

I've done all three. The third one is what this plugin is, except built once, properly, instead of half-built on every new project.

What Filament Billing actually adds

Three things, all operator-facing.

A Plans resource where you define your billing plans inside the panel. Name, price, currency, the policy behind it. This is your reference layer for what you sell.

A Subscriptions resource that reads your Cashier subscription tables and shows them as a proper Filament list. Each row has the actions you'd expect: cancel at period end, cancel now, resume, swap. No tinker, no Stripe dashboard. Your support person can handle a cancellation without touching code or getting a Stripe login.

An MRR widget for your dashboard. It shows monthly recurring revenue, active subscriber count, and how many people are in trial. It derives the number from the plans it sums, so the currency matches your data instead of a hardcoded symbol. If you've read my admin dashboards guide, this is the metrics-at-a-glance idea applied to billing.

There's also Stripe webhook status sync that keeps subscription statuses current as Stripe events arrive. That part builds on Cashier's own webhook handling, so it works as long as you've got Stripe webhooks wired to your app the normal way.

Who this is for, and who it isn't

I'd rather you know before you buy than ask for a refund after, so here's the honest scope.

This is an operator-side tool. It's for you and your team to manage billing from the admin panel. It is not a customer-facing checkout. Your customers still create subscriptions the way they already do through Cashier. Filament Billing gives you the layer to manage what those flows produce, not a replacement for them.

It's Stripe only, through Cashier. If you're on Paddle, this isn't for you yet.

You define your plans in the panel. It doesn't auto-sync from Stripe on install. You enter what you sell once, and manage from there. (Pulling plans straight from the Stripe API is the feature I'm most likely to add next, but I'd rather ship the honest version now than promise sync that isn't there.)

And it needs Filament v5 and Laravel 11 or 12, with Cashier for Stripe. Filament v5 shipped mainly to support Livewire v4, with no functional changes from v4, so if you're on a recent v4 app the upgrade is quick. If you want to know exactly what changed, I covered that in my Filament v5 breakdown.

If you're building a Laravel SaaS on Filament and you've already got Cashier taking payments, you're the exact person I built this for. If you're still deciding between billing providers, my Cashier Stripe vs Paddle cost comparison is worth a read first, because this plugin commits you to the Stripe side.

Why I shipped it narrow

I've made the mistake before of building a big, clever thing nobody used. So this one is deliberately small. Operator-side only. Stripe only. No customer checkout, no dunning flows, no churn analytics, no Paddle. Just the three pieces that solve the actual daily pain: seeing subscriptions, acting on them, and knowing your MRR.

That narrowness is a feature. It means the plugin does what it says, installs cleanly, and doesn't drag half-finished functionality into your app. If it turns out people want plan-sync or Paddle or a customer portal, those come later, driven by what buyers actually ask for, not by what I imagined in advance. This is the same ship-narrow-to-validate approach I wrote about in my Building a SaaS with Laravel and Filament guide, where I built this billing layer by hand the first time. I've since packaged that admin side into this plugin so you don't have to rebuild it.

Pricing and how to get it

Two one-time tiers: €69 for a single project, €149 for unlimited projects. No subscription, no recurring fee for the plugin itself. You buy it, you get the private Composer repository access, you install it with your license key. You can grab it on Anystack here.

Installation is the standard Anystack flow: configure the repository, add your license credentials, composer require hafizdev/filament-billing, then run the install command. It reads your existing Cashier setup and adds the resources and widget to your panel.

FAQ

Does this replace Laravel Cashier?

No. It sits on top of Cashier and reads its tables. You still need Cashier installed and configured for Stripe. Think of this as the admin interface Cashier never shipped.

Can my customers use it to subscribe or manage their own plans?

Not in this version. It's operator-side only. Your customers create subscriptions through your existing Cashier flows; this is for you and your team to manage them from the panel.

Does it work with Paddle?

No, Stripe only for now. Paddle support depends on demand, so if that's a blocker for you, let me know.

Do I need to be on Filament v5?

Yes, v5 with Laravel 11 or 12. Since v5 exists mainly for Livewire v4 support with no functional changes from v4, upgrading a recent v4 app is quick.

Will it pull my plans from Stripe automatically?

Not yet. You define your plans in the panel once. Automatic sync from the Stripe API is the most likely next addition.

Get it or ask me

If you're running Cashier on a Filament panel and you're tired of opening Stripe to cancel a subscription, this is the layer that fixes it. It's live now on Anystack.

Building something with Filament and Stripe and want to talk through whether this fits, or what's missing for your case? Get in touch. I read every message, and buyer questions are what shape where this goes next.

What's New in Laravel 13.15: Typed Translations and More

Hafiz — Wed, 15 Jul 2026 10:38:15 +0000

Most point releases are safe to skim. Laravel 13.15 has one change that's a reason to update today, not eventually, so it's worth two minutes even if you skip the rest.

That change is a security fix for the date_equals validation rule, where an invalid date could slip past validation entirely under the right conditions. If you validate dates anywhere near authentication, scheduling, or access windows, read that section. The other three headline changes (typed translation accessors, JSON Schema unions, and a dedicated Cloud queue driver) are quality-of-life improvements you'll appreciate but won't lose sleep over. Here's what each one actually does.

Quick note on timing: Laravel ships minor releases weekly, so by the time you read this, 13.16 through 13.19 are already out too (13.19 added HTTP query method support). None of that changes the 13.15 features below, and since these are all backward-compatible minor releases, a composer update gets you everything at once.

The Security Fix You Should Actually Care About

Start here because it's the one with teeth.

The date_equals validation rule was using loose comparison under the hood. That sounds harmless until you trace what PHP does with a bad date string. An invalid date parses to null. And in PHP, null == 0 evaluates to true. So if your reference date parsed to something falsy, like the Unix epoch 1970-01-01 00:00:00, an invalid date string could satisfy date_equals and pass validation.

Picture a rule like this guarding a form:

$request->validate([
    'event_date' => 'required|date_equals:'.$referenceDate,
]);

If $referenceDate resolves to a falsy timestamp and an attacker submits garbage that parses to null, the loose comparison waves it through. That's a validation bypass, and validation bypasses are exactly the kind of quiet bug that doesn't show up until someone goes looking for it.

The fix uses strict comparison for the equality check while keeping loose comparison for legitimate DateTime objects, so real dates still compare the way you expect. There's nothing to change in your code. You update the framework and the hole closes. That's the whole reason this release jumps the queue.

The same release also tightened route unserialization, restricting which classes the router will accept when unserializing during route caching and resolution. It's a smaller surface than the date bug, but it shrinks the room for object-injection tricks during route:cache. Another reason the update is worth doing sooner rather than later.

Typed Translation Accessors

Now the headline feature, and it's one that anyone running strict static analysis will like.

Laravel's translation helpers have always returned broad types. __() returns array|string|null, and trans() returns Translator|array|string. That's fine in a Blade template where you're just echoing a string. It's friction everywhere else, because a method that's typed to return string can't just return __('some.key') without PHPStan or Psalm complaining that it might get an array or null.

13.15 adds two typed accessors on the Translator that return a concrete type:

public function label(): string
{
    return trans()->string($this->name);
}

public function options(): array
{
    return trans()->array($this->options_key);
}

trans()->string() guarantees a string back. trans()->array() guarantees an array. The pattern mirrors the typed accessors Laravel already ships on config() and request(), so if you've used config()->string('app.name'), this will feel familiar immediately.

It's a small thing. But if your codebase runs Larastan at a high level (and the starter kits now ship at level 7), these two methods delete a category of annoying casts and assert() calls you were writing just to satisfy the analyzer. Small friction, removed everywhere at once.

JSON Schema Unions for AI Structured Output

This one's narrow but it matters if you're building with the Laravel AI SDK.

The JsonSchema component picked up two related capabilities. First, a fromArray() deserializer that turns a raw JSON Schema array back into Type objects, which is the inverse of the serialization that was already there. Second, and more useful day to day, the schema builder now supports multi-type unions through anyOf.

Why does anyOf matter? Structured output is where you force a model to return JSON matching a schema you define. Sometimes a field really can be one of several shapes. A support ticket's resolution might be a string when it's a simple note, or an object when it's a structured escalation. Before anyOf, you couldn't express "this field is one of these distinct schemas" cleanly. Now you can, and since both OpenAI and Gemini support anyOf in their structured output APIs, it passes straight through to the provider.

If you're already returning typed responses from agents, this widens what you can model without dropping back to a loose string field and parsing it yourself. If you haven't touched the AI SDK yet, this is a detail to file away rather than act on.

A Dedicated Cloud Queue Driver

If you deploy on Laravel Cloud and use its managed queues, several changes in 13.15 add up to a proper first-party queue driver rather than a generic one bent to fit.

The practical differences: managed queues now boot before service providers, so the queue connection is ready earlier in the lifecycle. A missing configured queue throws a clear ManagedQueueNotFoundException instead of failing in some vaguer way. FIFO queue name normalization was corrected. And the request ID header was renamed from X-Request-ID to Cloud-Request-ID, now surfaced in your logs, which is the kind of thing you'll be grateful for the first time you're tracing a request through a queued job in production.

There's a related nicety too: Queue::route() now accepts enum cases for both the queue name and the connection. If you've moved your queue names into a backed enum to stop typing magic strings, you can pass the enum directly instead of calling ->value everywhere.

If you're not on Laravel Cloud, none of this affects you. If you are, it's a quiet reliability upgrade to the part of your stack you least want surprises in. The broader queue setup worth knowing is in the queue jobs guide, and the managed queues vs Horizon comparison covers the trade-off if you're deciding between them.

The Smaller Fixes Worth Knowing

A few more changes that won't headline a release but will save someone an afternoon:

The Number helper got three edge cases fixed. Number::fileSize() now handles negative byte values instead of producing nonsense, Number::trim() stops returning null for INF and NAN, and Number::pairs() handles negative step values while throwing a clear exception on a zero step so you don't get an infinite loop. If you've ever fed user-derived numbers into these, the hardening is welcome.

Two infinite-recursion bugs got squashed: one when a model scope is defined using a private attribute, and one when a middleware group references itself. Both are the kind of mistake that's easy to make in a large app and miserable to debug, so having the framework fail sanely instead of hanging is a real improvement.

And a small operational win: queue:failed now shows the real class name of failed jobs instead of an unhelpful placeholder, which makes triaging a failed queue that much faster. The full list of queue and Artisan commands is in the Laravel Artisan Commands reference if you want to see what else is available there.

Should You Update?

Yes, and specifically for the date_equals fix if you validate dates anywhere sensitive. That's not a "nice to have when you get around to it" change, it's a closed security hole, and the update is a backward-compatible composer update with no code changes required.

The rest is upside you collect for free on the way. Typed translation accessors clean up strict-typed code, anyOf widens what you can model with AI structured output, and the Cloud queue driver makes managed queues more predictable. None of it breaks anything, because these are minor releases and Laravel doesn't ship breaking changes in those.

If you're several minor versions behind, the update also pulls in everything from 13.16 through the latest, so it's worth checking the changelog for anything relevant to your app beyond what's here. If you're on an older major version entirely, the Laravel 12 to 13 upgrade guide covers that jump first.

FAQ

Do I need to change any code to get the date_equals security fix?

No. The fix is entirely inside the framework's validation logic. Running composer update to pull in Laravel 13.15 or later closes the bypass, and legitimate DateTime comparisons keep working exactly as before.

What's the difference between trans()->string() and __()?

__() returns array|string|null, which forces casts or assertions in strictly-typed code. trans()->string() guarantees a string return type, and trans()->array() guarantees an array. They're for typed method bodies and static analysis, not for replacing __() in Blade, where the broad type is fine.

Does the JSON Schema anyOf support work with all AI providers?

The anyOf support is in Laravel's schema builder, and both OpenAI and Gemini accept anyOf in their structured output APIs, so it passes through to those providers. Support for other providers depends on whether their structured output API accepts unions.

Is the Cloud queue driver useful if I don't use Laravel Cloud?

No. These changes specifically target Laravel Cloud's managed queues. If you run your own queue infrastructure with Redis, SQS, or a database driver, they don't apply, though Queue::route() accepting enums is a general improvement everyone gets.

Is Laravel 13.15 the latest version?

Probably not by the time you read this. Laravel ships minor releases roughly weekly, so 13.16 and beyond are likely already out. Because minor releases are backward-compatible, updating gets you 13.15's features plus everything newer in one step.

Wrapping Up

Laravel 13.15 is mostly a quiet release, and that's fine. Not every version needs a marquee feature. The typed translation accessors are a clean quality-of-life win, the anyOf support quietly expands what the AI SDK can do, and the Cloud queue driver makes managed queues more predictable.

But the date_equals fix is the one that changes your calendar. Update for that, collect the rest as a bonus, and move on.

Laravel Pennant: The Complete Feature Flags Guide

Hafiz — Mon, 13 Jul 2026 07:31:46 +0000

Most Laravel apps already have feature flags. They just live in the worst possible place: a config/features.php file full of booleans, an .env variable read in three different controllers, or an if ($user->id === 1) that someone swore they'd remove before merging. It works until it doesn't, and then you're deploying code to change who sees a feature, which is the exact thing feature flags are supposed to prevent.

Laravel Pennant is the first-party fix. It's small, it has no external service to pay for, and once the mental model clicks it replaces every one of those hacks with one consistent API. But that mental model has one sharp edge that trips up almost everyone the first time, and most tutorials skip right past it. So this guide covers the whole thing: defining flags, scoping them to users or teams, percentage rollouts, rich values, testing, and the sticky-storage behavior that will silently break your first rollout if you don't know it's there.

Installing Pennant

Nothing surprising here:

composer require laravel/pennant

php artisan vendor:publish --provider="Laravel\Pennant\PennantServiceProvider"

php artisan migrate

The publish step drops a config/pennant.php file and a migration that creates a features table. That table is where Pennant's default driver stores resolved flag values, and understanding what "resolved" means there is the key to the whole package. More on that shortly.

Pennant ships two storage drivers. The database driver (the default) persists resolved values in that features table, so a value survives across requests, deployments, and server restarts. The array driver keeps values in memory for a single request and forgets them after, which makes it the right choice for tests. You pick the default in config/pennant.php.

Defining Your First Flag

Flags are defined with the Feature::define method, usually in a service provider's boot method. You give the flag a name and a closure that resolves its value. The closure receives the "scope", which by default is the currently authenticated user.

// app/Providers/AppServiceProvider.php
use App\Models\User;
use Laravel\Pennant\Feature;

public function boot(): void
{
    Feature::define('new-checkout', fn (User $user) =>
        $user->created_at->isAfter(now()->subDays(30))
    );
}

This flag is active for users who registered in the last 30 days. Everyone else gets the old checkout. Checking it anywhere in your app is one call:

use Laravel\Pennant\Feature;

if (Feature::active('new-checkout')) {
    return view('checkout.new');
}

return view('checkout.legacy');

Feature::active() checks against the current user. To check a specific scope, use for():

if (Feature::for($user)->active('new-checkout')) {
    // ...
}

In Blade, there's a directive that reads cleaner than an inline check:

@feature('new-checkout')
    <x-checkout.new />
@else
    <x-checkout.legacy />
@endfeature

That's the entire happy path. If Pennant were only this, it'd be a nicer syntax for booleans. What makes it worth adopting is scope and persistence, which is also where the trap lives.

The One Thing That Trips Everyone Up

Here's the behavior that surprises people, and it's worth stopping on because it will bite you otherwise.

With the database driver, a flag's value is resolved once per scope and then stored. The closure runs the first time you check the flag for a given user. After that, Pennant reads the saved value from the features table and never runs your closure again for that user.

Read that again, because the consequence is not obvious. If you define a flag as a 10% rollout, check it for your users, and then later change the closure to 25%, nothing happens. The users who were already resolved keep whatever value they got the first time. Your edit to the closure is ignored for everyone who's already been evaluated.

This is a feature, not a bug. It's what gives you a consistent user experience: a user who got the new checkout doesn't randomly lose it on their next request because a lottery re-rolled. But if you don't know it's happening, your first percentage rollout will look completely broken. You'll bump the number, refresh, and see no change, and you'll think Pennant is ignoring you.

The fix is to purge the stored values so they re-resolve against the new closure:

php artisan pennant:purge new-checkout

Now the next check for each user re-runs the closure at the new percentage. Treat this like a deploy step: whenever you change a flag's resolution logic and want existing users re-evaluated, purge it. I script it into the deploy alongside the migration, the same way you'd run route:cache (the full command reference is in the Laravel Artisan Commands guide).

Percentage Rollouts With Lottery

The most common reason to reach for flags is the gradual rollout: ship to 10% of users, watch your error rates, then widen. Pennant leans on Laravel's Illuminate\Support\Lottery helper for this, and the official Pennant documentation uses the same pattern.

use App\Models\User;
use Illuminate\Support\Lottery;
use Laravel\Pennant\Feature;

Feature::define('new-checkout', fn (User $user) => match (true) {
    $user->isInternalTester() => true,
    default => Lottery::odds(1, 10),
});

Internal testers always get the feature. Everyone else has a 1-in-10 chance, resolved once and then stored. Because the result is sticky, a user who wins the lottery keeps the feature on every subsequent request instead of flickering on and off as the lottery re-rolls. That consistency is the whole point, and it's also why widening to 25% later means editing the odds and running pennant:purge so unresolved and previously-resolved users alike get evaluated against the new number.

This is the exact interaction that surprises people, so it's worth saying once more in context: the closure and the storage work together. The closure decides the value the first time; storage remembers it forever after. Rollout percentage changes are storage operations, not code edits alone.

Scoping Flags to Teams and Accounts

The default scope is the authenticated user, but plenty of rollouts happen per team or per account, not per person. If one member of a company sees the new billing screen and their colleague doesn't, that's a support ticket waiting to happen.

Scope to the team by type-hinting it in the closure and passing it to for():

Feature::define('billing-v2', fn (Team $team) =>
    in_array($team->plan, ['pro', 'enterprise'])
);

if (Feature::for($request->user()->currentTeam)->active('billing-v2')) {
    // ...
}

If you get tired of writing for() everywhere, implement the HasFeatures trait's default-scope method or set a global default scope in your service provider so every check resolves against the team automatically. For a SaaS app, setting the default scope to the current team once is usually cleaner than threading for() through every call site.

The Null Scope Trap in Queues and Commands

This one pairs with the sticky-storage gotcha as the second thing that bites people, and it shows up specifically outside the HTTP request.

Your flag closure type-hints User. That's fine in a controller where someone's logged in. But check the same flag inside a queued job, an Artisan command, or an unauthenticated route, and there's no authenticated user, so the scope is null. When the scope is null and your closure doesn't accept null, Pennant skips the closure entirely and returns false.

So a flag that's active for a user in the browser silently reads as inactive when the same logic runs in a queued job processing that user's data. If your job's behavior depends on the flag, it quietly takes the wrong branch.

Two ways to handle it. Either pass the scope explicitly in contexts that have no authenticated user:

// Inside a job that knows which user it's working on
if (Feature::for($this->user)->active('new-checkout')) {
    // ...
}

Or make the closure null-safe so it fails predictably instead of surprisingly:

Feature::define('new-checkout', fn (User $user = null) =>
    $user?->created_at->isAfter(now()->subDays(30)) ?? false
);

The explicit-scope version is what I reach for, because a flag that depends on a user should always be told which user. Relying on the ambient authenticated user is exactly how the browser-versus-queue mismatch sneaks in.

Rich Values: Flags That Return More Than True or False

Flags don't have to be boolean. A closure can return a string, and Feature::active() treats anything except literal false as active. This turns a flag into a lightweight A/B test:

use Illuminate\Support\Arr;

Feature::define('purchase-button', fn () => Arr::random([
    'blue-sapphire',
    'seafoam-green',
    'tart-orange',
]));

Retrieve the resolved value instead of just checking active state:

$color = Feature::value('purchase-button'); // 'seafoam-green'

Because the value is sticky per scope, each user keeps their assigned variant across requests, which is exactly what you want for a clean A/B test. No separate experiment table, no cookie juggling. And you can pull several at once with Feature::values(['billing-v2', 'purchase-button']) or grab everything defined for the current scope with Feature::all(), which is handy for passing the whole flag set to your frontend in one payload.

One caveat on Feature::all(): class-based features that haven't been checked yet during the request won't appear, because Pennant only knows about them once they're resolved. If you're building a flag dashboard or hydrating an Inertia page with every flag, be aware some may be missing until they're touched.

Pennant and Route Metadata

Last week's post on route metadata gated a whole route group behind a feature flag using one middleware that read a feature key off the route. Pennant is the other half of that pattern, so here's the complete version.

Tag the routes with metadata:

Route::metadata(['feature' => 'billing-v2'])
    ->prefix('billing')
    ->group(function () {
        Route::get('/', [BillingController::class, 'index']);
        Route::resource('invoices', InvoiceController::class);
    });

Then one middleware reads the tag and asks Pennant:

use Laravel\Pennant\Feature;

public function handle(Request $request, Closure $next): Response
{
    $flag = $request->route()->getMetadata('feature');

    if ($flag && ! Feature::active($flag)) {
        abort(404);
    }

    return $next($request);
}

Register it on the web group, and every flagged route is gated with zero per-route boilerplate. Deleting the rollout is deleting one metadata line. This is the payoff of the two features together: route metadata declares which flag guards a route, Pennant decides whether it's on, and the middleware is the five lines that connect them. It's a cleaner separation than scattering Feature::active() checks through your controllers.

Testing Feature Flags

Flags that change behavior need tests for both branches, and Pennant makes forcing a flag's state trivial. In a test, redefine or activate the flag before the assertion:

use Laravel\Pennant\Feature;

it('shows the new checkout when the flag is on', function () {
    Feature::define('new-checkout', fn () => true);

    $this->actingAs($this->user)
        ->get('/checkout')
        ->assertViewIs('checkout.new');
});

it('shows the legacy checkout when the flag is off', function () {
    Feature::define('new-checkout', fn () => false);

    $this->actingAs($this->user)
        ->get('/checkout')
        ->assertViewIs('checkout.legacy');
});

Because your test suite should use the array driver, nothing persists between tests and each one starts clean. Redefining the flag at the top of a test overrides whatever your service provider set, so you control exactly which branch runs. This is also why the sticky-storage behavior never bites you in tests: the array driver forgets everything after each request.

When Pennant Is the Wrong Tool

Honest boundaries, because not every toggle needs a flag package.

If a value never changes per user and never rolls out gradually, it's config, not a feature flag. config('services.stripe.enabled') doesn't belong in Pennant. Pennant earns its place when a toggle varies by scope or rolls out incrementally, not when it's a global on/off switch you set once.

If you need flag changes managed by non-engineers through a dashboard, audit logs, scheduled rollouts, and multi-environment targeting, a hosted service like LaunchDarkly does things Pennant doesn't try to. Pennant is a library, not a product. It has no UI. For a lot of teams that's the point, but if your product managers need to flip flags themselves, Pennant alone won't get you there without building the dashboard yourself.

And if you're reaching for flags to manage long-lived branches, the flag is treating a symptom. Feature flags pair best with trunk-based development and small, self-contained changes, where each push is shippable and the flag just controls visibility. A flag wrapped around a six-month branch is a merge conflict with extra steps.

For the common case, though, incrementally rolling out a feature to real users on your own infrastructure with no monthly bill, Pennant is hard to beat.

FAQ

Does changing a Pennant flag's closure update existing users?

No, and this catches nearly everyone. With the database driver, a flag resolves once per scope and stores the result. Editing the closure doesn't re-evaluate users who were already resolved. Run php artisan pennant:purge {flag} to clear stored values and force re-resolution against the new logic.

Why does my feature flag return false inside a queued job?

Because the scope is null. Jobs, Artisan commands, and unauthenticated routes have no authenticated user, so a closure that type-hints User (without allowing null) gets skipped and Pennant returns false. Pass the scope explicitly with Feature::for($user)->active(...), or make the closure accept a nullable scope.

What's the difference between Pennant's array and database drivers?

The database driver persists resolved values in the features table, so they survive across requests and deployments. That's the production default. The array driver keeps values in memory for one request only, which is what you want in tests so nothing leaks between them.

Can Pennant do percentage-based rollouts?

Yes. Use Illuminate\Support\Lottery inside the closure to activate a flag for a percentage of scopes. Remember that values are sticky once resolved, so raising the percentage later requires a pennant:purge for existing users to be re-evaluated.

Do I need a separate service like LaunchDarkly?

Not for most Laravel apps. Pennant covers scoped flags, rich values, and gradual rollouts natively with no external dependency. Reach for a hosted service when you need a non-engineer-facing dashboard, audit trails, or complex multi-environment targeting that Pennant deliberately leaves out.

Wrapping Up

Pennant is small enough to learn in an afternoon and useful enough to keep forever. The API is the easy part. The two things that actually matter are the ones tutorials skip: values are sticky per scope until you purge them, and a null scope in a job or command silently returns false. Get those two into your muscle memory and everything else is just Feature::active().

Start by replacing your ugliest .env boolean with a real flag. Once the first one's in and you've watched a rollout behave, you'll wonder why the config file ever held that logic.

Laravel Octane in 2026: FrankenPHP vs Swoole vs RoadRunner

Hafiz — Wed, 08 Jul 2026 12:07:04 +0000

In April 2026, a carefully controlled benchmark put all three Laravel Octane servers through a real Laravel workload. RoadRunner more than doubled PHP-FPM's throughput. Swoole, the server with a decade-long reputation as PHP's performance monster, finished dead last. Below plain FPM.

A month later, a hosting company that has migrated dozens of Laravel apps to Octane published their production numbers. Their verdict on Swoole: it's their fastest option for API-heavy workloads, and they deploy it deliberately for exactly those customers.

Both sources are competent. Both published their methodology. Both are right.

That contradiction is the most useful thing you can learn about choosing an Octane server, because it tells you the question "which server is fastest?" has no universal answer. The useful question is which server matches your workload, your deployment model, and your team's appetite for operational complexity. This post covers what Octane actually changes, how the three servers differ architecturally, why the benchmarks disagree, and a decision framework you can apply to your own app. I'll also tell you when the honest answer is to not use Octane at all.

What Octane Actually Changes

A standard Laravel request on PHP-FPM boots the entire framework from zero. Service providers register, config loads, the container wires up, and then your code finally runs. For a typical app that boot costs 10 to 30ms per request, more if you're carrying Filament, Nova, or a heavy stack of packages. Then the request ends and everything is thrown away.

Octane inverts that. The application boots once per worker, stays resident in memory, and each incoming request reuses the already-built framework. The boot tax disappears from every request except the first.

That's the whole trick. Octane doesn't make your database queries faster, doesn't cache your responses, and doesn't parallelize your code (with one Swoole-shaped exception we'll get to). If your endpoint spends 200ms in MySQL, Octane saves you the 20ms boot and leaves the 200ms untouched. This is why I tell people to read their profiler before reading Octane benchmarks: if framework bootstrap isn't a meaningful slice of your response time, start with query optimization instead. It's usually the bigger win and it carries zero migration risk.

Installation is the same regardless of server:

composer require laravel/octane

php artisan octane:install --server=frankenphp
# or --server=swoole, --server=roadrunner

Octane supports four servers: FrankenPHP, Swoole, Open Swoole, and RoadRunner. Open Swoole is a community fork with the same Octane feature set as Swoole, so practically the choice is between three architectures.

Three Servers, Three Architectures

The performance and failure characteristics of each server come directly from how a request physically reaches your PHP code.

FrankenPHP is a Go binary built on the Caddy web server, with the official PHP interpreter embedded directly into the process via cgo. There's no proxy hop and no inter-process communication: Caddy accepts the request and hands it to a PHP thread inside the same process, where your booted Laravel app is waiting. Because Caddy is the web server, you get HTTP/2, HTTP/3, and automatic HTTPS without putting Nginx in front. Octane downloads the FrankenPHP binary for you when you pick it during install.

RoadRunner is also written in Go, but it takes the opposite approach to integration. It runs as a standalone server binary that manages a pool of ordinary PHP processes, forwarding requests to them over a fast RPC protocol. Your PHP workers are regular processes with real isolation: if one worker corrupts its state or dies, RoadRunner respawns it and the others never notice. It's been doing this job since 2018 and has the most mature plugin ecosystem of the three (queues, gRPC, key-value storage).

Swoole is different in kind, and the difference goes deeper than plumbing. It's a C extension installed via PECL that replaces PHP's execution model with an event loop and coroutines, closer to Node.js than to classic PHP. When your code hits blocking I/O, Swoole can suspend that coroutine and run another request on the same worker. That's a capability the other two simply don't have, and it's also why Swoole demands the most from your code.

The architectural differences cascade into everything else, so let's take each server on its own terms.

FrankenPHP: The Deployment Story

FrankenPHP is the youngest of the three, released in late 2023 and hardened through 2024 and 2025. What it changed isn't raw speed. It's how little infrastructure you need.

One binary is your web server, TLS manager, static file server, and PHP runtime. A production Dockerfile is this small:

FROM dunglas/frankenphp

COPY . /app
WORKDIR /app

RUN composer install --no-dev --optimize-autoloader

ENTRYPOINT ["php", "artisan", "octane:frankenphp"]

One container, one port, no Nginx, no supervisor config. If you deploy to Cloud Run, Kubernetes, or any autoscaling container platform, that shape maps perfectly. And on classic VPS setups, HTTPS with automatic certificate renewal comes from Caddy for free. When you need to go beyond the defaults, php artisan octane:start --server=frankenphp --caddyfile=/path/to/Caddyfile gives you full Caddy configuration.

The honest trade-offs: it's the youngest option, and youth shows. One hosting provider that runs it in production reports hitting two memory-leak regressions over 18 months, both fixed promptly upstream, but that's a different stability track record than RoadRunner's. Configuration is Caddyfile syntax rather than the Nginx configs most Laravel developers have committed to muscle memory. And in benchmarks driven by HTTP/1.0 tools, FrankenPHP looks unremarkable, for reasons we'll get to.

Swoole: The Ceiling and the Cliff

Swoole has the highest performance ceiling of the three, and the steepest cliff next to it.

The ceiling comes from coroutines. While FrankenPHP and RoadRunner workers handle one request at a time, Swoole's runtime can juggle many, suspending whichever one is waiting on the database. For endpoints that fan out to multiple upstream services, Octane exposes this directly:

use Laravel\Octane\Facades\Octane;

[$orders, $stats, $flags] = Octane::concurrently([
    fn () => Order::recent()->get(),
    fn () => Cache::get('dashboard:stats'),
    fn () => Feature::all(),
]);

Three operations, dispatched to Swoole's task workers and executed concurrently while your request waits for the results. You size that pool with --task-workers on octane:start. Octane::concurrently(), ticks, intervals, and the Swoole-backed Octane cache and tables are exclusive to Swoole and Open Swoole. Neither FrankenPHP nor RoadRunner can offer them because their workers don't have a coroutine scheduler.

The cliff: Swoole changes PHP's execution semantics, and code written for classic synchronous PHP doesn't always survive the change. Extensions can conflict, some packages misbehave inside coroutines, and Xdebug famously doesn't cooperate, so production profiling means Blackfire or Tideways. It's also an extension you compile via PECL rather than a binary Octane downloads for you, which makes your Docker images and CI more bespoke. The production shops that get the most from Swoole recycle workers aggressively (max_requests around 250 versus 500 on RoadRunner) because memory grows faster.

My blunt read: Swoole is a specialist's tool. If you're not going to use concurrently() or your workloads don't have real I/O concurrency, you're paying Swoole's complexity tax for a capability you never invoke.

RoadRunner: The Boring Choice, Compliment Intended

RoadRunner wins on exactly one axis, and it happens to be the axis that matters most for a lot of teams: predictability.

Its worker isolation model means a leak or crash in one PHP process can't poison its siblings. The Go server respawns dead workers and traffic continues. It has seven-plus years of production history, and its configuration lives in a plain YAML file that does what it says. In the April 2026 benchmark that embarrassed Swoole, RoadRunner delivered 111.6% more throughput than PHP-FPM on the same hardware with a 41% lower p99. Not because it's exotic, but because boot-once plus process isolation is a simple model that performs consistently across workload shapes.

Setup needs two extra packages alongside Octane, and the rr binary is offered for download on first start:

composer require laravel/octane spiral/roadrunner-cli spiral/roadrunner-http

php artisan octane:start --server=roadrunner

What you give up: no HTTP/3 or automatic HTTPS (you'll keep Nginx or Caddy in front), no coroutines, and a plugin ecosystem (gRPC, queues) that most Laravel apps never touch because Laravel's own queue system already covers that ground.

Why the Benchmarks Disagree

Back to the contradiction from the intro, because resolving it is what makes you dangerous in this decision.

The April 2026 benchmark that placed Swoole below PHP-FPM used ab, a load tool that speaks HTTP/1.0 with short-lived connections, against a light-I/O Laravel route. Two things follow. First, Swoole's entire advantage is concurrent I/O scheduling; on a workload with barely any I/O wait, its coroutine scheduler is pure overhead, so it loses. Second, FrankenPHP's HTTP/2 multiplexing never gets exercised over HTTP/1.0, so it benchmarks like plain FPM while its real-world strength stays invisible.

Meanwhile, the production shop reporting Swoole as their fastest option runs it on API workloads full of upstream calls and database fan-out, with concurrently() in active use. That's precisely the workload where coroutines pay. Same server, opposite conclusion, and both measurements are honest.

The lesson generalizes: every Octane benchmark measures its own workload and tooling as much as it measures the server. A hosting provider's before-and-after on a real authenticated endpoint (4 to 5x throughput moving FPM to FrankenPHP with Octane) is more predictive for a typical app than any synthetic table. And your own app benchmarked for an afternoon beats both. So treat published numbers as bounds, not rankings.

The Decision Framework

Here's how I'd actually choose in 2026.

Pick FrankenPHP if you deploy in containers or want the simplest possible stack. Cloud Run, Kubernetes, Docker-based platforms, or a VPS where you'd rather not maintain Nginx. It's also the right default if you're new to Octane: the binary auto-installs, and the single-process model has the fewest moving parts to reason about.

Pick RoadRunner if you're migrating a large existing app and stability is the priority. The process isolation gives you the softest failure modes while you shake out the state bugs every migration surfaces. It's the conservative choice, and for a revenue-carrying monolith, conservative is correct.

Pick Swoole only if you'll use what makes it Swoole. Many concurrent upstream calls per request, real fan-out, a team comfortable auditing packages for coroutine safety. Then the ceiling is real and nothing else reaches it.

Pick none of them if your profiler says boot time isn't your problem. A 300ms endpoint that spends 260ms in queries gets nothing meaningful from Octane. The cheap performance wins come first; Octane is what you reach for after them, when traffic and infrastructure cost make the boot tax worth eliminating. My own apps still run plain FPM on small droplets, and that's deliberate: at their traffic, Octane would add operational surface without moving anything a user can feel. The infrastructure cost math only tips toward Octane when you're scaling servers to handle load that's mostly boot overhead.

The Gotchas That Apply to All Three

Whichever server you pick, the migration risk is identical, because it comes from Octane's model rather than the server underneath.

Your app now lives in memory across requests. Anything static, any singleton, any memoized value persists into the next request. The classic bug is a package caching the authenticated user in a singleton, so request N+1 sees request N's user. Audit your singletons, use Octane's flush hooks for anything request-scoped, and test with two different logged-in users hitting the same worker.

Memory grows. Every long-running PHP process leaks a little, so set --max-requests and let workers recycle themselves. Deploys change too: php artisan octane:reload swaps workers with zero downtime, and it belongs in your deploy script (the full command list is in the Laravel Artisan Commands reference). And remember each worker handles one request at a time (Swoole's coroutines aside), so a slow request blocks a worker slot. Anything slow belongs on a queue, same as always.

FAQ

Is Laravel Octane faster than PHP-FPM for every application?

No. Octane eliminates the framework boot cost, roughly 10 to 30ms per request on a typical app. If your response time is dominated by database queries or external APIs, Octane changes almost nothing. Profile first: it pays off when boot time is a meaningful fraction of your responses and traffic is high enough that the saved milliseconds compound into fewer servers.

Which Octane server is easiest to set up?

FrankenPHP. Octane downloads the binary for you during octane:install, and because it bundles Caddy you don't need a separate web server for HTTPS, HTTP/2, or HTTP/3. RoadRunner is close behind (two extra Composer packages, auto-downloaded binary). Swoole requires compiling a PECL extension, which makes it the most involved.

Do I need to rewrite my code for Octane?

Rewrite, no. Audit, yes. Static properties, singletons, and anything memoized will persist between requests, which is the source of nearly all Octane bugs. Most well-structured apps need a handful of fixes, not an architectural change. Third-party packages are the bigger unknown, so test the critical paths under a single worker with --max-requests=1 to surface state leaks quickly.

What about Open Swoole?

Fully supported by Octane and functionally equivalent for Octane's purposes: you get the same concurrent tasks, ticks, and intervals as Swoole. It's a community fork, so the choice between them usually comes down to which extension your platform and PHP version support more cleanly.

Does Octane work with Laravel 13?

Yes. Octane is a first-party package and the Laravel 13 documentation covers all four servers. Install with composer require laravel/octane and pick your server during octane:install.

Wrapping Up

The 2026 Octane question isn't "which server wins the benchmark". It's a matching problem. FrankenPHP matches container-native deployments and small teams that want one binary doing everything. RoadRunner matches big migrations where boring is a feature. Swoole matches I/O-heavy APIs run by teams who'll actually use its concurrency. And plain PHP-FPM still matches every app whose profiler says boot time isn't the bottleneck, which is more apps than the benchmark posts admit.

Pick by workload, verify with an afternoon of load testing on your own endpoints, and be suspicious of any comparison (including this one) that hands you a single winner.

Planning an Octane migration for a production Laravel app and want a second pair of eyes on the state-leak audit and server choice? Let's talk.

Laravel Route Metadata: 5 Real Problems It Finally Solves

Hafiz — Mon, 06 Jul 2026 07:08:27 +0000

When route metadata got merged into Laravel 13.17, the first comment on the pull request was a long-time framework contributor asking what it's actually for. His follow-up was blunter: "IMO none of this behavior belongs on the Route, but oh well."

I get the skepticism. On paper, "attach arbitrary data to routes" sounds like a solution looking for a problem. But here's the thing: Laravel developers have been attaching arbitrary data to routes for years. We just did it badly. Config files keyed by route name. Abused ->defaults() calls that leak into controller parameters. Naming conventions like admin.reports.legacy.v1 that encode three different facts into a string and pray nobody renames the route. A GitHub discussion from 2022 asked for exactly this feature and got zero answers.

So the question isn't whether attaching data to routes is a good idea. You're already doing it. The question is whether you keep doing it through hacks or use the supported, cache-safe API that ships in every Laravel app from 13.17 onwards.

This post covers what shipped, the merge rules that make groups powerful, and five concrete problems where route metadata replaces something uglier. Working code for each.

What Laravel 13.17 Actually Shipped

Three methods. That's the whole API.

metadata() attaches an array of data to a route or a group:

use App\Http\Controllers\UserController;
use Illuminate\Support\Facades\Route;

Route::get('/users', [UserController::class, 'index'])
    ->metadata(['head' => ['title' => 'Users']]);

getMetadata() reads it back from the resolved route, with dot notation and an optional default:

$request->route()->getMetadata('head.title');           // 'Users'
$request->route()->getMetadata('head.author', 'Hafiz'); // 'Hafiz' (fallback)
$request->route()->getMetadata();                       // the full array

And setMetadata() replaces everything instead of merging, for the rare case where you want a route to opt out of whatever its group defined.

The part that makes this more than a glorified array property: metadata is stored on the route action under a dedicated metadata key. That means it flows through the existing route group logic and gets serialized by route:cache. Your metadata survives production route caching with zero extra work. Anything you'd find with php artisan route:list still resolves the same way (the full command reference is in the Laravel Artisan Commands guide if you need it).

Resources and singletons work too:

Route::resource('users', UserController::class)
    ->metadata(['head' => ['title' => 'Users']]);

Every route the resource generates carries the metadata. Before 13.17 there was no clean way to do this, because resource routes are registered in a pending state and you couldn't hook data onto them mid-registration.

The merge rules worth memorizing

Group metadata cascades down to every route inside the group. The merge follows two rules:

Associative arrays merge recursively. Nested groups layer values on top of each other.
Lists and scalar values replace what they inherit.

Here's both rules in one example:

Route::metadata(['head' => ['robots' => ['noindex'], 'author' => 'Hafiz']])
    ->group(function () {
        Route::get('/users', [UserController::class, 'index'])
            ->metadata(['head' => ['title' => 'Users']]);
    });

// $request->route()->getMetadata('head') returns:
// [
//     'robots' => ['noindex'],  // inherited from the group
//     'author' => 'Hafiz',      // inherited from the group
//     'title'  => 'Users',      // added by the route
// ]

The route added title without losing robots or author. But if the route had defined its own robots list, it would have replaced the group's list entirely, not merged with it. Lists replace. Associative keys merge. Once that clicks, the whole feature is predictable.

How We Hacked This Before

Every workaround for this problem had a real cost. Quick tour, because recognizing your own code in this list is the fastest way to see why the feature matters.

Custom keys in the action array. You could always smuggle extra keys into the route action and read them back with getAction(). It worked for single routes. It fell apart for groups, resources, and singletons, because there was no supported way to carry the data through the route-building pipeline. That's the exact gap the PR closes.

Abusing ->defaults(). Route defaults exist to provide default values for route parameters. Stuffing page titles or permission strings in there technically works, until a controller method with a matching parameter name silently receives your metadata as an argument. I've debugged that one. Not fun.

Config maps keyed by route name. A config/seo.php file with a hundred route names mapped to titles and descriptions. Now every route rename is a two-file change, nothing enforces the mapping stays in sync, and the data lives nowhere near the route it describes.

Encoding facts into route names. Names like api.v1.legacy.reports.index where "v1" and "legacy" are load-bearing. String parsing as architecture.

Route metadata replaces all four with data that lives on the route definition itself, cascades through groups, and survives caching. Now the five problems.

Problem 1: Per-Route SEO Tags Without a Config Map

The classic case, and the one the PR uses in its own examples. Marketing pages need distinct titles, meta descriptions, and robots directives. Most Laravel apps solve this with view-level variables passed from every controller method, which means every controller method has to remember to pass them.

With metadata, the route definition carries the SEO data and one middleware shares it with every view:

// routes/web.php
Route::metadata(['seo' => ['robots' => 'index,follow']])
    ->group(function () {
        Route::view('/pricing', 'pages.pricing')
            ->metadata(['seo' => ['title' => 'Pricing', 'description' => 'Plans from 9 euro a month.']]);

        Route::view('/about', 'pages.about')
            ->metadata(['seo' => ['title' => 'About us']]);
    });

// app/Http/Middleware/ShareSeoMetadata.php
public function handle(Request $request, Closure $next): Response
{
    View::share('seo', $request->route()->getMetadata('seo', []));

    return $next($request);
}

Your layout reads $seo['title'] with a sensible fallback and you're done. Controllers stop caring about SEO entirely. The /about page didn't define a description, so getMetadata() just won't return one, and your Blade fallback handles it.

The win over a config map: renaming a route can't break anything, because nothing is keyed by route name anymore.

Problem 2: Feature Flag Gating for Whole Route Groups

You're rolling out a new billing section behind a flag. The old approach is a middleware that takes the flag name as a parameter, ->middleware('feature:new-billing'), repeated on every route or group. Workable, but middleware parameters are strings, they don't cascade with any structure, and stacking more than one gets noisy.

Metadata handles the cascade for you:

// routes/web.php
Route::metadata(['feature' => 'new-billing'])
    ->prefix('billing-v2')
    ->group(function () {
        Route::get('/', [BillingController::class, 'index']);
        Route::get('/invoices', [BillingController::class, 'invoices']);
        Route::resource('payment-methods', PaymentMethodController::class);
    });

// app/Http/Middleware/EnforceFeatureFlags.php
use Laravel\Pennant\Feature;

public function handle(Request $request, Closure $next): Response
{
    $flag = $request->route()->getMetadata('feature');

    if ($flag && ! Feature::active($flag)) {
        abort(404);
    }

    return $next($request);
}

Register the middleware globally on the web group. Routes without a feature key pass straight through. The resource inside the group is covered automatically, which is exactly the pending-registration case the old action-array hack couldn't handle.

And when the rollout finishes, you delete one metadata line instead of hunting middleware strings across three files.

Problem 3: Declarative Permission Tags in Middleware

To be clear about scope first: this doesn't replace policies and gates. Model-level authorization belongs in policies. But plenty of apps also have coarse route-level access rules ("everything under /admin/reports needs the reports.view permission") that end up scattered across can: middleware strings.

Metadata gives you a single declarative layer:

Route::metadata(['permissions' => ['admin.access']])
    ->prefix('admin')
    ->group(function () {
        Route::get('/dashboard', [DashboardController::class, 'index']);

        Route::metadata(['permissions' => ['admin.access', 'reports.view']])
            ->prefix('reports')
            ->group(function () {
                Route::get('/', [ReportController::class, 'index']);
                Route::get('/export', [ReportController::class, 'export']);
            });
    });

Note the nested group repeats admin.access in its list. That's deliberate: permissions is a list, and lists replace inherited values rather than merging. If you want additive permissions, either repeat the inherited ones like I did here, or structure them as an associative array (['admin.access' => true, 'reports.view' => true]) so the recursive merge works in your favor. This is the sharpest edge in the whole feature, so it's worth internalizing early.

The enforcement middleware is five lines:

public function handle(Request $request, Closure $next): Response
{
    foreach ($request->route()->getMetadata('permissions', []) as $permission) {
        abort_unless($request->user()?->can($permission), 403);
    }

    return $next($request);
}

One place to audit route-level access. php artisan route:list shows you the routes, the metadata shows you the rules, and nothing is hidden in controller constructors.

Problem 4: Breadcrumbs That Build Themselves

This is the use case Ben Bjurstrom, the PR's author, gave when asked what the feature is for: package authors need a place to attach data to routes while group and resource registration is still pending. Breadcrumbs are the perfect example because they're hierarchical, exactly like nested route groups.

Route::metadata(['breadcrumb' => ['Admin' => '/admin']])
    ->prefix('admin')
    ->group(function () {
        Route::metadata(['breadcrumb' => ['Admin' => '/admin', 'Users' => '/admin/users']])
            ->prefix('users')
            ->group(function () {
                Route::get('/', [UserController::class, 'index']);
                Route::get('/{user}', [UserController::class, 'show'])
                    ->metadata(['breadcrumb' => ['Admin' => '/admin', 'Users' => '/admin/users', 'Detail' => null]]);
            });
    });

A Blade component reads $request->route()->getMetadata('breadcrumb', []) and renders the trail. No third-party breadcrumb package, no separate breadcrumb definition file that drifts out of sync with your routes, no reflection tricks.

Because breadcrumb maps are associative arrays, nested groups merge cleanly and you could even skip repeating the parent crumbs. I repeat them anyway for explicitness, since key order in merged arrays is something I'd rather not depend on for UI. Expect packages to build nicer APIs on top of this primitive soon; error trackers are already reading it, and Flare 3.1.0 displays route metadata next to stack traces.

Problem 5: API Deprecation Headers From One Middleware

If you version APIs, you eventually deprecate endpoints. Communicating that properly means Deprecation and Sunset headers on every affected response, and most teams either skip it or hardcode headers in a dozen controllers.

Tag the routes instead:

Route::prefix('api/v1')
    ->metadata(['api' => ['version' => 1]])
    ->group(function () {
        Route::get('/orders', [Api\V1\OrderController::class, 'index'])
            ->metadata(['api' => [
                'deprecated_at' => '2026-07-01T00:00:00Z',
                'sunset' => '2026-12-31T23:59:59Z',
                'successor' => '/api/v2/orders',
            ]]);

        Route::get('/customers', [Api\V1\CustomerController::class, 'index']);
    });

// app/Http/Middleware/AddDeprecationHeaders.php
use Illuminate\Support\Carbon;

public function handle(Request $request, Closure $next): Response
{
    $response = $next($request);

    if ($deprecatedAt = $request->route()->getMetadata('api.deprecated_at')) {
        $response->headers->set('Deprecation', '@'.Carbon::parse($deprecatedAt)->timestamp);

        if ($sunset = $request->route()->getMetadata('api.sunset')) {
            $response->headers->set('Sunset', Carbon::parse($sunset)->toRfc7231String());
        }

        if ($successor = $request->route()->getMetadata('api.successor')) {
            $response->headers->set('Link', '<'.$successor.'>; rel="successor-version"');
        }
    }

    return $response;
}

The header formats matter here. RFC 9745, published March 2025, standardized the Deprecation header as a structured field date, meaning @ followed by a unix timestamp, and the older Sunset header from RFC 8594 takes a classic HTTP-date. Storing ISO strings in metadata and converting with Carbon at the edge keeps the route file readable while the wire format stays spec-compliant. Plenty of APIs still ship Deprecation: true from the pre-RFC draft days, but new code has no excuse.

Notice the dot notation doing real work too: api.deprecated_at reaches into the merged array, and the group's version key merged with the route's keys because both live under the associative api key.

The same metadata doubles as input for documentation tooling. Iterate the route collection in a command, read getMetadata('api'), and generate a deprecation report for your changelog. The data has one home and two consumers.

Where I'd Draw the Line

The contributor who questioned this feature on the PR wasn't entirely wrong. There's a version of route metadata that makes your app worse, and it looks like this: a junk drawer of loosely related keys that grows forever because "just add it to metadata" became the answer to everything.

My rules so far:

Metadata should describe the route, not configure behavior that belongs elsewhere. "This route is deprecated" describes. "Retry this route's queue jobs three times" configures, and belongs where queue configuration lives.

Keep values serializable. Everything goes through route:cache in production, so closures and objects are out. Strings, numbers, booleans, arrays. If you're tempted to put a closure in metadata, you actually want middleware.

Prefer associative structures over lists when groups are involved. You saw why in the permissions example. Lists replace on inheritance, and that surprises people.

Test the metadata directly. Since metadata is now load-bearing (a missing feature key means an unguarded route), a cheap test that iterates the route collection and asserts every route under a prefix carries the expected keys catches drift before production does:

it('guards every billing-v2 route with a feature flag', function () {
    $routes = collect(app('router')->getRoutes())
        ->filter(fn ($route) => str_starts_with($route->uri(), 'billing-v2'));

    expect($routes)->not->toBeEmpty();

    $routes->each(fn ($route) => expect($route->getMetadata('feature'))->toBe('new-billing'));
});

Five lines of Pest, and nobody can add a route to that group that silently skips the gate. This kind of route-collection assertion was always possible, but metadata finally gives it something structured to assert against.

And know when the old tools are still right. A one-off route with one middleware doesn't need a metadata layer plus a global middleware reading it. Metadata earns its place when the same kind of data applies across many routes, especially through groups and resources. For single-route concerns, route model binding and plain middleware parameters are still the simpler answer.

If you're not on Laravel 13 yet, this feature alone won't justify the jump, but combined with everything else in the release it's another reason to schedule it. The Laravel 12 to 13 upgrade guide covers the path, and the upgrade itself is one of the smallest major-version jumps Laravel has shipped.

FAQ

Which Laravel version do I need for route metadata?

Laravel 13.17.0 or later. The PR was merged on June 19, 2026 and shipped in the 13.17.0 release. It's a minor release, so if you're on any 13.x version, composer update gets you there with no breaking changes.

Does route metadata work with route:cache?

Yes, and this is the main advantage over rolling your own. Metadata is stored on the route action under a dedicated key, so php artisan route:cache serializes it and getMetadata() reads it back identically in cached and uncached environments.

Can I use this in Laravel 12 or 11?

No. The feature landed in 13.x only and there's no official backport. On older versions you're back to config maps or action-array workarounds, which is a decent nudge toward upgrading.

How is metadata() different from defaults()?

defaults() provides default values for route parameters, which means the values can be injected into controller method arguments. metadata() is inert data that never touches parameter binding. If you've been using defaults() to store non-parameter data, metadata is the correct home for it.

What's the difference between metadata() and setMetadata()?

metadata() merges with whatever the route already has, including values inherited from groups. setMetadata() replaces the entire metadata array, which is how a route opts out of its group's metadata completely.

Wrapping Up

Route metadata is a small feature with a long tail. Nothing here was impossible before. All of it was awkward before. The difference between "possible with hacks" and "supported with clean cascade semantics and cache safety" is the difference between a pattern you avoid and a pattern you reach for.

Start with one use case. The SEO middleware is the lowest-risk entry point, and once the getMetadata() pattern is in your muscle memory, you'll spot the other four in your own codebase within a week.

Running a Laravel app that's accumulated years of route-name conventions and config maps, and want help untangling it during a 13.x upgrade? Let's talk.

Laravel Reverb vs Pusher vs Soketi: Which WebSocket Server in 2026?

Hafiz — Wed, 01 Jul 2026 05:56:05 +0000

You're adding real-time features to a Laravel app. Live notifications, a chat panel, a collaborative cursor, a dashboard that updates without a refresh. The broadcasting code is the easy part because Laravel's API is the same no matter what's underneath. The actual decision is which WebSocket server sits behind it.

Three options dominate the Laravel world: Reverb (first-party, self-hosted), Pusher (hosted, pay per connection), and Soketi (open-source, self-hosted, Pusher-compatible). They all speak the Pusher protocol, so your broadcasting and Echo code barely changes between them. What changes is cost, scaling ceiling, and how much operational work lands on you.

I'll compare all three on the things that actually decide it, then give you a clear pick for each stage. There's also one fact about Soketi that should change how you think about it in 2026, and most comparisons skip it.

The Quick Version

Pusher is the hosted option: zero servers to run, you pay per concurrent connection, and it gets expensive as you grow. Reverb is Laravel's first-party server: free software, you host it (or let Laravel Cloud host it), and it scales with Redis. Soketi is the open-source Pusher-compatible server: also free and self-hosted, historically the budget favorite, but its maintenance situation in 2026 is the catch.

All three use the Pusher protocol. That's the thing that makes this a real choice rather than a lock-in: you can move between them with config changes, not rewrites.

Pusher: Pay to Not Think About It

Pusher is the original hosted WebSocket service, and the pitch hasn't changed. You never run a server. You never tune file descriptors or restart a daemon. You create an app, get credentials, and broadcast.

The pricing is connection-based and it's the whole story:

Free Sandbox: 100 concurrent connections, 200,000 messages/day
Startup: $49/month, 500 concurrent connections
Business: $299/month, 2,000 concurrent connections
Higher tiers climb past $499 to $1,199/month for 15,000 to 30,000 connections

A message counts both ways. Publish one event to 50 subscribers and that's 51 messages against your quota. For a chatty app (presence channels, typing indicators, live cursors) the message count climbs faster than you'd expect, and the daily cap on the free tier makes it unsuitable for production testing.

Pusher's real value is the zero-ops promise and the SDK breadth. If you want real-time working in 15 minutes and you'd rather pay than provision, it delivers. The problem is purely cost at scale: 2,000 connections for $299/month is the kind of bill that makes self-hosting look attractive the moment you have the ops capacity to handle it.

Reverb: The First-Party Default

Reverb is Laravel's own WebSocket server, built on ReactPHP, shipped in 2024, and by 2026 it's the default choice for most Laravel teams. It speaks the Pusher protocol, so it's a drop-in for Laravel broadcasting and Echo. A single server handles thousands of concurrent connections, and it's free software: you only pay for the box it runs on.

That last point is the headline. A Reverb instance on a $10 DigitalOcean droplet or a cheap Hetzner VPS handles early-stage real-time features for the cost of the server, not per connection. Compared to Pusher's $49 to $299 tiers, the savings start immediately and widen as you grow.

Scaling past one server uses Redis. You set REVERB_SCALING_ENABLED=true, point your Reverb instances at a shared Redis server, and put them behind a load balancer. When a message hits one server, Redis publishes it to the others via pub/sub, so connections spread across machines stay in sync. It's the same horizontal-scaling pattern you'd use for any stateful service.

Two things make Reverb in 2026 stronger than it was at launch.

First, the database driver. You no longer need Redis for small-to-medium apps. Reverb can use your existing MySQL or Postgres database to coordinate, which means you can ship live notifications, dashboards, and collaborative features without provisioning, securing, and paying for a Redis cluster. For early-stage products that's a real infrastructure cost cut. For high-throughput apps (10,000+ concurrent connections), Redis is still the recommended backend.

Second, managed Reverb on Laravel Cloud. If you want Reverb's economics without running the server yourself, Laravel Cloud offers fully managed Reverb clusters. You pick the number of concurrent connections, and Laravel claims up to 50% less than third-party tools like Pusher. It became the single most requested Cloud feature for a reason: it's the middle ground between self-hosting and paying Pusher's per-connection rates. It's the same managed-versus-self-hosted trade I walked through for Cloud's managed queues versus Horizon, just applied to WebSockets.

The cost of Reverb shows up as operations, not dollars. A self-hosted Reverb server is a long-running process you have to keep alive with Supervisor, tune for open file limits, restart on deploy with reverb:restart, and monitor. If your site is on Forge, the Application panel has a Reverb integration that handles the server tuning for you. But it's still infrastructure you own. That's the trade against Pusher: you swap a monthly bill for operational responsibility.

Soketi: The Catch in 2026

Soketi is an open-source, Pusher-compatible WebSocket server built on uWebSockets.js (a C library ported to Node.js, which makes it very fast). For years it was the go-to budget pick: run it on a $5 to $10 instance and get effectively unlimited connections and messages, where the equivalent Pusher plan would cost $49 for just 500 connections. On raw price-per-connection, Soketi has always won.

Here's the part most comparisons won't tell you, and it's the most important fact in this whole post. As of 2026, Soketi's maintenance is a concern, and that's not speculation. The maintainers say so directly. Their own documentation describes release and maintenance frequency as based on available time that's "tight as hell," and openly notes that maintenance issues have caused infrequent updates and infrequent support.

That changes the calculation. A Pusher-compatible server that's blazing fast and free but slowly maintained is fine for a side project where you can absorb the risk. For something you're betting a business on, leaning on a server whose maintainers have flagged their own limited bandwidth is a different proposition. And the kicker: Reverb now does almost everything Soketi did (Pusher protocol, self-hosted, free, fast), but with the entire Laravel core team behind it and first-party integration. The main reason to pick Soketi over Reverb in 2026 is if you specifically want a Node-based server in a non-Laravel-centric stack. Inside a Laravel app, Reverb has quietly taken Soketi's lunch.

Head to Head

Cost at a small scale (say 500 concurrent connections): Pusher is $49/month. Reverb is the price of a $10 VPS. Soketi is the price of a $5 to $10 VPS. Self-hosting wins by a wide margin the moment you can run a server.

Cost at a larger scale (5,000+ connections): Pusher runs into the hundreds per month and keeps climbing. Reverb and Soketi cost the same VPS plus a Redis instance, a fraction of the hosted price, but now you're managing horizontal scaling yourself. Managed Reverb on Laravel Cloud sits in between: more than a raw VPS, less than Pusher, and if you're already eyeing Cloud, the $5 plan with spend caps and scale-to-zero keeps the floor low.

Operational burden: Pusher is zero. Managed Reverb (Cloud) is near zero. Self-hosted Reverb and Soketi both require you to run, tune, monitor, and scale a long-running process.

Maintenance confidence: Reverb and Pusher are actively, professionally maintained. Soketi has the open maintenance concern above.

Laravel integration: Reverb is first-party and tightest. Pusher and Soketi are Pusher-protocol compatible, which is close, but Reverb is the one the framework ships with and the docs assume.

My Recommendation

For most Laravel apps in 2026, start with Reverb. It's first-party, it's free, the database driver means you don't even need Redis early on, and a single instance handles thousands of connections on a cheap server. You'd have to have a specific reason not to use it.

If you don't want to run any infrastructure and you'd rather pay for it, you've got two clean options. Managed Reverb on Laravel Cloud keeps you in the Reverb ecosystem with no ops. Pusher makes sense if you want a battle-tested hosted service with the broadest SDK support and you're early enough that the connection count keeps you in the cheaper tiers.

Pick Pusher over managed Reverb when you need the SDK breadth for non-web clients, or you want a vendor with a long track record and enterprise SLAs. Pick managed Reverb when you're a Laravel shop that wants the lowest hosted cost and tightest framework fit.

I'd be cautious about starting a new production project on Soketi in 2026. The technology is solid and fast, but the maintainers' own note about limited upkeep, combined with Reverb now covering the same ground with first-party backing, makes it hard to recommend over Reverb for new Laravel work. If you're already running Soketi happily, there's no fire drill. But for a fresh build, Reverb is the safer version of the same idea.

FAQ

Can I switch between these later without rewriting?

Mostly yes, and that's the upside of all three speaking the Pusher protocol. Your Laravel broadcasting code and Echo config stay the same; you change connection credentials and host settings. Moving from Pusher to Reverb, or Soketi to Reverb, is a config and infrastructure task, not an application rewrite. That makes "start simple, move later" a viable strategy.

Do I need Redis for Reverb?

Not anymore, for small-to-medium apps. Reverb's database driver lets it coordinate through your existing MySQL or Postgres, so you can skip Redis entirely early on. You'll want Redis once you scale horizontally across multiple Reverb servers or push into very high connection counts (10,000+), where it's the recommended backend.

How many connections can one Reverb server handle?

A single Reverb instance handles thousands of concurrent connections, with the exact ceiling depending on your server's resources and tuning (open file limits matter a lot here). Past what one box can hold, you scale horizontally with Redis pub/sub and a load balancer. For context, Soketi reports holding 500 active high-traffic connections on a 1GB, 1-CPU machine, and Reverb is in the same class.

Is Pusher still worth paying for?

When you value zero operations and broad SDK support over cost, yes. Pusher's advantage is that you never run anything and it works across many platforms and languages. The downside is purely price: connection-based tiers get expensive fast, and a chatty app burns message quota quickly. If you have the ops capacity to run Reverb, the math usually favors self-hosting.

What about Ably or other alternatives?

Ably is another hosted option with stronger delivery guarantees (exactly-once, message history, state recovery) and is worth a look for mission-critical messaging where dropped messages aren't acceptable. But it's not Pusher-protocol native in the way these three are, so it's a bigger integration lift inside Laravel. For most Laravel real-time features, the Reverb-Pusher-Soketi triangle covers the decision.

Wrapping Up

The honest 2026 answer is that Reverb won the default-choice slot, and for good reasons: first-party, free, fast, and no longer even requiring Redis for smaller apps. Pusher remains the right call when you'll pay to never touch infrastructure, especially via managed Reverb if you want to stay in the Laravel ecosystem. And Soketi, once the obvious budget pick, now carries a maintenance question that Reverb sidesteps entirely. Start with Reverb, reach for a hosted option when ops isn't where you want to spend time, and treat the Pusher protocol compatibility as your insurance policy to change your mind later.

If you're planning real-time features for a Laravel app and want help choosing and setting up the right WebSocket layer, let's talk.

Connect a Laravel AI Agent to Any MCP Server: A Hands-On Guide

Hafiz — Mon, 29 Jun 2026 07:01:09 +0000

Most Laravel MCP tutorials teach you to build a server. You expose your app's tools, an AI client connects, and Claude or Cursor can query your orders table. Useful, and I've covered building an MCP server with Filament before.

This post goes the other direction. Your Laravel AI agent becomes the client. It connects out to any MCP server, GitHub, Notion, Laravel Nightwatch, or one you run locally, and uses that server's tools as if you'd written them by hand. If you've built an agent with the Laravel AI SDK already, this slots straight into the agent you have. Ask your agent to "look into the latest exception in my app" and it browses your Nightwatch issues, pulls the stack trace, and reports back. You wrote none of that integration code.

Laravel shipped this on June 9, 2026. It's the piece that turns an agent from something that only knows your code into something that can reach into every tool your team already uses. If you've been giving your agent context with Laravel Boost and MCP, this is the reverse: your agent reaching out instead of a tool reaching in. Here's how to wire it up, from a no-auth local server to a full OAuth flow, plus the gotchas that'll bite you in production.

What Actually Ships in the Box

The feature is two packages working together, and the split matters.

The MCP client lives in laravel/mcp. It knows how to connect to a server, negotiate the handshake, authenticate, and call tools. It works on its own, from a queued job or a console command, with no agent anywhere in sight.

The thin integration lives in laravel/ai. It lets an agent consume that client without changing how agents already work. You drop MCP tools into the same tools() array you already use, and the SDK wraps each one to fit the agent's tool contract.

Before any code, pin your versions. As of late June 2026:

laravel/mcp v0.8.1 (the 0.8 line introduced the client; earlier versions were server-only)
laravel/ai v0.8.1
Laravel 12 or 13
PHP 8.3 or higher

That PHP floor matters. laravel/mcp itself tolerates PHP 8.2, but laravel/ai requires 8.3, and you need both for this. If you're on 8.2, Composer will refuse to resolve. Check what you've got:

composer show laravel/mcp laravel/ai

The Client Surface

The whole client is three verbs: connect, list tools, call a tool. Everything else stays out of your way.

use Laravel\Mcp\Client;

// A remote server over HTTP
$client = Client::web('https://mcp.example.com');

// A local server you run as a process (STDIO)
$client = Client::local('php', ['artisan', 'mcp:start']);

Those two constructors are the two transports. web() uses streamable HTTP for remote servers you reach over the network. local() uses STDIO (standard input/output) for servers you run as a child process on the same machine. You pick by where the server lives, not by preference.

Listing and calling tools looks like this:

$tools = $client->tools();

$result = $client->callTool('search-issues', [
    'query' => 'payment failed',
]);

$result->text();             // the text content
$result->isError;            // did the tool report a failure
$result->structuredContent;  // structured payload, if the tool returned one

The connection happens lazily on the first real call, so you don't have to manage it manually. But you can if you want:

$client->connect();
$client->ping();
$client->disconnect();

During that connection, the client and server negotiate a protocol version and exchange capabilities, so both sides agree on the rules before any work happens. You don't write any of that. It's the handshake, and when it fails (more on that later) it's usually an auth or version mismatch underneath.

Step 1: A Local Server With No Auth

Start with the simplest possible case so you see the wiring before the complexity. Point an agent at a local MCP server (yours, or any STDIO server) with no authentication at all.

Inside your agent, the MCP tools go straight into the tools() method, right next to your hand-written tools:

use App\Ai\Tools\SendSlackMessage;
use Laravel\Mcp\Client;

public function tools(): iterable
{
    return [
        ...Client::local('php', ['artisan', 'mcp:start'])->tools(),
        new SendSlackMessage,
    ];
}

That's the entire integration. The spread operator drops every tool from the MCP server into the array. The SDK notices they're MCP tools and wraps each one: it translates the MCP input schema into Laravel's JSON schema, calls the remote tool when the model asks for it, and normalizes whatever comes back into a result the model can read. The model has no idea which tools came from MCP and which you wrote. They all look the same to it.

This is the mental model for the whole feature. If you can get one local server connected, every other server is just a different transport and an auth layer on top.

Step 2: Bearer Token Auth

Most useful servers want to know who you are. The simpler auth path is a bearer token, a string you already hold. A GitHub personal access token is the classic example.

use Laravel\Mcp\Client;

$client = Client::web('https://api.githubcopilot.com/mcp/')
    ->withToken($token);

You can pass a closure instead of a raw string, which is what you want when the token belongs to the currently authenticated user:

$client = Client::web('https://api.githubcopilot.com/mcp/')
    ->withToken(fn () => auth()->user()->github_token);

Drop it into the agent the same way:

public function tools(): iterable
{
    return [
        ...Client::web('https://api.githubcopilot.com/mcp/')
            ->withToken(fn () => auth()->user()->github_token)
            ->tools(),
    ];
}

Now your agent can search repositories, read CI logs, triage issues, and check Dependabot alerts. GitHub's server even supports a read-only mode through a request header if you'd rather the agent not change anything.

Step 3: Full OAuth (The Real-World Case)

Bearer tokens are fine when you already have a token. But hosted servers like Laravel Nightwatch use OAuth, where the user clicks a button, approves access on the provider's site, and comes back with a token your app stores. (If you're weighing Nightwatch against the alternatives, I compared Telescope vs Pulse vs Nightwatch separately.) This is the part the official announcement glosses over, so here's the whole flow.

use Laravel\Mcp\Client;
use Laravel\Mcp\Facades\Mcp;

Mcp::registerClient('nightwatch', fn () => Client::web('https://nightwatch.laravel.com/mcp')
    ->withOAuth(
        clientId: config('services.nightwatch_mcp.client_id'),
        clientSecret: config('services.nightwatch_mcp.client_secret'),
    ));

If the server supports dynamic client registration, you can omit the ID and secret entirely and the client registers itself. Whether you can do that depends on the server, which becomes important when things break.

Next, wire the connect and callback routes in routes/ai.php. The package gives you a helper that registers both:

use Laravel\Mcp\Client\OAuth\TokenSet;
use Laravel\Mcp\Facades\Mcp;

Mcp::oAuthRoutesFor('nightwatch', function (string $client, TokenSet $token) {
    auth()->user()->update([
        'nightwatch_mcp_token' => $token->accessToken,
    ]);

    return redirect('/dashboard');
});

This registers two named routes: mcp.oauth.nightwatch.connect and mcp.oauth.nightwatch.callback. The connect route redirects the user to the authorization server. The callback route exchanges the authorization code and runs your closure with a fresh token. You never touch the redirect URLs or the PKCE details.

Then a button in your Blade view kicks it off:

<a href="{{ route('mcp.oauth.nightwatch.connect') }}">
    Connect Nightwatch
</a>

The flow runs in order: the user clicks the button, the package redirects them to Nightwatch, they sign in and approve, Nightwatch sends them back to your callback route, your closure runs with the token, and you store it however you like. The package owns the OAuth choreography. Your app owns where the token lives.

One thing to be clear about: there's no built-in token store. You persist $token->accessToken yourself, and you read it back when you build the client. The package handles refreshing expired tokens, but storage is on you.

Once the token's stored, the agent uses the named client:

public function tools(): iterable
{
    return [
        ...Mcp::client('nightwatch')->tools(),
    ];
}

Now ask the agent: "What are the most recent exceptions in production? Help me prioritize which to fix first." It browses your issues, reads stack traces, and answers. Tell it "mark issue 123 as resolved with a comment summarizing the fix," and it does that too.

How the Agent Sees MCP Tools

Here's the flow from prompt to remote tool call and back, so you know what's happening when the model decides to use a Nightwatch tool.

The key insight is in the middle. By the time the model is choosing, native and MCP tools sit in the same list and look identical. The wrapping, the schema translation, the network call, the result normalization, all of it happens below the model's awareness.

Caching the Tool List

Listing tools is a network round trip on a remote server, and the tool list rarely changes. So cache it. Because tools come back as plain data, you wrap the call in Laravel's cache and they rehydrate cleanly:

use Illuminate\Support\Facades\Cache;

$tools = Cache::remember('mcp.nightwatch.tools', now()->addHour(), function () {
    return Mcp::client('nightwatch')->tools();
});

Worth knowing: this isn't a dedicated client feature, despite what some descriptions imply. It's standard Laravel caching wrapped around the tools() call. The win is real though: you skip a round trip on every single prompt, which matters most for OAuth-secured remote servers where each call carries auth overhead.

Testing Without a Live Server

You don't want your test suite hitting a real MCP server over the network. Laravel AI's faking layer lets you script the model's responses while the tool call still flows through the MCP layer.

MCP tool names follow a mcp_tools_<name> pattern. A server tool called search shows up to the agent as mcp_tools_search. So you can fake a model response that calls the tool, then a final answer, and assert on the result:

use Laravel\Ai\Facades\Ai;

it('investigates exceptions through the nightwatch agent', function () {
    Ai::fake([
        Ai::toolCall('mcp_tools_search-issues', ['query' => 'payment']),
        Ai::text('Found 3 payment exceptions. The most frequent is a Stripe timeout.'),
    ]);

    $response = (new SupportAgent)->prompt('Any payment errors lately?');

    expect((string) $response)->toContain('Stripe timeout');
});

You test the production path (the agent calling a tool, reading the result, responding) without a single network call.

The Gotchas That'll Actually Bite You

The happy path is clean. Here's what isn't, drawn from real issues developers have hit.

OAuth handshake failures are the big one. There's a documented case (laravel/boost issue #584) where connecting Nightwatch through certain agents threw 403 Forbidden ... when send initialize request before auth, and handshake decoding errors after. The reported cause: the client didn't detect that auth was required and never triggered the login flow. Two fixes came out of that thread. Run an explicit login for your agent if it supports one. Or route through the mcp-remote bridge instead of pointing directly at the URL, which is what Nightwatch's own docs recommend for several clients. If a direct connection fails the handshake, try the bridge before assuming your code is wrong.

Dynamic client registration isn't universal. Remember the OAuth step where you could omit the client ID and secret? That only works if the server supports dynamic client registration. Several servers require a pre-registered OAuth client, and trying to auto-register against them fails, often as a 403 that looks like an auth bug. Know which mode your target expects: if it doesn't do dynamic registration, you must supply clientId and clientSecret explicitly.

Token storage is your job, and it's easy to get wrong. The package refreshes tokens but doesn't store them. The common mistake is persisting the token somewhere your withToken() closure can't read it back, or not persisting it at all and wondering why every request re-prompts for auth.

Protocol version mismatches surface as handshake failures. Servers advertise different MCP spec versions. If a server only speaks a version the client doesn't negotiate, the connection fails at the handshake. The error won't always say "version," so keep it on your list of suspects when a connection won't establish.

Remote tool errors don't throw into your code. When a remote tool fails, the result carries isError rather than raising an exception in your agent loop. The wrapper normalizes the failure into something the model can read and react to. Check isError if you're handling results manually.

When to Use This (and When Not To)

Reach for an MCP client connection when the tool already exists as an MCP server and you'd otherwise be writing an API integration by hand. Nightwatch, GitHub, Notion, and a growing list of services expose MCP servers. Consuming one is a few lines; rebuilding its integration is a few days.

Skip it when a plain API call or a tool class you write yourself is simpler. If you only need one endpoint from a service, a small hand-written tool beats pulling in an entire MCP connection and its auth flow. MCP earns its place when you want many of a server's capabilities, or when the server is something like Nightwatch where the tools are rich enough to be worth the wiring.

And if you're building tools for your own app, remember you can reuse your laravel/mcp server tool classes directly in an agent with no client at all. Write the tool once, use it as a server tool for external clients and as a native agent tool internally. It's the same instinct behind making your whole Laravel app AI-agent friendly: build the capability once, expose it everywhere.

FAQ

Do I need to build an MCP server to use this?

No. This is the opposite direction. You're consuming external servers as a client. You don't expose anything. If you also want to expose your own app's tools to outside AI clients, that's the server side, which is a separate setup.

Which transports does the client support?

Two: STDIO for local servers you run as a process (Client::local(...)), and streamable HTTP for remote servers you reach over the network (Client::web(...)). You choose based on where the server runs, not preference.

Can I connect to multiple MCP servers in one agent?

Yes. Spread multiple clients into the same tools() array, mixing transports and auth freely. A local STDIO server and a remote OAuth server can both feed one agent, alongside your hand-written tools. The model treats them all identically.

How do I handle a server that needs OAuth but my client runs headless?

OAuth assumes a human approves access in a browser. For background or headless work, some servers support a client-credentials grant (no user in the loop), which the package handles. Others, like Notion's remote server, explicitly aren't built for headless agents, and you'd need a different auth path or a token issued ahead of time.

Does this work with Laravel 11?

The laravel/mcp client supports Laravel 11, 12, and 13, but laravel/ai requires Laravel 12 or 13 and PHP 8.3+. Since the agent integration needs both, you effectively need Laravel 12 or 13 to use an agent as an MCP client.

Wrapping Up

The agent-as-client direction is the quieter half of Laravel's MCP story, and the more useful one for most apps. Building a server exposes your app to AI tools. Consuming servers gives your agent reach into every tool your team already runs, with a few lines instead of a custom integration per service. Start with a local no-auth server to internalize the tools() pattern, graduate to a bearer token, then wire the full OAuth flow when you connect something like Nightwatch. And keep the troubleshooting section handy, because the handshake and OAuth edge cases are where the real time goes.

If you're building agent features into a Laravel app and want help getting the MCP layer right, let's talk.

PHP 8.5's Pipe Operator vs Laravel Collections: Where Piper Fits (And Where It Doesn't)

Hafiz — Wed, 24 Jun 2026 07:55:49 +0000

PHP 8.5 shipped the pipe operator in November, and most Laravel developers shrugged. Why would we care about |> when collect()->filter()->map() has read top-to-bottom for a decade? Chained transformations are a solved problem in Laravel.

Then Spatie released Piper last month: a library that ports Laravel's collection and string helpers to standalone functions built specifically for the pipe operator. When the team that maintains 300+ Laravel packages decides the pipe operator needs a Laravel-flavored toolkit, the question stops being academic. Is there an actual reason to write $array |> filter(...) |> map(...) instead of reaching for Collections?

I dug into the package, the design decisions behind it, and where each approach actually wins. Short answer: Piper isn't a Collections replacement and doesn't try to be. But there are two specific situations where it's the better tool, and one hard constraint that decides everything before style ever enters the picture.

A 60-Second Pipe Operator Refresher

The pipe operator takes the result of the left expression and passes it as the single argument to the callable on the right:

$result = '  laravel  '
    |> trim(...)
    |> strtoupper(...);

// "LARAVEL"

Each step reads in execution order, top to bottom, no nesting, no intermediate variables. The (...) syntax is PHP 8.1's first-class callable notation.

The catch: the right side must be a callable that accepts exactly one argument. And PHP's standard library was not designed for that. Argument orders are famously inconsistent (array_map($callback, $array) but array_filter($array, $callback)), so half the stdlib needs wrapping in arrow functions before it pipes. That friction is exactly the gap Piper fills.

What Piper Actually Does

Piper (v1.0, requires PHP 8.5) ports Laravel's array and string helpers to namespaced functions under Spatie\Piper\Arr and Spatie\Piper\Str. The design trick: every function is a higher-order function. Calling filter(fn ($i) => $i % 2 === 0) doesn't filter anything. It returns a closure waiting for the one value the pipe will feed it:

use function Spatie\Piper\Arr\{filter, map, join};
use function Spatie\Piper\Str\{prefix, suffix};

$summary = [1, 2, 3, 4, 5, 6]
    |> filter(fn (int $i) => $i % 2 === 0)
    |> map(fn (int $i) => $i ** 2)
    |> join(', ', ', and ')
    |> prefix('The winning numbers are ')
    |> suffix('.');

// "The winning numbers are 4, 16, and 36."

Notice what's absent: no collect() going in, no ->all() or ->toString() coming out. Plain arrays and strings flow through plain functions. That's the entire philosophy.

Where Piper Beats Collections

Native values in, native values out. Collections are a wrapper object. You pay a conversion at each boundary: collect($array) to enter, ->all() to leave, and every method returns a new Collection instance along the way. In application code you barely notice. In code that interfaces with anything expecting plain arrays (third-party SDKs, array-typed signatures, JSON boundaries), the wrapping and unwrapping is pure ceremony. Piper skips it entirely: each function takes an array, returns an array.

Mixing your own functions into the chain. This is the pipe operator's structural advantage, and it's something Collections can't do cleanly. A Collection chain can only call methods that exist on the Collection class (or macros you register globally). A pipe chain accepts any callable: Piper helpers, native functions, your own domain functions, all in one flow:

use function Spatie\Piper\Arr\{filter, map};

$total = $orders
    |> filter(fn (Order $o) => $o->isPaid())
    |> map(fn (Order $o) => $o->total)
    |> array_sum(...)
    |> $this->applyDiscount(...);

With Collections, applyDiscount() either becomes a macro, a ->pipe() call, or a break out of the chain into a variable. The pipe operator treats your functions as first-class chain citizens.

No framework dependency. Piper's functions are standalone with zero Illuminate packages required. For package authors who want Laravel-style ergonomics without pulling illuminate/collections into their dependency tree, that's a real selling point.

Where Collections Still Win

API surface. Piper v1 ports the most-used helpers. Collections have 100+ methods refined over a decade: groupBy(), pluck() with dot notation, chunk(), zip(), mapWithKeys(), higher-order messages like ->map->title, and on and on. The moment your transformation needs one of the deeper methods, you're back in collect() territory, and splitting one pipeline across both styles is worse than picking one.

Lazy evaluation. LazyCollection processes large datasets (cursor results, big files) one item at a time with constant memory. Piper has no lazy story: each function in the chain materializes a full new array. For query results you've already optimized, chaining five Piper functions over 100,000 rows allocates five intermediate arrays.

Eloquent integration. Query builders return Collections. Relations return Collections. Every Laravel API hands you a Collection already. Converting to a plain array just to pipe it through Piper means swimming upstream against the entire framework.

Discoverability. Type -> after a Collection and your IDE lists every available method. With Piper you need to know the function exists, import it, and keep your use function block tidy. It's a small tax, but it's paid on every file.

The Constraint That Decides Everything

Piper requires PHP 8.5. That's not a style consideration, it's a hard gate. PHP 8.5 shipped in November 2025, and most production fleets I see are still on 8.2 through 8.4. If your servers aren't on 8.5, this entire discussion is theoretical, and I'd guess that covers the majority of Laravel apps in production today. I wrote about this lag pattern before: PHP 8.4 features were still "new" to most codebases a full year after release.

There's a second adoption headwind worth naming: AI coding assistants. Sebastian De Deyne (who built Piper) observed that coding agents essentially never produce pipe operator code unless explicitly asked. Training data has a decade of collect() chains and almost no |>. In 2026, syntax that your tooling doesn't reach for by default spreads slower, regardless of merit.

My Take

Use Piper when you're writing framework-agnostic code (packages, shared libraries) or transformation-heavy code on native arrays and strings where pulling in Collections feels like overkill. The function-mixing capability is the one place the pipe operator is structurally better than method chaining, not just different. It's the same kind of decision-tree thinking I apply to services versus actions: pick by code context, not by what's newest.

Inside a Laravel app, keep using Collections. They're everywhere, your team knows them, Eloquent hands them to you, and the lazy variant handles scale. Piper isn't trying to dethrone them; it's filling the gap for the code that lives between Laravel projects. Spatie has a habit of shipping packages a few years before the ecosystem catches up (Scotty did this for deployment), and Piper reads like a bet on where PHP code style lands by 2028, not a tool you must adopt this sprint.

FAQ

Does Piper replace Laravel Collections?

No, and Spatie doesn't position it that way. Piper covers array and string transformations on native values. Collections remain the richer, framework-integrated tool. Think of Piper as a companion for the places Collections are awkward, not a successor.

Can I use the pipe operator with Collections directly?

Not meaningfully. Collections are objects with chained methods, and the pipe operator wants single-argument callables. You could pipe into collect(...) to enter Collection-land, but at that point just use the Collection chain.

Does the pipe operator perform better than Collection chaining?

Marginally, in theory: plain function calls skip the object method dispatch and per-step Collection instantiation. In practice the difference is noise compared to your database queries. Don't pick either approach for performance; pick for readability and context.

Can I use Piper in Laravel 13?

Yes, as long as your runtime is PHP 8.5 or higher. The package has no framework dependency, so it works in any PHP 8.5 project, Laravel or not. The version check that matters is your PHP binary, not your Laravel version.

What about Stringable for string chains?

Laravel's Str::of() fluent strings cover the same ground as Spatie\Piper\Str inside a Laravel app, with the same trade-offs as Collections: wrapper object, framework dependency, huge API. The same logic applies: Stringable in app code, Piper in framework-agnostic code.

Wrapping Up

The pipe operator is the most interesting thing to happen to PHP syntax in years, and Piper is the first serious attempt to make it ergonomic for the Laravel crowd. But interesting and necessary aren't the same thing. If your production PHP is 8.5 and you write package code or work with native arrays at framework boundaries, Piper earns a spot in your composer.json. For everything else, collect() isn't going anywhere.

If you're modernizing a Laravel codebase and weighing which PHP 8.5 features are actually worth adopting, let's talk.