PubNub Alternative. Pusher Protocol. Cloudflare's Edge.

Vask is a Pusher-protocol-compatible WebSocket service, built on Cloudflare's edge in 330+ cities. If you are using PubNub for channels, broadcasts, and presence (the things most teams actually use PubNub for) Vask gives you that surface at startup prices with multi-region edge delivery built in. The migration is honest about itself: not a host swap, but a bounded SDK and event-mapping job that most teams complete in days, not weeks.

Why developers leave PubNub

PubNub is enterprise-shaped real-time infrastructure. It is well-built, well-supported, and priced for the segment it serves. The teams who leave are usually not using the whole surface. They picked it for live interactivity, then realized that their actual workload is simpler: publish to channels, subscribe from clients, and track presence.

The three patterns we hear:

1. The under-utilization audit. Finance asks engineering why the PubNub line item is $1,400 a month. Engineering opens the dashboard and finds that the workload is "publish to one of six channels, subscribe from a JS client, occasional presence event." That is the Pusher protocol's surface area, and there are several services that implement it at one tenth the cost.
2. The enterprise contract drag. PubNub's commercial motion involves enterprise sales conversations, custom MSAs, and yearly renewals negotiated against transaction projections that are usually wrong in one direction or the other. For teams whose revenue is growing past the published Starter tier but who are not yet running operationally-critical real-time workloads, the contract overhead is a tax on focus.
3. The feature-set ratchet. Once you adopt PubNub Functions or Access Manager, the cost of leaving rises because some logic now lives in their platform. Teams that catch themselves drifting toward this and stop early are the ones who find migrating tractable. Teams that stay long enough to embed business logic in Functions face a harder rewrite later.

The wedge for PubNub-leavers is not latency. PubNub's network is real. It is the bill, and the bill is structured for a different shape of buyer than the teams who feel it most acutely.

How Vask is different

Three pieces of mechanism, no marketing varnish.

The Pusher protocol, picked deliberately. The Pusher Channels protocol is the cleanest channel-based real-time protocol in wide use. Open, documented, and supported by SDKs in every major language. PubNub built its own protocol and SDK family from scratch, which is a reasonable bet in 2010 and a harder one to justify in 2026 when the protocol you want already exists and has a working ecosystem. We chose to implement the protocol rather than invent one. Your future migration story (toward us or away from us) is portable because the protocol is portable.

Cloudflare's edge instead of a larger proprietary platform. Connections terminate on Cloudflare's edge network. PubNub has its own global network; Vask's wedge is a smaller Pusher-protocol surface and a different bill shape, not a claim that PubNub lacks global infrastructure.

Startup-priced tiers, published openly. $10/mo entry tier (Side: 500 concurrent, 2M broadcasts). $20/mo Indie. $100/mo Business. No sales call, no MSA, no transaction projection negotiation. If you outgrow the tiers we publish, we will talk; in the meantime, the bill is on the website.

The receipts:

• Cloudflare-edge delivery in 330+ cities
• Pusher Channels protocol. Open, documented, portable to any future host that implements it
• Tier pricing published openly. Indie at $20/mo for 2K concurrent + 10M broadcasts/month
• Most teams ship the migration in days, not weeks. SDK swap is the main job
• Direct founder support on every paid tier

Side-by-side

The table renders from a dated competitor fixture, so the numbers reflect PubNub's published positioning as of the verification stamp. Enterprise tiers are quote-based and intentionally not reflected as a single line item.

What the migration looks like

This is the section where we are not pretending the migration is a host swap. PubNub is its own protocol and SDK family. Vask is the Pusher protocol. The work is bounded but real.

What changes:

