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 custom usage packages and negotiated renewals at scale. 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

Verified 2026-10 against PubNub pricing: Free includes 200 MAU, Starter is $98/month with 1,000 MAU included, and Pro uses custom pricing. These plans include usage allowances; they are not concurrency/message tiers. The headline workload cannot determine a PubNub quote because peak concurrency, broadcasts, and fanout do not determine monthly active users.

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.

Compare your monthly users and actual usage

PubNub prices its plans around monthly active users (MAU): unique users active during a month, not the maximum number connected at once. Two applications with the same peak concurrency can have very different monthly user counts. Broadcast volume and fanout also cannot tell you how many distinct users were active.

The Free plan includes 200 MAU and development usage allowances. Starter costs $98/month with 1,000 MAU included and expanded production usage allowances. Pro has custom MAU packages and usage allowances; contact sales for a quote. Check PubNub's official pricing for current plan limits and your account terms rather than assuming unlimited usage or converting MAU into a connection quota.

Review your actual monthly users, enabled features, usage, and recent invoices. Compare those costs with Vask's published plans, including concurrent connection capacity and monthly broadcasts. Include the SDK rewrite and any PubNub-specific features you must rebuild. The sample workload above cannot produce a verified PubNub bill or savings estimate.

Vask webhooks are available now with Pusher-compatible payloads and signatures for supported events: channel occupied/vacated, cache misses, presence member added/removed, subscription count changes, and client events on private/presence channels. This does not imply parity with PubNub Functions or other provider-specific integrations.

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, compare the actual bill and rewrite effort before deciding. A simpler protocol surface can help, but savings depend on your users and usage.

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.