# anycable-rails: swapping Action Cable for the AnyCable server > The anycable-rails gem lets a Rails application use AnyCable, a separate language-agnostic realtime server, in place of Action Cable, over WebSockets or server-sent events. The repository is the SDK half of that arrangement, and its two gems, its setup generator and its strict linting setup are the parts you touch. **anycable/anycable-rails** — AnyCable for Ruby on Rails applications - Repository: https://github.com/anycable/anycable-rails - Website: https://anycable.io - Stars: 535 · Forks: 36 - Language: Ruby - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/anycable-anycable-rails ## Two projects, and this repository is the Rails side of one of them AnyCable is an open-source, language-agnostic realtime server for reliable two-way communication over WebSockets and SSE. The README points at a separate repository for the server itself, and this repository contains the code for the AnyCable Rails SDK, which allows you to use AnyCable as a drop-in replacement for Action Cable. That split is the whole architecture, and it is worth being precise about. Action Cable is a component that lives inside your Rails application, with its own pub-sub adapter, its own server, its own connection handling and its own scaling story. AnyCable moves that out into a standalone server that your Rails application talks to. The SDK is what makes that swap invisible to the rest of your code. The language-agnostic part matters more than it sounds. Because the server is not Ruby, you are not forced into the Ruby concurrency model for the broadcast path, and the protocol is available to applications that are not Rails at all. The Rails SDK is one client of that server. Two transports are supported, WebSockets and server-sent events, and offering both is a real design choice rather than a feature list. WebSockets is bidirectional and is the usual choice. Server-sent events is unidirectional from the server, which means it works through proxies and load balancers that are hostile to long-lived upgrade connections, and it is the pragmatic answer for a broadcast-only channel. Whether the Rails SDK covers both paths is something the documentation covers rather than the README. The project is MIT licensed, the homepage is anycable.io, the documentation is at docs.anycable.io/rails/getting_started, and there is a separate example Rails application linked as a demo. The last push was on 2026-07-16, the repository is not archived, and the recent releases are 1.6.1 on 2025-12-22, 1.6.0 on 2025-02-04 and 1.5.0 on 2024-04-02. ## The quick start, and what the setup generator does to your app The installation is a Gemfile entry and a generator, and the second step is where the real work happens. The gem goes into the Gemfile: ```ruby gem "anycable-rails" ``` Then the interactive setup command: ```sh bundle exec rails g anycable:setup ``` An interactive generator is a meaningful design decision. A realtime swap touches several places in a Rails application at once: the cable configuration, the allowed request origins, the mount point for the JavaScript client, and the JavaScript bundle that the application serves. Doing all of that by hand from a blog post is exactly the kind of task that goes subtly wrong, and a generator that walks the user through it is the reasonable answer. What the generator writes is not described in the visible part of the README, and that is a limitation of the documentation rather than of the tool. The Rails documentation site is the place to find out which files are touched and what the cable configuration ends up looking like, and anyone evaluating this should read that page before running the generator on a project with an existing Action Cable setup, because a generator that edits configuration is the last thing you want to run blind. The word drop-in deserves the same scrutiny. It is a claim about the Action Cable API surface, and the practical questions are the ones the documentation should answer: which Action Cable features are covered, which are not, and what happens to the adapter you already configured. An application that uses a custom channel, a custom adapter or an unusual connection setup is exactly where a drop-in claim is either true or not. The example Rails application linked from the README is the fastest way to see the result of the setup command, and it is linked as a demo for that reason. ## Two gems, a rubocop plugin and a strict lint setup The repository layout is more revealing than the README, and it shows a project with more than one audience. There are two gemspecs for the runtime, anycable-rails-core.gemspec and anycable-rails.gemspec, plus a third, rubocop-anycable-rails.gemspec, which is a custom RuboCop plugin. So the project ships not just the SDK but also linting rules for applications that use it, which is a sensible thing to provide since the SDK introduces configuration that a project might otherwise get wrong in a way RuboCop could catch. The release process confirms the two-gem structure. The Makefile default target is release, and the release target releases anycable-rails-core first, then anycable-rails with the -t flag, then pushes to git and pushes the tags: ```make all: release release: gem release anycable-rails-core gem release anycable-rails -t git push git push --tags ``` The -t flag on the second release most likely tags the release in git, which matches the git push --tags that follows. The core and the full gem split suggests the full gem is a superset, probably pulling in the Rails integration and the JavaScript client while the core is the part usable without it. That is speculation on my part rather than a documented statement, and the gemspecs are where the answer is. The tooling around it is thorough. There is a.rubocop.yml plus a.rubocop/ directory, a separate.rubocop-md.yml for linting Markdown, a.mdlrc for the same, and a forspell.dict dictionary, which is the word list for a spell checker, which tells you the project checks the spelling of its own documentation. There is a gemfiles/ directory, the conventional way to test a gem against several dependency sets, a Gemfile and a Gemfile._local for local overrides, a Rakefile, a CHANGELOG.md, a spec/ directory for the tests, an etc/ directory, a docs/ directory, and bin/. The combination of a custom RuboCop plugin, a spell-check dictionary and a multi-gemfile matrix is the signature of a project maintained to a professional standard rather than a weekend experiment, and it is consistent with the release cadence and the version numbering. ## When a separate realtime server is worth the move The interesting question for a Rails team is when moving Action Cable out of the application process is worth the configuration work, because the answer is not always. The obvious case is horizontal scale. Action Cable runs inside your application servers, which means every application instance holds its own connections and needs a shared pub-sub backend to fan a broadcast out to all of them. Redis or a similar adapter solves that, but it is a second piece of infrastructure to run, and the fan-out path becomes the thing that has to be kept alive and monitored. With a dedicated realtime server, the connections and the broadcast live in one place and the application instances become clients of it rather than hosts of it. The second case is a protocol requirement. If you need server-sent events, a standalone server that speaks both transports is simpler than making an Action Cable application speak a second protocol, because the client library and the server are designed together rather than assembled from a Rails feature and a separate SSE implementation. The third is operational isolation. A realtime server has a very different resource profile from a request-handling application process, and separating them means you can scale, restart and observe them independently. Against that, there are costs. You now run two things instead of one. The SDK has to be a faithful stand-in for Action Cable, and any feature of Action Cable your application uses that the SDK does not cover is a gap you have to close yourself. And the setup generator is editing a live configuration, so it deserves a dry run on a branch. If your application has one server process and a modest number of subscribers, Action Cable is fine and the SDK is overhead. The move pays off when connection count, broadcast fan-out or the second protocol is the problem, and the release cadence of the gem, with 1.6.1 published in December 2025 and 1.6.0 back in February 2025, suggests the project is stable enough to plan around rather than track closely. ## Reporting a vulnerability, and what a version number means here The security contact is worth reading on its own, because it tells you something about how the project is run. To report a security vulnerability, contact anycable@evilmartians.com, and the project will coordinate the fix and the disclosure. That is a named address with a commitment to coordinated disclosure, rather than a request to open a public issue, and for a library that sits in the authentication and broadcast path of a Rails application that is the right arrangement. It is also a reminder that this gem is closer to the sensitive parts of an application than a typical utility. Action Cable handles channel authorisation and per-connection state, and a real-time server holds a large number of open connections. Whatever the SDK is doing to make the substitution transparent, it is doing it in that space. The version numbers need a word of explanation, because they are the gem's own rather than Rails'. The recent releases are 1.6.1, 1.6.0 and 1.5.0, and the 1.6.x line is the current one. The gem is versioned against the AnyCable server and the SDK's own compatibility, not against Rails releases, so the question when you are choosing a version is which server version and which Rails version the pair supports, and the answer lives in the documentation and the CHANGELOG rather than in the version number itself. That is worth checking before an upgrade rather than after. A realtime server swap touches your connection lifecycle, and the failure mode when a version pair is mismatched is a connection that opens and then behaves oddly, which is tedious to diagnose from application logs alone. The CHANGELOG.md in the repository root is the file to read first, and the fact that it is there rather than in a wiki is a small point in the project's favour. ## Conclusion Adopt anycable-rails if you are running Rails with Action Cable and want to move the realtime server out of the application process, whether because you need multiple application servers sharing one broadcast path or because you want server-sent events as well as WebSockets. Do not adopt it if you are starting a new Rails application with no realtime requirements, since the setup generator changes your configuration and there is no benefit without the fan-out problem. Before you run the generator, note that it edits your application configuration, and check the supported Action Cable version range for your Rails release, since the gem is versioned against the server rather than against Rails itself. ## FAQ ### What does the anycable-rails gem do? It is the Rails SDK for AnyCable, an open-source language-agnostic realtime server for two-way communication over WebSockets and SSE. The gem allows you to use AnyCable as a drop-in replacement for Action Cable. ### How do I install anycable-rails? Add the gem to your Gemfile with gem "anycable-rails", then run the interactive setup command bundle exec rails g anycable:setup, which walks through the configuration changes. The documentation at docs.anycable.io/rails/getting_started covers the details. ### What is the difference between anycable-rails and anycable-rails-core? The repository ships two runtime gems plus a separate RuboCop plugin gem. The release target in the Makefile pushes anycable-rails-core first and then anycable-rails with the -t flag, so the two are released together with the full gem depending on the core. ### How do I report a security issue in anycable-rails? Email anycable@evilmartians.com rather than opening a public issue. The project states that it will coordinate the fix and the disclosure. ## Sources - [anycable/anycable-rails on GitHub](https://github.com/anycable/anycable-rails) - [License: MIT](https://github.com/anycable/anycable-rails/blob/main/LICENSE) - [Project website](https://anycable.io) - [README](https://github.com/anycable/anycable-rails/blob/main/README.md) - [Releases](https://github.com/anycable/anycable-rails/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anycable-anycable-rails