Chaskiq: a self-hosted Intercom alternative built on Rails, React and GraphQL

What Chaskiq replaces, and for whom

Chaskiq is a full featured Live Chat, Support & Marketing platform, positioned by its README as an alternative to Intercom, Drift and Crisp. The feature list is unusually wide for a single repository: customer segment filters with custom attributes, an embeddable web messenger, agent conversation routing, text chat with customizable content blocks, video calls over RTC, triggerable conversational bots, mailing campaigns, onboarding tours, a help center with multilanguage support, GDPR consent configuration, audit records, a composable roles and permissions system, and pluggable reports.

The audience is narrower than that list suggests. This is a Rails application with a React front end and a PostgreSQL data store, so the people who get value from it are teams that already operate Ruby infrastructure and want the support desk, the knowledge base and the outbound mailing tool to share one database and one permission model. A marketing team looking for a hosted inbox will not enjoy the setup. A product team that already runs Rails, has a Postgres instance, and is paying per seat for a SaaS helpdesk is the realistic adopter.

The integrations are the second half of the pitch. The README lists Whatsapp, Twitter DM, Slack, Calendly and Zoom, plus Pipedrive for CRM and webhooks for everything else. Each of those is a separate credential to obtain and maintain, which is worth counting before you commit to the platform rather than after.

Rails API, React client, AnyCable for the socket layer

