Deploy Rocket.Chat — Self-Hosted Team Chat & Slack Alternative

Deploy and Host Rocket.Chat on Railway

Rocket.Chat is the open-source alternative to Slack and Microsoft Teams — a complete team communication platform with channels, threads, direct messaging, voice and video calls, screen sharing, file sharing, and a 200+ app marketplace. This template deploys it with MongoDB correctly configured as a replica set — the hard requirement that breaks most self-hosted attempts — so real-time messaging works from the first deploy.

What This Template Deploys

Both connect over Railway's private network; only Rocket.Chat is public. MongoDB is initialized as a single-node replica set, which Rocket.Chat requires — and because uploads default to GridFS in MongoDB, all your data lives in one place.

About Hosting

Rocket.Chat is feature-rich, but one MongoDB requirement determines whether it works at all — and it's the thing most self-hosted deploys get wrong.

MongoDB must run as a replica set — even for a single node. This is non-negotiable: Rocket.Chat relies on MongoDB change streams for real-time message delivery, and change streams only work when MongoDB runs as a replica set. A plain MongoDB deploy starts, but Rocket.Chat's real-time updates silently fail — messages don't appear live, which defeats the purpose. This template runs MongoDB with --replSet rs0, initializes it automatically, and points MONGO_URL and MONGO_OPLOG_URL at it with ?replicaSet=rs0 — the exact step naive deploys skip.

ROOT_URL must be your Railway public domain. Rocket.Chat builds links, upload URLs, and OAuth redirects from ROOT_URL, so it must match your Railway domain exactly, or invites and integrations break. This template sets it from your domain.

All data lives in MongoDB — so backups are simple. Uploads default to GridFS storage inside MongoDB, meaning messages, users, settings, and files all live in the one database. The Rocket.Chat container itself is stateless, so redeploys and upgrades are clean, and backing up MongoDB backs up everything.

Complete the setup wizard on first open. After deploy, open your Rocket.Chat URL and the Setup Wizard runs — create your admin account, name your organization, and configure the workspace. Then you land on the home screen ready to create channels and invite your team.

It's a heavier app — size it right. Rocket.Chat is feature-complete, so it wants resources. Small teams run on modest settings, but for 500+ concurrent users, plan for 4+ vCPU and 8+ GB RAM, with extra memory for MongoDB's working set.

Typical cost: ~$10–20/month on Railway for Rocket.Chat and MongoDB, more for large teams. Rocket.Chat Community is MIT-licensed and free; the cloud plans bill ~$7/user/month.

How It Compares

Slack and Teams are polished but bill per user and keep your conversations on their servers. Mattermost is a lighter self-hosted option on Postgres. Rocket.Chat's edge is being the most feature-complete self-hosted Slack alternative — video, an app marketplace, omnichannel customer support, LDAP, and federation — with your team's data fully on infrastructure you own, at flat cost.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — Rocket.Chat and MongoDB build, and the replica set initializes (~4 minutes)
2. Confirm ROOT_URL is your Railway public domain
3. Confirm MongoDB is running as a replica set (this template handles it automatically)
4. Open your Railway URL and complete the Setup Wizard to create your admin account
5. Create channels, invite your team, and start messaging

Real-time messaging works immediately because MongoDB is configured as a replica set from the start.

Common Use Cases

• Slack alternative without per-user fees — unlimited team members at flat infrastructure cost
• Private team communication — channels, threads, and DMs with your data on your own infrastructure
• Video meetings and screen sharing — built-in voice and video calls without a separate tool
• Community platform — public channels and federation for open communities and user groups
• Regulated environments — self-hosted messaging with LDAP, E2E encryption, and full audit control

Configuration

MongoDB must be a replica set. Rocket.Chat needs MongoDB change streams for real-time messaging, which require replica-set mode even single-node. This template runs --replSet rs0, initializes it, and sets ?replicaSet=rs0 on both Mongo URLs — the step naive deploys miss.

ROOT_URL must match your domain. Links, uploads, and OAuth build from it. If it doesn't match your Railway domain, invites and integrations break. Data lives in MongoDB (GridFS), so back up MongoDB to back up everything.

Dependencies for Rocket.Chat Hosting

• Railway account — ~$10–20/month for Rocket.Chat and MongoDB, more for large teams
• MongoDB configured as a replica set (included and initialized automatically)
• Adequate resources for your team size (4+ vCPU / 8+ GB RAM for 500+ users)
• Optional: SMTP for email invitations and notifications

Deployment Dependencies

• Rocket.Chat GitHub Repository
• Rocket.Chat Documentation
• Docker Deployment Guide
• Railway Private Networking

Implementation Details

The template runs the official Rocket.Chat image (registry.rocket.chat/rocketchat/rocket.chat) on port 3000 alongside a MongoDB service started with --replSet rs0. Because Rocket.Chat depends on MongoDB change streams for real-time updates — which require replica-set mode even for a single node — the template initializes the replica set automatically and sets MONGO_URL and MONGO_OPLOG_URL with ?replicaSet=rs0. This is the single most common failure in self-hosted Rocket.Chat: a standalone MongoDB starts but real-time messaging never works.

ROOT_URL is set to the Railway public domain so links, upload URLs, and OAuth callbacks resolve correctly, and the services communicate over the private network with only Rocket.Chat exposed. Uploads default to GridFS storage inside MongoDB, so all messages, users, settings, and files live in the database and the application container is effectively stateless — redeploys and upgrades are clean, and a MongoDB backup captures everything.

On first launch, the Setup Wizard creates the admin account and workspace. Rocket.Chat is a resource-intensive application; small teams run on modest settings while large deployments benefit from additional CPU and RAM, particularly for MongoDB's working set cache.

Frequently Asked Questions

Why does MongoDB need to be a replica set? Rocket.Chat uses MongoDB change streams for real-time message delivery, and change streams only work in replica-set mode — even single-node. Without it, the app starts but live messaging fails. This template configures the replica set automatically.

Why isn't real-time messaging working on my other deploy? Almost always because MongoDB isn't a replica set. A standalone MongoDB lets Rocket.Chat start but breaks change streams, so messages don't appear live. This template runs --replSet rs0 and initializes it.

Where is my data stored? In MongoDB — messages, users, settings, and uploaded files (via GridFS) all live there. The Rocket.Chat container is stateless, so backing up MongoDB backs up your entire workspace.

Why must ROOT_URL match my domain? Rocket.Chat builds links, upload URLs, and OAuth redirects from it. If it doesn't match your Railway domain, invitations and integrations break.

Can I do video calls? Yes — voice and video calls and screen sharing are built in, so you don't need a separate meeting tool alongside your team chat.

How is it different from Mattermost? Both are self-hosted Slack alternatives; Rocket.Chat has more features (app marketplace, omnichannel, federation) but runs on a MongoDB replica set, while Mattermost is lighter on Postgres.

Why Deploy Rocket.Chat on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Rocket.Chat on Railway you get a full self-hosted team chat platform with the hard part solved — MongoDB configured and initialized as a replica set so real-time messaging works immediately, ROOT_URL set, and automatic HTTPS. Channels, video calls, and an app marketplace, with your team's data on infrastructure you own.