Slick

open source · self hosted

Your team's
chat. Your
infrastructure.

Slick is self hosted team chat: channels, threads, calls, search, and files, on a server you control and can encrypt end to end. People and AI agents share one API, so an agent is a member rather than an integration.

Install guide
One container holding every part of SlickA cutaway drawing of a single container. Inside it, stacked: the web app, the HTTP API, the realtime gateway, and background jobs. Beneath it, one mounted volume holding the database and uploaded files.one processweb appreact, served statichttp apihonorealtime gatewaywebsocket fan-outbackground jobspruning, thumbnails/datasqlite, and every file:3000, the only portno message brokerno queue, no workerno cronone volumecopy it to back it up
fig 01Everything above ships as one image and runs as one process.

§ 02behaviour

2.1

Realtime that survives a restart

Every change is appended to a durable event log inside the same transaction that made it. Clients reconnect with the last sequence they saw and get exactly what they missed, across dropped wifi and server restarts alike.

no sticky sessions

2.2

Agents are ordinary members

A bot holds a token and uses the same REST and WebSocket API a person does. There is no reduced bot API to work around, so an agent can read a thread, search the workspace, and answer in place.

see fig 02

2.3

Encryption you can actually turn on

Switch it on per channel and the server keeps only ciphertext. Keys are generated on your devices, sealed individually to each member, and rotated whenever membership changes.

calls never touch the server

2.4

Calls that connect anywhere

Audio, video, and screen sharing, peer to peer. Add the bundled relay and the networks that normally break calls, corporate wifi and mobile carriers, work the same as everything else.

media stays encrypted through the relay

fig 02an agent answering from workspace history

#eng3 people, 1 agent
  1. Dana09:41

    @claude what did we settle on for the Postgres cutover?

  2. claudeagent09:41

    You decided to run the migration CLI against an empty database first, keep the event-log seq values so connected clients resume, then restart with DATABASE_URL set.

    from #eng, 12 July

scripted · agents use the same api people do

§ 03clients

3.1

The web app

Served by the same process as the API, on the same port. There is nothing to install and nothing to keep in step: the app a browser loads is the one that server shipped with.

any modern browser

3.2

macOS and Windows

A native shell around the same web app, pointed at your server. It exists for what a browser tab cannot do: a dock badge, real notifications, and a window that outlives a browser restart.

built from source, macOS tested

3.3

iPhone

The same shell again, built for iOS, connecting to the server you type in on first launch. Calls, encryption, and push all work the way they do everywhere else.

not on the app store

The shells are not published as downloads yet. Both are built from the repository with one command, and the desktop and install pages say how. Everyone else can simply open the server in a browser.

§ 04specification

Your data stays where you put it.

One directory holds everything: a SQLite database and the files people upload. Back it up by copying it. Move it by moving it. There is no account to close, no export to request, and nothing phoning home.

license
AGPL 3.0
image
One, multi-stage
processes
One
ports
One, 3000
database
SQLite, or Postgres
files
Local disk, or S3
media
Peer to peer, always encrypted
clients
Web, macOS, Windows, iPhone
telemetry
None

notenot built yet

If you would rather not run it.

Hosting is not available today. Leave an address and you will hear one time, when it exists.