Soketi

Self-hosted real-time infrastructure, honestly reviewed. No marketing fluff, just what you get when you run your own WebSocket server.

TL;DR

• What it is: Open-source (AGPL-3.0), self-hosted WebSocket server that speaks Pusher’s protocol — meaning your existing Pusher SDK code connects to it with a host swap and credential change [1].
• Who it’s for: Developers and technical founders running Laravel, Next.js, or any Pusher-SDK-based app who are tired of paying Pusher’s per-connection and per-message limits [1][2].
• Cost savings: Pusher’s paid plans start at $49/mo for 500 concurrent connections and 30 million messages. Soketi on a $5–10/mo VPS handles thousands of connections with high traffic on under 1 GB RAM and 1 CPU [1].
• Key strength: Pusher Protocol v7 compatibility means near-zero migration effort. Swap the host, swap the credentials, done [1].
• Key weakness: The project’s own README openly warns that maintenance has been infrequent and updates have slowed [1]. This is the honest concern with Soketi in 2026 — the software works, but the project is not actively developed at pace.

---

What is Soketi

Soketi is a Node.js WebSocket server that implements the Pusher Protocol v7 [1]. It runs on your infrastructure, speaks the same wire protocol as Pusher Channels, and is a drop-in replacement for the hosted Pusher service at the SDK level — whether you’re using the JavaScript Pusher client, Laravel Echo, or any other Pusher-compatible library.

The core engine is built on uWebSockets.js, a C application compiled to Node.js. The project claims performance of 8.5x that of Fastify and at least 10x that of Socket.IO [1]. In practice, this means Soketi is not the bottleneck in your stack — your database is.

As of this review it sits at 5,563 GitHub stars [1]. The AGPL-3.0 license is worth understanding before you deploy: you can self-host freely, but if you distribute modified versions as a network service (e.g., build a Soketi-as-a-service product), you must open-source your modifications. For the target audience — a founder self-hosting for their own app — this doesn’t matter. For someone building a hosted product on top of Soketi, it does.

---

Why people choose it over Pusher (and Ably)

The pitch is simple and it holds up: Pusher charges you for connections and messages. At any meaningful scale, those numbers hurt.

Versus Pusher. Pusher’s Starter plan ($49/month) caps you at 500 concurrent connections and 30 million messages per month [1]. For a product with real-time features — chat, notifications, live dashboards, collaborative editing — you can hit 500 concurrent connections at a few hundred active users depending on session length. The math gets punishing fast: 1,000 connections puts you on the $99/mo plan, 5,000 on the $299/mo plan, and the numbers keep climbing. Meanwhile, Soketi on a single $6 Hetzner VPS handles thousands of connections on less than 1 GB RAM. Same protocol. Zero per-message fees.

Versus Ably. Ably is arguably a more mature hosted service with better global infrastructure and a more sophisticated feature set (history, message ordering guarantees, presence at scale). But you’re paying for that — Ably’s free tier is limited, and production use costs money. Soketi doesn’t compete on features with Ably’s enterprise offering. It competes on cost for the 90% of use cases that don’t need Ably’s edge cases.

The Pusher compatibility angle is the real selling point. Most WebSocket alternatives require you to rewrite your client and server code — different event model, different channel concept, different auth flow. Soketi requires changing a config value [1]. For a team already running Pusher, that’s not a migration; it’s a 15-minute deployment exercise.

---

Features

Based on the README and project documentation:

Core WebSocket engine:

• Pusher Protocol v7 implementation — compatible with all Pusher SDKs [1]
• Built on uWebSockets.js for C-level socket performance [1]
• Private channels, presence channels, encrypted channels [1]
• App-based access — you define multiple apps (each with a key/secret pair), mirroring Pusher’s multi-tenant model [1]

Scaling and storage backends:

• Single-instance mode (in-memory) for development and small deployments
• Redis adapter for horizontal scaling across multiple Soketi instances [1]
• App storage via static arrays (JSON config), DynamoDB, PostgreSQL, MySQL — choose what fits your stack [1][2]
• MongoDB support for app configuration storage [1]

Observability:

• Built-in Prometheus metrics endpoint — scrape and graph without third-party agent [1]
• Metrics cover active connections, messages per second, channel counts, and more [1]

Deployment options:

• Docker image (official)
• npm package (@soketi/soketi) for direct Node.js installation [1]
• Helm chart on Artifact Hub for Kubernetes [1]
• One-click deploy examples for Railway [1]
• Cleavr integration for VPS deployment [1]

Community tools:

• Soketi UI — a separate community project for managing apps via a browser interface [1]
• Soketi App Manager for Filament — if you’re in the Laravel/Filament ecosystem [1]

