Deployment
Choose the shortest WuKongIM deployment path and complete the required checks before traffic cutover.
Deployment starts with one decision: can you accept a single point of failure? If you are unsure which runtime to choose, start with Docker.
Every deployment is a cluster
A one-node deployment is a single-node cluster. It still uses the Controller, Slot, Channel, routing, and storage paths; there is no standalone mode that bypasses cluster semantics.
Choose a path
| Your goal | Start here |
|---|---|
| Run locally and verify the message path | Quick Start |
| Use the shortest repeatable deployment path | Docker (recommended) |
| Manage hosts, files, and systemd directly | Linux |
| Replicate across nodes and plan failure recovery | Read Multi-node Cluster, then choose Docker or Linux |
A single-node cluster fits development, validation, and small production workloads that explicitly accept interruption after a node or disk failure. Use a multi-node cluster across independent failure domains when service must continue after a node failure.
Every deployment must satisfy
- Pin an artifact version or digest; never use a floating tag.
- Give every node a unique ID, independent persistent storage, and a reachable transport address.
- Replace example credentials and restrict Manager, metrics, debug, benchmark, diagnostics, and transport access.
- Advertise TCP, WS, or WSS addresses that clients can actually reach; use
0.0.0.0only for listeners. - Verify persistent mounts, an end-to-end message, and
/readyzbefore admitting traffic.
curl --fail http://127.0.0.1:5001/readyz/healthz only proves that the process responds. Load balancers, release gates, and traffic cutover must use /readyz.