Any Cables #33: Durable at Once
January – February 2026
The word “durable” keeps showing up. Durable Streams, DurableAgent, durable sessions. After years of treating realtime as fire-and-forget, the ecosystem is converging on the idea that messages should survive disconnects. Here’s what happened in January and February.
Highlights
AnyCable 1.6.9: Durable Streams support
The headliner: AnyCable now speaks Durable Streams—an open HTTP protocol for reliable, resumable data streaming from ElectricSQL.
We announced the gradual adoption of the protocol in the AnyCable, Rails, and the pitfalls of LLM-streaming post back in December. Well, “gradual” happened faster than expected—with AnyCable v1.6.9, the read side is done. Your clients can now consume AnyCable streams using any Durable Streams-compatible client. You still publish via the AnyCable API (broadcasting), but on the read side, it’s an open standard. No vendor lock-in, no proprietary protocol required.
Other highlights from the release:
New REST API for publishing broadcasts and querying presence from any HTTP client—no SDK required (docs)
Pusher Get Channel Users API to simplify the migration to AnyCable (docs).
News
An update on The end of Heroku
Sad (but kinda expected) news: Heroku is turning on maintenance mode (read: “we’re gradually sunsetting our operations”). If you’re using it and have been expecting to rely on it in the mid- to long-term, you need to start looking for alternatives.
Today, there are plenty of PaaS platforms offering a Heroku-like experience (I’m pretty sure we’ll continue using this term even when Heroku is no more). Self-hosting is also not rocket science anymore; the variety ranges from Kamal to Kubernetes kits.
We decided to check the distribution of deployment platforms among AnyCable users (based on the anonymized telemetry we collect) and got the following results:
Out of the identified platforms (you see the “None” at the bottom—it’s everything from self-hosted and local runs to k8s clusters), Heroku is 2nd, with ECS/Fargate as the leader. Not suggesting anything, just sharing our data. (But you need help in picking and implementing the escape strategy, Evil Martians are here to help.)
Durable Streams on Electric Cloud
Since we covered the original announcement in #32, ElectricSQL shipped fast: from v0.1.0 (NPM) on Dec 23 to the hosted cloud along with v0.2.0 on Jan 22. The new version also comes with the Idempotent Producer specification—don’t even try to publish your message twice! We, Team AnyCable, are glad to be in the company of early adopters of this new, exciting technology. Are you durable streaming yet?
Valkey 9.0: innovation, features, and improvements
The announcement is not fresh, but we decided that it deserves more attention. Why? First of all, Valkey has finally caught up on the Redis features released in 7.4 (right after the change in the Redis licensing policy, and thus not available to other cloud providers). For example, the family of Hash field expiration commands (HEXPIRE et al) is now supported, making Valkey compatible with AnyCable Presence implementation.
Videos
Real-time Collaboration with Rails, AnyCable and Yjs (JP Camara @ SF Ruby Conference)
All 32 talks from SF Ruby Conference 2025 are published on sfruby.com/talks. Check them all out!
Posts
Can you imagine running a Rails app on V8 (JS runtime) for serverless sake? No need to imagine, Sam Ruby is already bringing this to life. Realtime-wise, check out the chat demo: Action Cable backed by Broadcast Channel (do you remember we shared the same idea when talked about Rails on Wasm in #23).
Releases
We’ve already mentioned Durable Streams and REST API additions. Another noticeable addition is a mTLS support for Redis (or Valkey).
We changed the way the server is configured when running the php artisan anycable:server command to use Laravel configuration. (Thanks for the feedback from our AnyCable Laravel early adopters!).
Loro is a Y.js alternative built in Rust by an independent team. Loro produces cleaner merges thanks to the Fugue algorithm. It also keeps full editing history by default—you get Git-like time travel without bolting on extra storage. Bindings exist for JS/WASM, Swift, Python, and React Native, plus ProseMirror and CodeMirror integrations.
The release notes are read as a year-end recap: v6, async consumers, server-side publication filtering, WebSocket over HTTP/2, C# SDK, 7k+ installations.
Livewire 4 makes building reactive web applications (in PHP) with no JavaScript even simpler: now, you can mix PHP, view templates, styles and JavaScript (“no” doesn’t mean “never”) in a single file! (I have strong MXML vibes 😁.)
Frame of curiosity: Who’s next? Pusher?
Heroku has become synonymous with the “git push” deployment experience. It’s been the default for Ruby on Rails applications for years. And now what? It’s over.
What other PaaS services will repeat the fate of Heroku? Who pioneered a field, set the standard, and is now struggling to compete in a new world full of other vendors and viable open-source alternatives? The first project that comes to mind is Pusher.
For years, Pusher has been the default answer to “how do I add realtime to my app?” Easy to start, SDKs everywhere, it Just Works™. While everyone was afraid of self-hosting WebSockets, Pusher offered an easy way out. Don’t underestimate the power of irrational fear: even though open-source reverse-engineered alternatives have been known for almost as long as Pusher exists, they were barely used outside of local setups and experimental projects (I remember suggesting switching to Poxa, an Elixir-driven OSS alternative, back in 2016—that was a hard sale, we failed).
Pusher’s protocol became a de facto standard. Laravel built its entire Broadcasting layer around it. Countless apps speak Pusher protocol without thinking twice. Well, until the invoice arrives. Or you need delivery guarantees. Or you want your data on your infrastructure.
The demand for real-time features in 2026 is not the same as in 2016 (no, I don’t want my 2016 back; I live today). The supply has changed too: more PaaS options arrived, popular frameworks got built-in real-time engines (Action Cable in Rails, Reverb in Laravel), new protocols emerged to satisfy new needs (yes, I’m talking about Durable Streams, again). And Pusher stays basically the same, not from the features they offer but from the way developers use it.
We’ve seen many applications using Pusher, many developers unsatisfied with its features and limitations, and managers unsatisfied with the bills. That triggered our decision to support the Pusher interface in AnyCable. The goal is not to lure the clients but to provide a smooth migration path towards better realtime UX.
Today, switching your application from Pusher (PaaS) to AnyCable is just a matter of configuration. This is the first phase. After finishing the infrastructure migration, you can gradually migrate to other protocols better suited to your needs: whether it’s server-sent events, or durable streams, or reliable WebSockets backed by the AnyCable protocol—the choice is yours and yours only.
The future of realtime web must be reliable and affordable. Be a part of it and don’t let the next “An update on …” post take you by surprise.