AnyCable: a Go realtime server that keeps Rails Action Cable semantics

The problem AnyCable solves for Rails teams

Action Cable runs inside the Rails process. Every open WebSocket holds a Ruby thread, and the memory that comes with it, so connection count and application throughput compete for the same resources. AnyCable separates the two. The Go server in this repository owns the sockets, and the Rails application only handles the messages that need application logic. The README describes the project as a realtime server for two-way reliable communication over WebSockets and SSE, and the repository layout backs that up: there are separate top-level directories for sse, hub, broker, pubsub, router, rpc and protocol.

The audience is narrow but real. You need a Ruby application that already uses Action Cable channels, and you need the connection layer to survive more concurrent clients than a single Rails process comfortably handles. If your realtime needs are a few hundred sockets on one dyno, the operational cost of a second service is probably not worth it. The value appears when connection count is the constraint rather than message volume.

How the Go server and the Ruby app divide the work

The split is the whole design. The Go binary accepts client connections, speaks the Action Cable protocol over WebSocket or SSE, and keeps a hub of active sessions. When a message needs application logic, the server forwards it over gRPC to a Ruby process, which runs the channel code you already wrote and returns what to broadcast. The go.mod file lists google.golang.org/grpc and github.com/fullstorydev/grpchan, and there is a protos directory plus a protocol package, which matches that description.

Broadcasts travel the other way through a broker. The Makefile checks whether port 6379 is listening and, if it is not, exports ANYCABLE_BROADCAST_ADAPTER=http; otherwise the Redis adapter is assumed. That single default tells you something important about deployment: the broadcast path is pluggable, and the HTTP adapter is the fallback when no Redis is reachable. The repository also carries nats, enats, redis, pubsub and broadcast directories, so the broker is a first-class extension point rather than a hardcoded dependency.

Two details are worth flagging. First, the server embeds mruby through github.com/mitchellh/go-mruby, vendored under vendorlib/go-mruby, and the Makefile gates it behind the mrb build tag with MRUBY_GO=false as the escape hatch. That means some message handling can run inside the Go process without a round trip to Ruby, which is a real latency argument, but it also means the build has an extra toolchain dependency unless you turn it off. Second, the repository contains a pusher directory and go.mod requires github.com/pusher/pusher-http-go/v5, so Pusher-protocol compatibility exists alongside the native protocol. The README does not explain that path; you have to go to docs.anycable.io.

Installing AnyCable and sending a first message

The README does not contain install steps. It points to docs.anycable.io for everything, and the repository itself is the server source. What the repository does show is the build. The Makefile defines OUTPUT ?= dist/anycable-go and builds with the mrb and gops tags by default, so a local build from a checkout looks like this:

MRUBY_GO=false make

Setting MRUBY_GO=false drops the mrb tag, which the Makefile comments describe as useful in environments without an mruby toolchain, for example the Dockerized dev environment. The binary lands at dist/anycable-go unless you override OUTPUT.

The Docker route is documented by the image reference in the README badge, anycable/anycable-go on Docker Hub. A container run needs at minimum an address to listen on and a way to reach your Ruby RPC server; the exact flag names are in the CLI package and in docs.anycable.io, and the README does not list them, so read the CLI help output of the binary you build rather than copying flags from a blog post.

On the Ruby side, the pairing is the anycable-rails gem, which is not in this repository. The README only says that all necessary information lives in the documentation. The practical first use is therefore: build or pull the Go server, start it pointed at your Rails app's RPC endpoint, then open one of your existing Action Cable channels from a browser and confirm the message arrives. If the channel works unchanged, the wiring is correct.

Where AnyCable stops being the right tool

The RPC hop is the main cost. Every message that needs application logic leaves the Go process, crosses gRPC to Ruby, and comes back. For chat, presence and notification fan-out that is fine. For a workload where nearly every inbound message triggers Ruby code, you have added a network round trip to a path that previously stayed in-process, and the Go server's connection advantage does not compensate for it.

