Docs
Servers & ports
A reference for the services in an Etoki deployment: what each one does, the ports it listens on, and how to operate it.
Services & ports
A typical deployment exposes these ports. Only open what you run; the gateway on 443 can front several services behind bridge paths.
| Port | Service | Role |
|---|---|---|
| 443 | Gateway | TLS camouflage — looks like HTTPS, fronts router/directory |
| 5223 | Router | Message queues + 2-hop onion forwarding (TCP; WS variant available) |
| 5443 | File relay | Chunked, padded file transfer (NFP) |
| 5553 | Push relay | Content-free push fan-out (NPP) |
| 5663 | Directory | Opt-in @username → contact-address lookup (NDP) |
| 3478 | coturn | STUN/TURN for calls and Etoki push-to-talk |
| 5880/5881 | Bot relay | HTTP/HTTPS bot API (optional, one host) |
| localhost | etokid | Headless daemon WS/JSON API for bots (keep private) |
Transports
Clients can reach a router over several transports:
- Plain TCP — the default, e.g.
etoki://<fp>@your.host:5223. - WebSocket —
ws://form for reachability behind CDNs and reverse proxies. - TLS camouflage —
tls://sni@host:443/path, indistinguishable from HTTPS to an observer. - SOCKS5 / Tor — dial through a SOCKS5 proxy so onion targets resolve inside Tor, with per-session circuit isolation.
State & identity
Each service persists its identity and data under a state directory (a systemd StateDirectory). Because the fingerprint is derived from persisted keys, addresses stay stable across restarts and upgrades.
Back up your state directories / volumes. Router queue retention and quotas are tunable through the admin plane.
Operating the services
- systemd:
systemctl status|restartandjournalctl -u <unit>for logs. - Keep the etokid daemon API on a private network — it is token-gated but not TLS by default.