The open source Slack alternative you can read line by line.

Every chat tool claims to be “built for teams.” Very few will let you open the hood and check. Fluid Chat is an open source Slack alternative where the entire product — the messaging, the search, the admin console, the API — is source you can read, fork, run and argue with on a Tuesday afternoon.

There is no “community edition” with the good parts sawn off. There is one edition. You can host it yourself, or use the hosted version, and both of them cost the same thing, which is nothing.

What “open source” usually means, and what it means here

In chat software, “open source” has quietly become a garnish. A lot of products publish a repo, then keep the useful half — SSO, retention, audit logs, the admin bits — behind a licence key that turns on features the community build deliberately can't reach. You get the source, in the sense that a restaurant will show you a photo of the kitchen.

Fluid Chat does not have a second binary. The admin features that other tools use as upgrade bait — roles, guest scoping, audit logging, retention policies, per-workspace read-only mode, scoped API keys, full data export — are in the same repository as the message composer, because there is no business model that requires hiding them.

What you actually get

Open source is only interesting if the software is good, so here is the boring inventory. Fluid Chat ships 91 features across messaging, search, files, administration and its API — not a proof of concept with a roadmap attached.

• Channels, DMs and group DMs — public and private channels, a channel browser with previews, archiving, and group DMs up to nine people.
• Threads that behave — reply counts, participant facepiles, and the “also send to channel” escape hatch for when a thread turns out to matter.
• Search with real operators — in:#channel, from:@person, has:file, is:pinned, before:/after:/during:, running over Postgres full-text search across your entire history.
• Reactions, custom emoji, mentions — including @here, @channel, @everyone, user groups, and skin tones, because these are apparently non-negotiable.
• Files, pins, saved items and reminders — drag-drop uploads to S3-compatible storage, inline images, permalinks, scheduled send.
• An admin console with teeth — audit log, retention policies, invite links with limits, per-channel posting policy, guest accounts scoped to their channels.
• A real API — the web client has no private endpoints. It calls /api, there's a generated OpenAPI 3.1 document, and API keys carry explicit scopes and rate limits.

What it does not have, stated plainly so nobody discovers it in week three: no huddles, no voice or video, no Slack Connect, no SSO/SAML, no native mobile apps (the web client uses a drawer layout and works fine on a phone), and no Slack importer yet. Those are scope decisions, not a pricing tier you can unlock.

Why open source matters more for chat than for most software

Your chat log is the least-guarded, most-honest record your company keeps. It's where the incident actually got debugged, where the decision actually got made, and where someone pasted a production connection string in 2023 and everyone agreed never to mention it again.

That makes three things matter unusually much:

1. 1You can audit it. Not “a vendor's compliance PDF says it's fine” — you can grep the permission helpers yourself. Every query in Fluid Chat is workspace-scoped through shared helpers rather than ad-hoc filters, and you can go check that claim right now.
2. 2You can't be evicted. Open source plus self-hosting means no pricing change, acquisition, or region shutdown can hold your history hostage. The worst case is you keep running the version you have.
3. 3You can change it. Adding an endpoint is a route entry plus a service function. If your team needs a weird integration, you don't file a feature request into the void — you write it.

Open source Slack alternatives, briefly compared

Fluid isn't the only option here, and pretending otherwise would be a strange way to earn your trust. The genuinely useful differences are architectural, because those don't change when someone reshuffles a pricing page.

Short version: pick Mattermost if you want a mature enterprise story and don't mind the paid tiers. Pick Rocket.Chat if you want voice, video and omnichannel in one box and MongoDB doesn't scare you. Pick Zulip if your team genuinely thinks in topics rather than channels — its threading model is the best in the category and it's a real reason to choose it. Pick Fluid if you want the boring stack, the whole feature set at $0, and no tier chart at all.

The stack is deliberately boring

The fastest way to make open source software nobody self-hosts is to require six services nobody has heard of. Fluid Chat has exactly one hard dependency: Postgres. Messages live there. The search index lives there. There's no proprietary datastore to learn and nothing that phones home.

• Next.js 15 for the app and API, over a typed server router.
• Postgres 14+ — the only hard dependency, doing storage and full-text search.
• Socket.IO for presence, typing and event relay. It's an accelerator, not a dependency: if the socket dies, writes still go over HTTP and the app keeps working.
• Redis — optional. You only need it once you run more than one app process, at which point realtime events fan out over pub/sub.
• A worker for scheduled sends, reminders, retention, exports and email.
• S3-compatible storage for uploads. MinIO counts.

# the whole thing, on your machine, in about two minutesgit clone https://github.com/azianmike/fluid-chat.gitcd fluid-chat && cp .env.example .envdocker compose up  app       ready on http://localhost:3000  realtime  websockets on :3001  worker    jobs running  postgres  migrations applied

Is open source chat actually safe to run?

The usual worry is that open source means “anyone can see the vulnerabilities.” In practice, closed chat software has exactly the same vulnerabilities — you just find out about them via a status page.

What Fluid does about it: passwords are hashed with Argon2, every query is workspace-scoped through permission helpers rather than hand-written filters, guests are confined to the channels they're added to, API keys carry explicit scopes with per-key rate limits and audited creation, and the audit log records the administrative actions you'd want to reconstruct later. Self-hosted, none of it leaves your server. And unlike a compliance badge, you can verify all of that by reading the code.

Who this is a bad fit for

An honest list, because the fastest way to waste your afternoon is a landing page that says “perfect for every team.”

• You need voice, video or huddles in the same app. Fluid doesn't do them and isn't planning to.
• You need SSO/SAML on day one. Not built.
• You need native iOS and Android apps. The web client is genuinely good on mobile, but it's a web client.
• You need to import years of Slack history right now. Export out of Fluid is solved (JSONL, CSV, file manifest); importing Slack's archive is the open piece, and it's a great first contribution.
• You need Slack Connect to talk to other companies.

If none of those are dealbreakers, the rest of the trade is very good: every feature, every person, unlimited history, $0, and source you can read.