Migration

Migration Strategy

Use phased rollout:

1. Keep your existing clients (pusher-js / Echo), point them to Sockudo host.
2. Move backend event publishing to Sockudo HTTP API or Pusher server SDK targeting Sockudo.
3. Validate auth endpoints and presence behavior.
4. Adopt @sockudo/client only for advanced features (filters/delta).

Client Config Diff (Basic)

// before (hosted Pusher)
new Pusher("app-key", {
  cluster: "eu",
  forceTLS: true,
});

// after (Sockudo)
new Pusher("app-key", {
  cluster: "mt1",
  wsHost: "your.sockudo.host",
  wsPort: 6001,
  wssPort: 443,
  forceTLS: true,
  enabledTransports: ["ws", "wss"],
});

Backend Trigger Diff

Most Pusher server SDKs can target Sockudo by setting host and port.

new Pusher({
  appId: process.env.PUSHER_APP_ID,
  key: process.env.PUSHER_APP_KEY,
  secret: process.env.PUSHER_APP_SECRET,
  host: "your.sockudo.host",
  port: 6001,
  useTLS: false,
});

Compatibility Notes

• Core protocol behavior is Pusher-compatible.
• Signed HTTP API query parameters are required for /apps/* routes.
• Advanced tag filtering and delta decode are not native in stock pusher-js/Echo clients.

Recommended Rollout Checks

• /up and /up/{appId} healthy.
• Private and presence auth succeeds.
• Message fanout latency and ordering match expectations.
• Webhooks and metrics endpoints wired in production.