#3 · Rocket.Chat is unusable
My experience with Rocket.Chat has been one of the worst experience with open source self-hosted software I've ever had
Dear subscriber,
Aléryon Science is a one man operation. I have limited collaboration needs but I still need some tools. For the last few months, I've considered to add some form of chat app to my tools. A coworking space I attend has an instance of Rocket.Chat and as an end user, I really like it.
A few days ago I decided to toy with installing an instance for myself. I quickly realized that from an admin point of view, Rocket.Chat is an unusable piece of software. Unless there is a specific feature of Rocket.Chat you absolutely need, I would argue you should look for something else. Rocket.Chat has been messy for Aléryon Science, but I cannot imagine how catastrophic it could be for a much larger organization with larger and more critically important chat needs.
Let me breakdown why I think Rocket.Chat is unusable. Tighten your seatbelt because it's about to be a hell of a ride.
It all started with the DigitalOcean marketplace image. In my experience, these images are of, let's say, varying quality. They probably should be avoided for production servers, but as a testing ground they're useful. The Rocket.Chat one though is truly something else.
As of today, the image installs the 4.5.4
version of Rocket.Chat but Rocket.Chat is currently at the 5.1.1
version.
The numbering indicates that a major release happened recently, so one could assume that there's an easy upgrade path once you install the image. Don't get your hopes too high because trying to upgrade from 4.5.4
to 5.1.1
will break beyond repair your instance. And I couldn't find a way to repair it, even after extensive googling. There's this post on the forum but the solution didn't work for me.
I tried to do some digging myself, in the logs. I'm not a sysadmin but I've administered servers for more than 10 years now so I have some skills. My best guess was that updating from 4.x.x
to 5.x.x
involves some breaking change in Node.js — changes the CLI updater is incapable of taking care of properly. But then I've found this issue on GitHub where somebody had the same problem… from from 4.5
to 4.6
. So the problem with the updater is probably even worse than a breaking change that wasn't properly taken care of — which is already a huge red flag in my opinion.
Bear in mind that at this point, I've already spend several hours trying to correctly upgrade. And the upgrading method I use is the recommended method. So if you go with the DigitalOcean marketplace image, you only have two options:
- sticking to the installed, outdated version
- breaking your instance beyond repair
Those are two unacceptable options, so I decided to install Rocket.Chat manually. There is a dedicated page on their docs claming that deploying Rocket.Chat is "as easy as it can get". Having worked with Docker in the past, I felt confident the claim was correct.
I can definitely say it was one of the worst experience I've ever had with trying to install an open source, self-hosted software. I carefully tried to follow the instructions but I had trouble correctly filling the .env
file.
### Rocket.Chat configuration
# Rocket.Chat version
# see:- https://github.com/RocketChat/Rocket.Chat/releases
#RELEASE=
# MongoDB endpoint (include ?replicaSet= parameter)
#MONGO_URL=
# MongoDB endpoint to the local database
#MONGO_OPLOG_URL=
# IP to bind the process to
#BIND_IP=
# URL used to access your Rocket.Chat instance
#ROOT_URL=
# Port Rocket.Chat runs on (in-container)
#PORT=
# Port on the host to bind to
#HOST_PORT=
### MongoDB configuration
# MongoDB version/image tag
#MONGODB_RELEASE=
# See:- https://hub.docker.com/r/bitnami/mongodb
### Traefik config (if enabled)
# Traefik version/image tag
#TRAEFIK_RELEASE=
# Domain for https (change ROOT_URL & BIND_IP accordingly)
#DOMAIN=
# Email for certificate notifications
#LETSENCRYPT_EMAIL=
Should ROOT_URL
include the protocol (https://
) or just the FQDN? Should I use the internal IP in BIND_IP
or the public IP of the server? What am I supposed to put in the Traefik options? There's literally no documentation whatsoever on how to fill this file correctly.
I also had some odd behavior from the server, only to realize it needed more RAM. Why is there no minimum configuration stated in the docs? I solved this by adding a swap file but I could have saved time if I knew beforehand what kind of specs the server needs.
I'm guessing I still did something wrong because despite many trials, I never succeeded to have a running instance of Rocket.Chat on my VPS. The server proven to be unaccessible. I tried to find a workaround and then I realized there is… a completely different page of instruction, on the same website, to also install Rocket.Chat with Docker.
I discovered this second page by pure chance. I tried to follow the instructions of this second page but once again, I couldn't have a working installation of Rocket.Chat. At this point, I probably should have given up but hey, who doesn't like a good challenge? So I tried something else:
- install Nginx with a Let's Encrypt certificate
- install Rocket.Chat via Docker
- serve Rocket.Chat with Nginx as a reverse proxy
I purposely installed an outdated version of Rocket.Case to see if with this method, upgrading does break the instance beyond repair or not. And then finally, success! I had 1) a working instance of Rocket.Chat 2) that I could actually upgrade without destroying it. About time!
But don't get your hopes too high. It's not over.
When you do the setup, Rocket.Chat offers you to connect your instance to the Rocket.Chat cloud. If you connect to it, you'll get push notifications and a bunch of other extra features such as the ability to install apps from their marketplace. It's in theory a simple process: your provide your email address to create an account on their cloud platform and that's it. It actually never worked. I received the confirmation email, but it failed. I tried to redo the confirmation process a few times but after maybe three or four tentatives, it deteroriated to the point that the emails came with an empty URL for the confirmation link. Every time the confirmation failed, I had to redo the whole setup from scratch. I have no idea what's broken on the Rocket.Chat cloud, but something definitely is. So I decided to skip this part and setup my instance without pairing with their cloud.
I dived into the administration settings and oh boy, here's you will get hit by another layer of "what the hell is that". I honestly don't know where to start so I better make a list:
- there is a huge number of settings — which in itself is not necessarily a bad thing. The real issue is that almost none of them are documented. You have to guess what a given setting is doing. Push buttons and hope for the best.
- you can connect to their cloud but the process is bizarre, clunky and not user friendly — at all. It also took me a few trials to make it correctly work.
- there are multiple instances where the UI is just broken — up the point it's unusuable
I probably should have given up there, but I did not. I did some feature testing on my own and it turns out that Rocket.Chat would work really well for my use case. But then I hit another wall: push notifications on iOS.
I won't elaborate much here as it's the same boring story: I couldn't make them work. The instance is, at least in theory, properly connected to the Rocket.Chat cloud, but something, somewhere, is broken. I've found this page on a different helpdesk site and (oh surprise) none of the instructions worked. Even worse, I couldn't find the "Always notify mobile" option in the administration settings. And bear in mind that I ran the latest version of Rocket.Chat. So either the feature broke due to a bug or has been retired and the docs hasn't been updated — in both instance, it doesn't shed a positive light on Rocket.Chat. I also tried to setup the "Direct Reply" email feature — never worked even though I never got any error message.
I won't lie, at this point my patience started to significantly erode. A chat app without push notifications is basically useless. A chat app that is so hard to install is definitely not a chat app that wants to be installed. A chat app that can break beyond repair while you upgrade it with the recommended upgrade method is not a chat app you want to trust. What about their cloud offering though? Rocket.Chat Cloud offers some full-fledged hosting, so maybe it could fit my needs. Remember, I'm a solo entrepreneur with limited, but real, collaboration needs.
I headed to their pricing page and they do not list a single price point. See for yourself here.
The product offering is not really clear either. My needs are clear: I need a Rocket.Chat instance with a few seats. I shouldn't need to "Talk to an expert" or to "Contact sales" to have a price estimate for this. In comparison, Mattermost Cloud has a much clearer pricing page.
Withholding pricing is not new for Rocket.Chat Cloud. Remember the push notifications? They're push via their cloud, for free up to 10.000 notifications a month. What does it cost if you need more? You need to contact sales to have an answer! Why on Earth would you willingly make literally everything so complicated when your competitors show it can be much, much simpler? Or maybe I'm not the target audience of Rocket.Chat — but based on how easily the software can catastrophically break, larger organizations probably aren't either. So who is Rocket.Chat for exactly?
This is where I decided to give up. I wanted to install Rocket.Chat to explore its features and ease of use but in just a few days, it was just too much trouble. I'm not a sysadmin and I have no interest in spending too much of my time administrating my tools. Plus Rocket.Chat doesn't feel like an app you can trust. I don't want such a critical tool to break beyond repair when I do some routine upgrading.
As an organizational economist, I was curious to see if I had been extremely unlucky or if the organization behind Rocket.Chat is poorly run. I think it's probably poorly run.
Look at this thread — from February 2018. It's about the GitHub issues on the main Rocket.Chat repo. The author complains it's a huge mess and offers a bunch of suggestions to improve their management.
A few people working at Rocket.Chat answered and promised that improvements were underway. In September 2022, so 4.5 years later, none of them are visible. They still have a ton of open, unresolved issues — almost 2900.
In the thread, the author complains about the large number of labels used to "organize" the issues. He mentions a hundred labels. As of today, the number has worsened to 149.
In this other thread, another user mentions a "catastrophic bug" in 3.12.1
and 3.12.2
.
The bug discussed in this last thread also seems to surface regularly — which leaves me wondering how good, or more realistically how bad, Rocket.Chat is at debugging its own code. Which, in turn, raises the question of the overall quality of the codebase.
For me, the adventure with Rocket.Chat ends here. It's a hassle to administer — up the point it's probably the worst open source self-hosted software I've used in the last 12 years. And it's even worse considering there's a full company behind it. It's understable for small open source projects lead by volunteers to have trouble fixing bugs. But for an open source software with the resources of Rocket.Chat, it's really not reassuring.
I did not write this post to criticize the people working at, and on, Rocket.Chat. I'm not here to lay blame. My goal is to warn any potential admin user of Rocket.Chat that Rocket.Chat is a leaky boat that will come with a rocky experience. You probably better off going with another self-hosted solution such as Mattermost or Nextcloud Talk — or go with a commercial offering such as Slack, Microsoft Teams or Zoom Chat. I will probably stuck with Zoom Chat. It's powerful enough for what I do and I already have a paid Zoom subscription. Zoom has its own issues but overall, it's good enough for my needs.
Olivier