There is also a hard boundary on language. The server is written in Go and the RPC contract is the integration point, but the ecosystem around it is Ruby-shaped: the README links the Pro and managed offerings, the repository ships a Gemfile, mrb, and a vendored mruby, and the documentation is organised around Rails. If your backend is not Ruby, nothing in this repository stops you from implementing the RPC side yourself, but you would be writing that layer without the documentation's main path. That is a real project, not a configuration change.

Operationally, you now run two things instead of one. The Makefile's Redis probe is a good illustration of how quietly this bites: if port 6379 is not listening, the build environment silently selects the HTTP broadcast adapter, and a deployment that assumed Redis may behave differently than the developer's machine. The README does not document rollback, so plan how you would return to Action Cable before you migrate, not after.

Finally, note the telemetry defaults. The Makefile exports ANYCABLE_DISABLE_TELEMETRY=true and points ANYCABLE_TELEMETRY_URL at http://localhost:4343 for local builds. Those are development defaults in the Makefile, not a statement about production behaviour, and the README says nothing about what is collected. Check the documentation before you assume either way.

AnyCable compared with Action Cable and other realtime servers

The natural comparison is Action Cable itself, which is the thing AnyCable replaces at the connection layer. Action Cable keeps sockets in the Rails process and uses Redis as its pub/sub backbone; AnyCable keeps sockets in Go and uses gRPC to reach Rails only when application logic is needed. The channel code stays the same, which is why the migration is mostly deployment work. The difference in approach is where the connection state lives, and that is what changes your scaling model.

Against a general realtime service such as Pusher, the difference is control versus operations. AnyCable is software you run, and the repository even ships a pusher directory and depends on pusher-http-go, so protocol compatibility with that ecosystem is part of the codebase. A hosted service removes the second process from your stack entirely. If your team does not want to operate a Go binary and its broker, the hosted route is the honest answer, and the README itself points to a managed offering.

Against writing your own Go WebSocket server, AnyCable's advantage is the protocol and the Ruby-side contract already being defined: the api, protocol, protos and rpc directories are that contract. You would be rebuilding those, plus the broker adapters for Redis and NATS that already exist here.

Maintenance, releases and licence

The last push to the default branch was on 2026-09-24, and v1.6.17 was released the same day. Before that, v1.6.16 landed on 2026-08-06 and v1.6.15 on 2026-06-29. The repository is not archived. That cadence, roughly a release every six to eight weeks through the middle of 2026, is the concrete signal to weigh rather than any claim about project health.

The upgrade cost sits in two places. The Go server is a binary you rebuild or re-pull, so the version bump is cheap; the Ruby gem and the RPC contract are the parts that can break, and the CHANGELOG.md at the repository root is where those notes live. Pin a version, read the changelog entry for it, and check the documentation's compatibility notes for your Rails version before upgrading. The repository also carries a .golangci.yml and a lefthook.yml, so the project enforces its own lint and hook rules for contributors, which matters if you plan to patch it.

The licence is MIT, per the README and the MIT-LICENSE file. MIT is permissive: you can use, modify and redistribute the code, including in closed products, provided the copyright notice and permission notice are preserved. That applies to this open source edition. The README distinguishes a Pro edition and a managed offering, and those are separate products with their own terms; the MIT grant in this repository does not automatically extend to them. For anything beyond that, read the actual licence text and the terms of the other offerings rather than relying on a summary.

Editorial conclusion

Adopt AnyCable when your Rails app already speaks Action Cable and the Ruby process is the bottleneck for open connections; the Go binary plus an RPC endpoint is a smaller change than rewriting your channels. Do not adopt it for a non-Ruby backend, or if you cannot run and monitor a second process, because the RPC layer is now part of your request path. Before rolling out, verify which broadcast adapter your deployment will use (the Makefile falls back to the HTTP adapter when nothing listens on 6379), confirm your Rails version against the compatibility notes in docs.anycable.io, and check the changelog for the release you pin, since v1.6.17 landed on 2026-09-24 and the 1.6 line has moved several times this year.

Frequently asked questions

Official sources

1. anycable/anycable on GitHub
2. License: MIT
3. Project website
4. README
5. Releases