@slake-dev/server

Backend server for Slake — handles real-time sync via Socket.IO, annotation storage, and GitHub integration.

Install

npm install @slake-dev/server

Usage

Start the server:

npx slake-server

Environment variables

| Variable | Default | Description | |---|---|---| | PORT | 4000 | Server port | | SLAKE_ALLOWED_ORIGINS | http://localhost:3000,http://localhost:4000,http://localhost:5173 | Comma-separated CORS origins | | SLAKE_ORIGIN_ALIASES | — | Comma-separated alias=canonical pairs that share a room (see below) | | GITHUB_TOKEN | — | GitHub personal access token for issue creation | | GITHUB_ENTERPRISE_HOST | — | GitHub Enterprise web/OAuth host, e.g. github.acme.com (see below) | | GITHUB_ENTERPRISE_CLIENT_ID | — | Client ID of the OAuth app registered on the enterprise host | | GITHUB_ENTERPRISE_CLIENT_SECRET | — | Optional — only for revoking the grant on logout | | GITHUB_ENTERPRISE_API | derived | Override the enterprise REST API base (rarely needed) |

GitHub Enterprise

Set GITHUB_ENTERPRISE_HOST + GITHUB_ENTERPRISE_CLIENT_ID to authenticate against a GitHub Enterprise instance instead of public github.com. The REST API base is derived automatically — https://api.<host> for Enterprise Cloud data residency (*.ghe.com), or https://<host>/api/v3 for Enterprise Server. Public github.com sign-in is unchanged when these are unset. A given backend serves public github.com plus one configured enterprise host; the OAuth proxy only talks to those (server-side allow-list). Register an OAuth app on the enterprise host with Device Flow enabled first — full walkthrough in the root README → GitHub Enterprise.

Origin aliases (sharing a room across tunnels)

By default, rooms and storage are scoped per origin so two apps on the same backend stay isolated. That means http://localhost:3000 and an ngrok tunnel pointing at it are treated as different rooms, and users on each can't see each other.

Set SLAKE_ORIGIN_ALIASES to map alias origins to a canonical origin. All matched origins land in the same room and share annotations:

SLAKE_ORIGIN_ALIASES=https://abc123.ngrok-free.dev=http://localhost:3000

Multiple aliases (e.g. one tunnel per teammate) can map to the same canonical:

SLAKE_ORIGIN_ALIASES=https://abc.ngrok-free.dev=http://localhost:3000,https://xyz.ngrok-free.dev=http://localhost:3000

When at least one alias is configured, the server logs a one-time warning if an unaliased origin connects, suggesting the env var to add.

Migration of pre-alias data. Annotations created from an alias origin before SLAKE_ORIGIN_ALIASES was configured were stored under the alias's own slug, not the canonical's. The server lazily migrates these on user-join: when a user joins from an alias origin and the canonical room is empty for that pathname, any annotations under the alias slug are copied over. This mirrors the legacy unscoped-pathname migration and, like that one, covers annotations only — pre-alias threads and replies under alias slugs remain orphaned. In practice this rarely matters because tunnel URLs are usually ephemeral, but if you have long-lived tunnels (paid ngrok reserved domains, etc.) and need full thread migration, file an issue.

License

PolyForm Perimeter 1.0.0