What it doesn’t do:

• No built-in message history or playback — if a client reconnects, it doesn’t get missed messages (Pusher’s Channels history feature, Ably’s message replay). You handle this at the application layer.
• No built-in push notifications — this is WebSockets, not mobile push.
• No built-in connection geography / global edge network — your latency is your VPS location.

---

Pricing: SaaS vs self-hosted math

Pusher Channels pricing (for comparison):

• Sandbox: free, 100 max connections, 200K daily messages
• Starter: $49/mo — 500 max connections, 30M messages/month
• Pro: $99/mo — 1,000 max connections
• Business: $299/mo — 5,000 max connections
• Beyond that: custom enterprise pricing

Ably pricing (for comparison):

• Free: 200 concurrent connections, 6M messages/month
• Production plans start at $29/mo and scale up; pricing gets opaque fast at scale

Soketi self-hosted:

• Software: $0 (AGPL-3.0 license) [1]
• VPS to run it: $5–10/mo on Hetzner, Vultr, or DigitalOcean [1]
• Redis (if scaling horizontally): another $5–15/mo for a managed Redis, or run it on the same instance

Concrete math for a typical case:

Say you’re building a real-time SaaS with a notifications feed and a live dashboard. You’re running 300–600 concurrent connections at peak, generating around 15M messages/month. On Pusher, you’re comfortably on the $49–99/mo Starter or Pro plan. On a self-hosted Soketi instance on a 2-vCPU, 4 GB RAM VPS ($12/mo on Hetzner), the same load runs with headroom to spare [1]. Annual savings: roughly $450–$1,000/year for a real-world small product. That number grows fast as your user count grows — Pusher’s pricing scales with you in a way that your VPS bill largely doesn’t.

The honest caveat: you’re trading money for operational responsibility. Pusher handles uptime, scaling, and incident response. Self-hosted Soketi means you’re on call.

---

Deployment reality check

Soketi is a Node.js process. The install path is either npm install -g @soketi/soketi or Docker. It’s not complex software to run.

What you actually need for a basic single-instance setup:

• Any Linux VPS with 1 GB RAM minimum (1 GB handles a substantial number of connections)
• Node.js 18+ or Docker
• A domain and reverse proxy (nginx or Caddy) for TLS termination
• Environment variables for app configuration (or a JSON config file for static apps)

What you need for production at scale:

• Redis for the pub/sub adapter (required when running multiple Soketi instances behind a load balancer)
• A PostgreSQL or MySQL database if you want dynamic app management instead of static JSON config
• A load balancer in front of multiple Soketi instances for horizontal scaling

What can go sideways:

The most honest signal in the Soketi README is this sentence: “Recently, there were issues with the maintenance and this caused infrequent updates, as well as infrequent support.” [1] The maintainer has put this in the README itself, which is admirable for transparency and important for anyone evaluating Soketi for a production stack.

Concretely, what this means:

• Open issues may sit unresolved for months
• Security patches may lag
• New Pusher protocol features won’t be added quickly
• Community support channels (Discord) may be slow

The last commit dates and release cadence are not available in the data provided, but the README’s own warning should set expectations. This is not a red flag for using Soketi — the Pusher protocol is stable and doesn’t change often. It is a flag for anyone who needs active maintenance, rapid bug fixes, or a roadmap.

Realistic setup time for a developer: 30–45 minutes from zero to a working Soketi instance on a VPS. For a non-technical founder without server experience: this is not the tool to set up yourself. You need someone to do the initial deployment.

---

Pros and Cons

Pros

• Pusher Protocol v7 compatibility. The migration from Pusher to Soketi is a credential swap, not a rewrite. No new SDK to learn, no client-side changes [1].
• Serious performance. uWebSockets.js delivers C-level socket performance. Thousands of concurrent connections on a $6 VPS is not marketing — the underlying library benchmarks are documented [1].
• Cheap at scale. Pusher’s per-connection pricing breaks most indie and early-stage budgets. Soketi’s cost scales with your VPS size, not your user count [1].
• Built-in Prometheus monitoring. You don’t need a separate monitoring agent to get metrics. Scrape the endpoint, plug into Grafana, done [1].
• Multiple storage backends. Static JSON for simple setups, PostgreSQL for production, DynamoDB for AWS shops — the app management layer is flexible [1].
• Horizontal scaling with Redis. Redis adapter means you can run multiple instances behind a load balancer without message routing problems [1].
• Ecosystem tooling exists. Community-built Soketi UI and Filament integration mean you’re not stuck with raw config files [1].

Cons

