One Socketelx server can serve several Pusher apps on one port. Each app has its own id, key and secret, and is fully separate from the others: a connection with app A's key never sees app B's channels, presence, webhooks or counters.
Use it when you host more than one product, or want a staging and a production app on the same box. If you only have one app you don't need any of this.
Docker (JSON in one variable)
docker run -p 6001:6001 \
-e SOCKETELX_APPS='[
{"id":"chat","key":"chat-key","secret":"a-long-random-secret",
"allowed_origins":["https://chat.example.com"]},
{"id":"admin","key":"admin-key","secret":"another-long-secret",
"webhook_url":"https://admin.example.com/hooks"}
]' \
ghcr.io/socketelx/socketelx
Each app needs id, key and secret. It may also set webhook_url,
client_messages_enabled, allowed_origins, max_connections,
max_connections_per_ip, rest_rate_limit, client_event_rate_limit and
batch_limit. Everything else (port, Redis, cluster, metrics, TLS) is
server-wide and comes from the usual variables.
Ids and keys must be unique. Setting SOCKETELX_APPS replaces
SOCKETELX_APP_ID, SOCKETELX_APP_KEY and SOCKETELX_APP_SECRET.
Elixir
{Socketelx,
name: MyApp.Socketelx,
port: 6001,
max_connections: 5_000,
apps: [
[id: "chat", key: "chat-key", secret: "...", allowed_origins: ["https://chat.example.com"]],
[id: "admin", key: "admin-key", secret: "..."]
]}Options outside apps are defaults for every app; an app's own value wins. On a
multi-app server say which app you mean:
Socketelx.trigger(MyApp.Socketelx, "room-1", "message", %{text: "hi"}, app: "chat")
Socketelx.authorize_channel(MyApp.Socketelx, socket_id, "private-room-1", app: "chat")What each client uses
Clients connect with their app's key (new Pusher("chat-key", ...)), and your
backend uses that app's id and secret for the REST API
(/apps/chat/events). A wrong secret for an app's id is refused, the same as
any bad signature.
Details
- Limits are per app.
max_connections: 5_000means 5,000 per app, not in total. - Metrics carry an
app="<id>"label when there is more than one app. - Redis and clusters work as before. Every node must list the same apps. Keys in Redis are namespaced by app id.
- Cost. Each app runs its own small set of processes (and its own Redis connections with the Redis backend), so dozens of apps are fine; thousands are not what this is for.