The Laravel starter kits (React, Vue, Svelte, and Livewire) have had a huge run of updates recently, including team support, Inertia v3 support, and toast notifications.

I'll be going live tomorrow (04/21) at 12pm EDT (4pm UTC) with Wendell Adriel for a walkthrough of what's new. We'll also touch on Maestro, the orchestrator that powers how all the kits stay in sync.

Would love to see you there! If you have any questions, feel free to drop them here ahead of time or ask in chat during the stream!

Stream: https://www.youtube.com/watch?v=AbPSAt46Ja0

I just released Laravel subscriptions with a ready-to-use Filament UI.

This allows developers to set up subscription sales in their projects in 15 minutes, or an hour at most.

It comes with:

• Pre-built pricing pages (Tailwind)
• Filament admin dashboard for managing subscriptions
• Built-in webhook handling

This idea came to me when I was faced with implementing subscriptions myself. There were many pitfalls. Debugging was difficult. Boxed solutions were cumbersome and expensive.

Previously, this was practically impossible due to integration with the existing admin panel. Now, Filament solves this problem.

Did I solve someone's problem?

I’d love to hear your feedback on the code architecture or features I should add next!

Live Demo: https://subkit.noxls.net/

GitHub: https://github.com/karpovigorok/subkit

https://techstackups.com/articles/laravel-raised-money-and-now-injects-ads-directly-into-your-agent/

We just released Pagible 0.10, an open-source AI-powered CMS built for Laravel developers:

• https://pagible.com/laravel-cms

What's new in 0.10

• MCP Server — Pagible ships with a built-in Model Context Protocol server. AI agents can create pages, manage content, and search your site programmatically. This makes Pagible one of the first CMS platforms where AI can directly manage your content through a standardized protocol.
• Customizable architecture — The codebase has been split into 9 independent sub-packages (core, admin, AI, GraphQL, search, MCP, theme, etc.). Install only what you need.
• Vuetify 4 admin panel — The admin backend has been upgraded to Vuetify 4 and optimized for WCAG accessibility, keyboard navigation and reduced bundle size.
• Significant performance work — This release focused heavily on database performance: optimized indexes, reduced query count, eager loading, optimized column selection, and faster page tree fetching.
• Rewritten fulltext search — Custom Scout engine supporting fulltext search in SQLite, MySQL/MariaDB, PostgreSQL, and SQL Server. Paginated results with improved relevance ranking.
• Named roles & JSON permissions — Moved from bitmask permissions to a readable JSON array system with configurable roles (e.g. editor, publisher, viewer, etc).
• Security hardening — Rate limiting on all endpoints, strict security, DoS protection against all inputs.

What makes Pagible different

• Laravel-native — Not a CMS bolted onto Laravel. It uses Blade, Eloquent, migrations, Scout, service providers — everything you already know.
• AI-first — MCP server for agent-driven content management, plus built-in AI features for content generation, translation, and image manipulation via Prism/Prisma.
• Hierarchical pages — Nested set tree structure with versioning. Editors see drafts, visitors see published content.
• Multi-tenant — Global tenant scoping on all models out of the box.
• Small footprint — The entire codebase is deliberately kept small. No bloat, no unnecessary abstractions.
• LGPL-3.0 — Fully open source.

Links

• Demo: https://demo.pagible.com/
• GitHub: https://github.com/aimeos/pagible
• Website: https://pagible.com/laravel-cms

Would love to hear your feedback and if you like it, give a star :-)

Hey there everyone.

When working with libraries like Filament, a lot of the queries are not explicit in code as only Model classes are passed around. This makes debugging and improving query performance more difficult. Existing debugging tools like Debugbar or Telescope work require a browser UI and aren't very accessible to coding agents.

I built LaraPerf.dev because I wanted to let my agents run in a loop and continue trying to find query speed improvements.

The tool is optimized for having an agent call it as a tool call.

The agent calls `artisan perf:watch --seconds 20` which will listens to all queries for 20 seconds. However, the command immediately exits to let the agent do more actions within those 20 seconds. The agent can then query through all query results with the `perf:query` command to find slow or N+1 queries and with `perf:explain` to run `EXPLAIN ANALYZE` for a given query.

It also comes with a premade skill to let your agent run in a loop.

