I Got Tired of Paying $99/Month for Pusher, So I Built a Pusher-Compatible Alternative

Yurii donets — Sun, 04 Oct 2026 07:35:25 +0000

I've been using WebSockets in production applications for years.

For Laravel projects, the combination of Laravel Broadcasting, Echo, and Pusher-compatible infrastructure is incredibly convenient. You get realtime events without having to build the entire delivery layer yourself.

But eventually I ran into a problem that probably sounds familiar to anyone running several small or medium-sized projects:

the infrastructure bill started growing faster than the actual realtime workload justified.

At some point I found myself looking at a Pusher plan around $99/month and asking a fairly simple question:

Do I really need to pay this much for the amount of realtime traffic I'm actually using?

That question eventually turned into a project.

I built Donevia — a hosted, Pusher-compatible WebSocket service.

The goal isn't to invent another realtime protocol.

It's almost the opposite.

Why Pusher compatibility?

Pusher already has a mature ecosystem.

Laravel supports it extremely well. Laravel Echo works with it. There are existing client libraries for multiple platforms, and developers already understand the concepts of channels, events, private channels, and presence channels.

So replacing all of that with a completely new API didn't make much sense to me.

I wanted the migration path to look more like this:

keep your application → keep Laravel Echo → keep the Pusher protocol → change the infrastructure.

For a typical Laravel application, that means the application can continue broadcasting events normally while the WebSocket connection points to Donevia instead.

Conceptually, your Echo configuration still looks familiar:

window.Echo = new Echo({
    broadcaster: 'pusher',
    key: 'YOUR_APP_KEY',

    wsHost: 'your-websocket-host',
    wsPort: 6001,

    forceTLS: true,
    disableStats: true,
});

The important part is that the application shouldn't need to understand that the underlying provider changed.
That became one of the fundamental design decisions behind Donevia.
It quickly became more than running a WebSocket server
Running a Pusher-compatible WebSocket engine is the easy part.
Turning it into a SaaS is much more interesting.
Once I started building the surrounding platform, I needed:

customer accounts
multiple applications per account
application credentials
usage tracking
connection limits
message limits
plans
tenant isolation
billing infrastructure
an application console
metrics

And suddenly the project wasn't just "host a WebSocket server."

It became an infrastructure platform.

Accounts, applications, and tenants

One architectural decision I spent quite a bit of time on was deciding where limits should actually live.
I didn't want every application to behave like a completely separate subscription.
Instead, Donevia treats the customer account as the billing and quota boundary.
An account can have multiple applications:

Account
 ├── Application A
 ├── Application B
 └── Application C

Those applications share the resources available under the account's plan.
Internally, this is handled through a tenant layer.
The tenant isn't something customers need to manage as an "organization." It's primarily an infrastructure boundary used for quotas, billing, and isolation.
That lets the platform answer questions like:
How many concurrent connections are all applications belonging to this customer currently using?

rather than only:
How many connections does this particular application have?

For a SaaS platform, I think that distinction matters.
Usage accounting turned out to be surprisingly important
Another problem was defining what a "message" actually means.
WebSocket infrastructure produces several different kinds of activity.
There are API-triggered events.
There are messages delivered to connected clients.
There are messages received over WebSockets.
There are connections and disconnections.
There are transmitted and received bytes.
For Donevia, I eventually separated metrics such as:

new connections
disconnections
API messages
delivered messages
WebSocket messages received
WebSocket messages sent
socket bytes received
socket bytes transmitted
HTTP calls
HTTP traffic

This gives me much better visibility into what individual applications are actually doing.

More importantly, it gives me a foundation for pricing that is based on measurable resource usage instead of arbitrary limits.

Then came quotas

Metrics tell you what happened.

Quotas have to stop something from happening.
That's a much more sensitive problem.
If an account has a connection limit, all applications belonging to that account need to respect the same limit.
So the WebSocket layer needs to know which tenant owns an application and how much capacity that tenant has available.
For connection limits, I also chose a fail-closed approach.
If the quota system cannot reliably determine whether a new connection is allowed, it should not silently allow unlimited connections.
That's less convenient during infrastructure failures, but much safer for a multi-tenant service.

Load testing changed how I looked at the project

One thing I didn't want to do was launch an infrastructure product after testing it with ten browser tabs.
So I started load testing it.
First tens of connections.
Then hundreds.
Then thousands.
Eventually I pushed the test environment toward 200,000 concurrent WebSocket connections.
That doesn't mean I'm claiming Donevia can magically handle 200,000 production users on any random server.
Synthetic connection tests and real production traffic are very different things.
But the exercise was extremely useful.
It exposed bottlenecks, made connection accounting problems visible, and forced me to think seriously about the next stage:
horizontal scaling.
A single powerful server can take you surprisingly far.
But infrastructure SaaS eventually needs to survive the loss of a node and distribute traffic across multiple nodes.
That's the direction I'm working on now.

The hardest problem isn't WebSockets

After building most of this, I've realized something.
The hardest part probably isn't the protocol.
It's trust.
If you're building a todo app and it breaks for five minutes, that's annoying.
If you're providing realtime infrastructure and it breaks, potentially every application depending on you loses realtime communication.
Established providers have years of operational history behind them.
A new infrastructure provider doesn't.
So simply saying: "We're cheaper." isn't enough.

You need monitoring.
You need predictable limits.
You need redundancy.
You need transparent status information.
You need backups and recovery procedures.
And eventually you need enough operational history that developers are comfortable trusting you with production traffic.
That's the part of building Donevia that I find most interesting now.
So what is Donevia today?
Today, Donevia is a operational Pusher-compatible WebSocket platform with:

application management
Pusher-compatible credentials
Laravel / Echo compatibility
tenant-based architecture
connection quotas
usage tracking
realtime metrics
customer console
plan infrastructure

There is still plenty to build.

Horizontal scaling and high availability are particularly important next steps.

But the core platform is now far enough along that I want to start putting it in front of developers outside my own projects.

You can see the project here:

donevia.net

I'm particularly interested in feedback from developers already using Pusher, Ably, Soketi, Laravel Reverb, or another realtime stack.

If you were considering moving realtime infrastructure to a smaller provider, what would you need to see before trusting it with a production application?

Price?
Reliability numbers?
Multiple regions?
An SLA?
Open-source components?
A status page?
Something else?