• Acknowledged maintenance slowdown. The maintainer documents this in the README. If you need a project with active development and timely security patches, this matters [1].
• AGPL-3.0 license, not MIT. Not a problem for self-hosting your own app. A problem if you’re building a service product on top of Soketi [1].
• No message history or replay. Clients that disconnect and reconnect miss messages. You implement recovery logic yourself or don’t offer that feature.
• No global edge network. Your latency is determined by your VPS location. Users on the other side of the planet from your server get worse real-time performance.
• No GUI by default. App management is config-file or database-driven. The community Soketi UI exists but isn’t officially maintained.
• 5,563 stars — decent, not dominant. For comparison, Socket.IO has 60K+ stars. Soketi is a real project with real adoption, but it’s not the WebSocket reference implementation [1].

---

Who should use this / who shouldn’t

Use Soketi if:

• You’re running a Laravel or Next.js app that already uses Pusher and your monthly Pusher bill has crossed $49.
• You have a developer (or are a developer) comfortable with a basic Linux VPS and Docker.
• Your real-time requirements are standard: presence channels, private channels, event broadcasting. No exotic message history or delivery guarantees.
• You want to own your WebSocket infrastructure and eliminate a recurring SaaS dependency.

Skip it (use Pusher or Ably) if:

• You need enterprise-grade global infrastructure with SLAs, compliance certifications, and 24/7 vendor support.
• You’re in a regulated industry where infrastructure responsibility matters to your compliance team.
• You need built-in message history and replay — Ably’s differentiator is strong here.
• You have no technical person to handle server setup and ops. Soketi is self-hosted infrastructure; it needs someone to run it.

Skip it (look at Centrifugo) if:

• You’re concerned about the maintenance cadence and want an actively developed open-source alternative. Centrifugo is a more actively maintained Go-based WebSocket server with a larger feature set. It doesn’t speak Pusher protocol natively (it has its own protocol), so migration is more involved, but the project is substantially more active.

Skip it (use Laravel Reverb) if:

• Your stack is Laravel. Laravel 11+ ships with Reverb — an official, first-party WebSocket server built and maintained by the Laravel team. It’s Pusher-compatible, integrates directly with Laravel’s broadcasting layer, and eliminates the operational question of “is this project maintained?” For Laravel apps, Reverb is now the obvious answer.

---

Alternatives worth considering

• Pusher Channels — the managed service Soketi replaces. Best-in-class developer experience, global infrastructure, $49/mo starting price. The obvious choice if ops simplicity matters more than cost.
• Ably — more sophisticated than Pusher (message history, ordering guarantees, better global network). Price scales with usage. A step up from Pusher for complex requirements.
• Centrifugo — Go-based open-source WebSocket server. More actively maintained than Soketi, broader feature set, but uses its own protocol (migration from Pusher requires more work). Worth serious consideration for new projects.
• Laravel Reverb — if you’re on Laravel, this is the official answer. First-party, Pusher-compatible, actively developed by the Laravel core team.
• Socket.IO — the classic Node.js WebSocket library with a server component. Larger ecosystem, different protocol (not Pusher-compatible), higher overhead than uWebSockets.js.
• Liveblocks — hosted collaborative infrastructure, not raw WebSockets. Different abstraction level — better for collaborative editing features, not general-purpose pub/sub.

---

Bottom line

Soketi solves one problem cleanly: it lets you escape Pusher’s per-connection pricing with minimal code changes. The Pusher protocol compatibility is the entire value proposition, and it delivers on it — the same SDK, the same event model, a config swap. The underlying performance (uWebSockets.js) is legitimate. The cost math ($6 VPS vs $49–299/mo on Pusher) is real.

The honest concern in 2026 is the maintenance trajectory — the project’s own README flags infrequent updates, and if you’re a Laravel developer, Laravel Reverb now exists as a first-party alternative maintained by a team with clear long-term commitment. For non-Laravel stacks on a budget, Soketi still makes sense if you accept that you’re running stable but not actively-evolved software.

If the deployment and ops overhead is the barrier, that’s what upready.dev handles — one-time deployment, you own the infrastructure, the SaaS bill goes away.

---

Sources

1. Soketi GitHub Repository and README — github.com/soketi/soketi (5,563 stars, AGPL-3.0 license). https://github.com/soketi/soketi
2. Soketi Official Website — soketi.app — product description, feature overview, deployment guides. https://soketi.app
3. Soketi Documentation — installation, environment variables, app management. https://docs.soketi.app

Primary source note: The third-party review articles retrieved for this tool contained no Soketi-related content (scrape returned off-topic pages). This review is based on the official README, GitHub profile data, and official website. Claims are sourced to primary documentation; no third-party review synthesis was possible for this edition.