Introducing WebSockets for Laravel Cloud, Powered by Laravel Reverb

Introducing WebSockets for Laravel Cloud, Powered by Laravel Reverb

We just shipped WebSockets for Laravel Cloud, the easiest way to add real-time features to your application.

WebSockets for Laravel Cloud are managed WebSocket clusters powered by Laravel Reverb. This means you can add real-time communication to your applications in just 10 seconds, and for up to 50% less than other third-party tools.

Simply pick the number of concurrent connections when setting up your cluster. Got multiple apps? Split your connections among different applications for greater cost efficiency. It's that easy.

Sign up for Laravel Cloud to add Laravel Reverb-powered WebSocket clusters to your apps in 10 seconds.

The Power of Laravel Reverb, Now Fully Managed

Real-time features are crucial for activation, retention, and engagement in an application. When users interface with a live chat, instant notifications, or real-time dashboards, the magic of "now" is undeniable.

However, building, scaling, and managing the underlying WebSocket infrastructure is anything but magical. It's painful, time-consuming, and complicated, and it takes precious time away from building features.

The Laravel community has come to know and love Laravel Reverb, the open-source, high-performance WebSocket server we released almost two years back. Reverb quickly became the go-to for Laravel developers implementing real-time features.

But since Reverb is an OSS package, hosting and scaling it still required managing servers or relying on separate third-party services.

Since the release of Laravel Cloud earlier this year, support for managed Reverb has become the single most requested feature from our Cloud customers, to the tune of countless "What's the ETA for Reverb in Cloud?", "Do you support Reverb?", and, my personal favorite, "Reverb when?".

Well, with WebSockets for Laravel Cloud, a fully managed Reverb cluster that is natively integrated into your Laravel Cloud experience, the answer is: Reverb now.

Simple Setup, Simple Scaling

In the spirit of Laravel Cloud's "it just works" ethos, we've made the experience of creating WebSockets clusters as simple as possible.

When you set up your cluster, you pick the number of concurrent connections it should be able to handle. This capacity can then be split into multiple applications, each sharing a portion of those connections for cost-effective resource management.

As soon as you add a WebSocket application to your Laravel environment, Cloud automatically populates all necessary environment variables. You don't have to look up keys or configure endpoints. You don't have to handle third-party vendors or separate billing.

It just works.

See WebSockets for Laravel Cloud in action, and check the code we used to build our demo app on GitHub.

Predictable Pricing

Simplicity isn't just about a beautiful UI, populating variables, and hands-off deployments.

It's also about making pricing predictable and easy to understand. We've kept the pricing for our Laravel Reverb-powered WebSocket clusters incredibly simple:

  • You just pay for your maximum concurrent connections.
  • Each concurrent connections tier includes a generous allowance of millions of messages.
  • That's it.

No complex equation, no extra base plan, no cost-per-million-messages/minutes/channels confusion.

This simple, predictable model is designed to provide an incredibly low barrier to entry. In fact, our solution is up to 50% cheaper than some of our leading competitors. We want you to focus on building, not calculating costs.

Get Started with WebSockets for Laravel Cloud

WebSockets for Laravel Cloud frees you from handrolling another service or the hassle of third-party vendors and instead unifies another piece of your application architecture within Laravel Cloud.

It's a step closer to our mission of enabling developers to move to production quickly, eliminate infrastructure management, and enjoy the best developer experience along the way.

We build for developers who ship. Start integrating WebSockets for Laravel Cloud into your projects today.

Want to learn more?

Keep reading

Laravel Cloud February 20, 2026

Laravel Cloud Incident Report: February 20, 2026

## Summary On February 20, 2026, Laravel Cloud experienced a connectivity outage lasting approximately 3 hours and 15 minutes. The disruption was caused by an [incident at Cloudflare](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/), one of our infrastructure partners, which resulted in the withdrawal of IP prefix advertisements that route traffic to Laravel Cloud services. During this time, customers were unable to reach the Laravel Cloud control panel or some of their applications hosted on Laravel Cloud. No customer data was lost or compromised, and no deployments in progress were affected. The issue was entirely network-level — applications and their underlying infrastructure remained healthy throughout. While redundancy generally exists throughout our infrastructure, we have not yet extended that same protection to our IP announcement layer. Closing that gap is now a top engineering priority. Our goal is to implement additional failover protection so that no single upstream dependency can cause a prolonged outage for our customers. ## Timeline (UTC) | Time | Event | |------|-------| | **18:42** | Laravel Cloud monitoring detects connectivity failures. Incident declared and response team assembled immediately. | | **18:45** | Cloudflare begins investigating issues with their services and network. | | **18:48** | Laravel Cloud status page updated and notification posted to Twitter/X. | | **19:09** | Cloudflare identifies impact to a subset of BYOIP (Bring Your Own IP) prefixes. Reports the underlying issue as mitigated and begins working to restore affected advertisements. | | **~19:40** | Laravel Cloud attempts to re-advertise prefixes via the Cloudflare dashboard. The option is unavailable — prefixes are locked in a "Withdrawn" state requiring Cloudflare to unlock. We communicate this to Cloudflare via our shared support channel. | | **20:50** | Cloudflare acknowledges that some customers are unable to re-advertise their prefixes through the dashboard and begins working on a fix. | | **21:57** | Full connectivity to Laravel Cloud is restored as Cloudflare completes prefix restoration. | **Total duration of impact: approximately 3 hours and 15 minutes.** ## What Happened Laravel Cloud uses Cloudflare for network services including IP prefix management via their BYOIP (Bring Your Own IP) product. On February 20, Cloudflare experienced an incident that caused IP prefix advertisements to be withdrawn for a subset of their customers, including Laravel Cloud. When IP prefixes are withdrawn from BGP, traffic can no longer be routed to the affected services. This meant that while Laravel Cloud's applications, databases, and infrastructure were fully operational, users could not reach them because the network path no longer existed. Cloudflare identified the underlying cause and advised customers to re-advertise their prefixes manually through the Cloudflare dashboard. However, Laravel Cloud's prefixes were locked in a "Withdrawn" state that required Cloudflare's intervention to unlock. This meant the suggested self-mitigation path was not available to us, and recovery was dependent on Cloudflare restoring the prefixes on their end. ## What Was Affected - **Connectivity to Laravel Cloud applications** — users could not reach their apps - **Laravel Cloud dashboard and API** — inaccessible during the outage - **Deployments** — new deployments could not be initiated ## What Was Not Affected - **Customer data** — all data remained intact and secure - **Running applications** — apps continued to run normally; they were simply unreachable - **Databases and caches** — no data loss or corruption ## Our Response Our monitoring detected the issue within minutes, before Cloudflare's own status page reflected the incident. We immediately declared an incident, assembled our response team, and updated our status page and social channels to keep customers informed. Once Cloudflare published their self-mitigation guidance, we attempted to follow it but were unable to do so due to the prefix locking issue described above. We escalated directly with Cloudflare's team and continued to monitor and communicate throughout the incident. ## Looking Forward Laravel acknowledges that single points of failure in our infrastructure can disproportionately introduce risk in our ability to manage availability of the applications we serve. We are exploring strategies to decouple and introduce redundancy in our key networking layers to create better resiliency from underlying components. We take the reliability of Laravel Cloud seriously, and we understand the impact this outage had on our customers and their users. We are committed to learning from this incident and building a more resilient platform.

Laravel Team