• The client SDK. Replace PubNub's JS SDK with pusher-js (or laravel-echo for Laravel apps). Both expose a subscribe-to-channel, listen-to-event pattern, but the API shapes differ. Rename the import, rename the event-binding calls.
• The server publish layer. Replace PubNub's server SDK with pusher-http-php, pusher-http-ruby, pusher-http-python, or the equivalent for your stack. The publish call goes from pubnub.publish({channel, message}) to pusher.trigger(channel, event, payload). Event names become explicit; in PubNub they are typically implicit in the message body.
• Channel naming and auth. Pusher private channels (prefix private-) and presence channels (prefix presence-) replace PubNub's Access Manager rules for the same use cases. The channel auth callback pattern is well-documented and most apps wire it up in an hour.
• Presence semantics. Both services support presence. Vask's presence is via the Pusher protocol's presence-* channel with member join/leave events. Map the events; the semantic shape is close.

What does not change:

• Your business logic in the application server. The channel publish becomes a different method call, but the conditions under which you publish (a user did X, an event Y happened) are app code, not infrastructure code.
• Your application's data model around real-time. Channels-and-subscribers-and-presence is a universal pattern; the names of the methods change, the shape of the architecture does not.

Index: app/Broadcasting.php
===================================================================
--- app/Broadcasting.php
+++ app/Broadcasting.php
@@ -1,8 +1,5 @@
-use PubNub\PubNub;
-use PubNub\PNConfiguration;
+use Illuminate\Support\Facades\Broadcast;
 
-$pnConfig = new PNConfiguration();
-$pnConfig->setPublishKey(env('PUBNUB_PUBLISH_KEY'));
-$pnConfig->setSubscribeKey(env('PUBNUB_SUBSCRIBE_KEY'));
-$pubnub = new PubNub($pnConfig);
-$pubnub->publish()->channel('orders')->message($payload)->sync();
+// Vask drop-in via Laravel broadcasting
+Broadcast::channel('orders', fn () => true);
+broadcast(new OrderCreated($payload))->toOthers();

A realistic timeline for most teams: a week to plan the protocol mapping and rewrite the SDK calls, a week to run both endpoints in parallel via a feature flag and verify behavior on a portion of production traffic, then a cutover when confidence is there. Larger codebases with PubNub-specific features outside the channel-broadcast-presence surface take longer in proportion to those features.

If the migration runs into an edge case in your stack, email [email protected] and you will get an answer from someone who can read your diff.

Run the numbers on your own bill

The frame above is the argument. The number is what closes it. Plug in your concurrent users, your broadcasts per minute, and the average subscribers per channel, and the calculator will show you what each pricing model produces on your specific traffic shape.

If you want a written breakdown for your team or your finance lead, the calculator will email you a formatted report keyed to your inputs.

When NOT to switch

Honesty is load-bearing on alternatives pages. The cases where we would tell you to stay on PubNub:

• You are using PubNub Functions as a serverless layer. Functions is a real product surface and Vask does not have an equivalent. If meaningful business logic runs inside PubNub Functions, the rewrite is not bounded by SDK swap; it is bounded by reimplementing serverless functions in your own stack or another provider. That can still be the right call, but go in with eyes open about scope.
• You depend on PubNub Access Manager for fine-grained authorization. Pusher protocol's private and presence channels cover most authorization needs, with a callback on your application server. If your auth model is built around PubNub's per-grant Access Manager rules, the migration involves rebuilding that logic on your application server, which is feasible but is its own project.
• You use PubNub Files, Mobile Push, or Storage as load-bearing parts of the stack. These are not parts of the Pusher Channels protocol surface and Vask does not provide them. Solve them separately if you want to migrate channels-only.
• Your enterprise contract includes commitments Vask cannot match. Custom SLAs beyond 99.99%, specific compliance certifications, 24/7 phone support on contract. We support paid tiers with direct founder responsiveness, which is enough for most teams and is not the right thing for some.
• You are below the PubNub free tier and paying nothing. Stay where you are until you have a bill. Switching to save money you are not spending is wasted migration time.

If none of those apply, the math and the architecture story work in your favor. The audit usually surprises the team that runs it.

Get going

Edge-native channels and broadcasts on a protocol your future team will recognize. No enterprise contract to negotiate, no Functions to depend on, no per-grant authorization rules to map. Three pieces of mechanism, published prices, founder-built.