The README is explicit about the split: the back end is a Rails app that responds to requests RESTfully in JSON, and the front end is a React app that communicates with the Rails GraphQL API. PostgreSQL is the main data store. Redis is used as a cache and for transient data. The README points to the Gemfile for the complete list of Ruby dependencies, and package.json shows the front end is a Yarn workspace monorepo with app/javascript/packages/* as the workspace glob, with @chaskiq/components and @chaskiq/store as internal packages.

The socket layer is where the architecture gets interesting. docker-compose.yml defines an anycable service running anycable/anycable-go:1.0-alpine on port 8080, plus a separate rpc service running bundle exec anycable. The Go process holds the websocket connections and talks to the Ruby RPC server over gRPC on port 50051, with ANYCABLE_RPC_HOST set to rpc:50051 and ANYCABLE_HEADERS set to cookie,origin. That means a production deployment is not one process. It is Rails, a Ruby RPC worker, a Go websocket server and Redis, at minimum.

The GraphQL API is consumable with OAuth authorization according to the README, which is the integration path for anything the built-in apps do not cover. The dashboard is described as having an extensible and pluggable architecture so you can implement your own blocks against external data sources. That is a real extension point, and it is also the kind of claim that only pays off if you are comfortable reading the front end source, because the README does not document the block API.

Installing Chaskiq with Docker and starting a first conversation

The README does not put install commands in the repository root. It redirects: for a development environment there are separate guides for macOS, Ubuntu, Windows 10 and Docker at dev.chaskiq.io, and for production it points to the Chaskiq Install Guide at dev.chaskiq.io/production-configuration. The minimum versions stated before you start are Ruby 2.6+, PostgreSQL 10+ and Redis 2.6+.

The repository does ship a docker-compose.yml, and it is the fastest way to see the stack. It builds from Dockerfile.development with RUBY_VERSION 3.3.5, PG_MAJOR 15, NODE_MAJOR 16, YARN_VERSION 1.13.0 and BUNDLER_VERSION 2.3.26. The rails service maps ports 3000 and 3001 and runs ./bin/dev.

docker compose up runner
docker compose exec runner bin/rails db:prepare
docker compose up rails anycable rpc

The first command starts the backend image with a bash shell so you can prepare the database without the web server competing for the terminal. The second runs the Rails database task inside that container. The third brings up the Rails server, the AnyCable Go process and the Ruby RPC worker together, after which localhost:3000 should serve the app.

Configuration comes from environment variables, and .env.example is the reference. It sets HOST, ASSET_HOST and WS, which must agree with how the browser reaches the app, then the AWS S3 credentials used for uploads, and the bootstrap account:

HOST=http://localhost:3000
WS=ws://localhost:3000/cable
[email protected]
ADMIN_PASSWORD=password
DEFAULT_SENDER_EMAIL=admin@example

The WS value has to point at the AnyCable endpoint, not the Rails port, or the messenger will load and then sit silent. Once the app is up, the first real task is creating a help center article and embedding the web messenger on a page you control, because those two together are the part of the product that touches your customers.

Where Chaskiq stops being the right tool

The licence is the first constraint, and it is not a small print item. package.json declares AGPL-3.0-or-later, and the README describes the commercial licence as existing so you can use Chaskiq in commercial products without the provisions of the AGPL-3.0-or-later plus commons clause, keeping your code proprietary. The repository's LICENSE.txt is classified as NOASSERTION on GitHub, so the authoritative text is the file itself, not the package metadata. If you intend to modify Chaskiq and expose it to users over a network, read the licence before you build anything on top of it. That is a statement about what the licence says, not legal advice.

The operational surface is the second constraint. A working deployment needs PostgreSQL, Redis, the Rails process, the AnyCable Go binary and the Ruby RPC worker, with the RPC host and websocket headers configured correctly between them. That is a lot of moving parts for a support widget, and every one of them is a thing that can fail at 2am. Teams without Ruby experience will spend their first week on the stack rather than on the product.

The release history is the third. The most recent release listed is 2.0.3 from 2023-11-14, and the README's own feature list ends with the phrase and many features to come. The last push to the repository was on 2026-06-30, so the codebase is being touched, but the tagged releases are old. If you need a versioned artifact with a changelog you can pin to, that gap matters more than the commit activity.

Finally, the README's browser support table targets Safari 10+, Chrome 57+, Internet Explorer 11+ and Firefox 52+. Internet Explorer 11 is in that list, which tells you the compatibility floor was set a while ago and the front end carries the weight of it.

Chaskiq compared with Chatwoot and other open source desks

The searches people run against this project are dominated by one comparison: chaskiq vs chatwoot. The difference is in the stack rather than the feature list. Chaskiq is Rails plus React plus GraphQL, with AnyCable handling websockets and a pluggable dashboard the README says you can extend with your own blocks. Chatwoot is the other name that comes up repeatedly in the same searches, and it is the alternative most teams will evaluate first.

The practical distinction is how much of the product you are expected to assemble. Chaskiq ships the help center, the mailing campaigns, the onboarding tours and the conversational bots as first-class parts of the same application, which is why its feature list reads like a SaaS pricing page. The cost is the runtime: Rails, Postgres, Redis, AnyCable Go and the RPC worker. A lighter desk with fewer subsystems will be easier to keep alive.

If your team is not a Rails team, the calculus changes completely. The GraphQL API with OAuth is there for integration, but the extension points described in the README assume you can read the front end packages. Teams that want to fork and reshape the product need Ruby and React skills in house. Teams that only want to answer messages should look at whichever option requires the least infrastructure for their scale, and for many of them that is not Chaskiq.

Maintenance, upgrades and what the release history tells you

Upgrade cost is the part the README does not cover. There is no rollback procedure documented, no migration guide between major versions, and no compatibility matrix for the GraphQL API. The Gemfile.lock and yarn.lock are checked in, which pins the dependency tree for a given commit, but the path from one tagged release to the next is not described anywhere in the repository files.

What the repository does show is a wide dependency surface. The front end alone carries React 17, MUI-era packages such as @emotion/react and @headlessui/react, charting through @nivo, maps through mapbox-gl, the dante3 editor, i18next for translation and esbuild for bundling. The back end is a Rails app with a Gemfile the README declines to enumerate. Every one of those is a package that will need attention, and translations are managed through Crowdin according to the README badge, which means locale files move independently of the code.

The production Dockerfile is the other maintenance signal. It takes RUBY_VERSION, PG_MAJOR, NODE_MAJOR, BUNDLER_VERSION and YARN_VERSION as build arguments, installs PostgreSQL and Node inside the image, and precompiles assets with NODE_OPTIONS set to --max-old-space-size=2048. Asset compilation at that memory ceiling is the kind of step that fails quietly on a small build machine.

Given the gap between the 2.0.3 tag in November 2023 and the last push in June 2026, treat the main branch as the thing that moves and the releases as snapshots. If you need a version you can point at and defend, check what the tag actually contains before you plan around it.

Editorial conclusion

Chaskiq fits teams that already run Ruby on Rails, want the web messenger, help center and mailing campaigns in one database, and accept AGPL-3.0-or-later plus the commons clause unless they buy the commercial licence. Skip it if you need a managed service or a stack you can host on a single small VPS without Postgres and Redis. Before committing, read the production configuration guide at dev.chaskiq.io and confirm the licence terms against your own distribution model.

Frequently asked questions

Official sources

1. chaskiq/chaskiq on GitHub
2. Issues
3. Project website
4. README
5. Releases