Find it at https://laraperf.dev or checkout the code at https://github.com/mateffy/laraperf

https://laravelshopper.dev/blog/announcing-the-livewire-starter-kit

Hey r/laravel,

I built Relay — an open source WebSocket server written in Go. Sharing it here since most of you are the target audience.

Why build this when Reverb exists?

Reverb is great and I want to be upfront about that. The real reason Relay exists is different: Reverb runs inside a Laravel PHP application — you need a Laravel app running to host it. Relay is a standalone Go binary with zero dependencies. No PHP, no Composer, no Laravel. You drop it on any server and run it.

That matters if you want to self-host WebSockets without owning a Laravel app, or if you want a server that starts in milliseconds and uses minimal resources regardless of what stack you're on.

What Relay actually does differently:

• Single Go binary — no runtime, no dependencies, drop it anywhere
• Performance — at 1,000 concurrent connections: ~18% CPU, ~38MB RAM vs Reverb's ~95% CPU, ~63MB RAM on equivalent hardware
• Built-in Channel Inspector — live view of active channels, subscriber counts, and event payloads with syntax highlighting. Nothing like it exists in Reverb.
• Open source exit ramp — Relay Cloud is the managed tier, but the binary is MIT licensed. Self-host free forever, or move between cloud and self-hosted with two env var changes.

What Relay does NOT uniquely offer:

Being honest here since I got called out on this elsewhere — Relay, like Reverb and every other Pusher-compatible server, works with any Pusher client. That's not unique. It's just how the Pusher protocol works. Reverb also supports multiple apps and Laravel Cloud now has a fully managed Reverb offering.

The stack:

Server: Go binary, MIT licensed — github.com/DarkNautica/Relay

Managed cloud (optional): relaycloud.dev — free hobby plan, $19/mo Startup

Laravel package: composer require darknautica/relay-cloud-laravel

Benchmark post: relaycloud.dev/blog/relay-vs-reverb-benchmark

Happy to answer questions and take criticism — clearly still learning what makes this actually unique.

I posted recently on Reddit about building a fluent validation rule builder for Laravel (laravel-fluent-validation). Since then I also released a Rector companion package for automated migration. Instead of the usual pre-release-and-wait cycle, I ran Claude Code on the package repo and on three production Laravel codebases simultaneously and let the Claude instances work together.

The workflow

claude-peers is an MCP server for Claude Code. Each instance running on your machine can discover other instances, see what they're working on, and send messages. They don't share context. Each has its own conversation with full codebase access.

In practice it works like this: the package peer tags a new release. It sends a message to the three codebase peers saying "0.4.5 tagged, fixes the parallel-worker race, please re-verify." Each codebase peer receives the message, pulls the new version, runs the migration, runs their tests, and sends back results. If something breaks, the response includes the exact error, the file, and usually a theory about why. The package peer reads that, asks follow-up questions if needed, fixes the issue, and the loop continues.

One thing I didn't expect was how quickly the peers developed their own review dynamic. They would challenge each other's assumptions, ask for evidence, and sometimes reach consensus before coming back with a recommendation.

I had four terminals open:

• The package repo, building features, writing tests, shipping releases
• Three production codebases, each a real Laravel app with its own validation patterns, framework integrations, and test suites

Everything runs locally. Claude Code works on local clones of each codebase, with the same filesystem access you'd have in your terminal. No production servers, no remote environments, no secrets exposed to AI.

The interesting part was what the peers caught that tests and synthetic fixtures couldn't:

• One app has 108 FormRequests and uses rules() as a naming convention on Actions and Collections. The skip log grew to 2,988 entries / 777KB. On a smaller codebase you'd never notice.
• Another app runs 15 parallel Rector workers. The skip log's truncate flag was per-process, so every worker wiped the others' entries. Synthetic fixtures run single-process. This bug doesn't exist there.
• The same app runs Filament alongside Livewire. Five components use Filament's InteractsWithForms trait which defines its own validate(). Inserting the package's trait would have been a fatal collision on first render.
• A third app found that 5/7 of its Livewire files had dead #[Validate] attributes coexisting with explicit validate([...]) calls. Nobody anticipated that pattern.

Wrote up the full workflow, what worked, and when I'd use it (link in comments).