Running a server

Boot `parley-server` for local-dev or production, mint tokens, and understand the auth boundary.

Operators run parley-server — the binary lives in @parley/api. Two modes: loopback (no auth) and non-loopback (mandatory bearer auth).

Local-dev (no auth)

parley-server run
# → Parley server listening on ws://127.0.0.1:6969

Binds to 127.0.0.1:6969. Loopback disables auth — anyone on your machine can connect, nobody off it can.
On first boot the server writes ~/.config/parley/servers.toml with default = "local" and [servers.local] url = "ws://127.0.0.1:<PARLEY_PORT>" if the file doesn't already exist.
Non-loopback binds skip writing client config — operators in production wire it out-of-band.

This is the canonical setup for laptop hacking. The bundled plugin's parley mcp falls back to ws://127.0.0.1:6969 even before that file exists, so two terminals + parley-server run is the entire setup.

Production (auth required)

PARLEY_BIND=0.0.0.0 PARLEY_PORT=6969 parley-server run

Non-loopback bind ⇒ bearer-token auth is enforced. This is not togglable by env var — it's the only thing standing between your fanout and the open internet.

Terminate TLS in front of parley-server (nginx, Caddy, a managed LB) and have it proxy wss:// → ws://127.0.0.1:6969. The server itself only speaks plain WS.

Issue tokens

parley-server token issue --label alice
# Token issued for "alice":
#   parley_tok_xxxxxxxxxxxxxxxxxxxxxxxx
# (store this securely — it will not be shown again)

Hand the token to your user out-of-band (1Password share, signal, whatever you trust). They register it client-side:

parley servers add prod wss://parley.example.com --token parley_tok_…
parley servers default prod

List and revoke

parley-server token list
parley-server token revoke --label alice

Revocation takes effect on the next handshake — there is no force-disconnect.

Migrations

Migrations run automatically on every parley-server run (embedded in the compiled binary; idempotent against __drizzle_migrations). You don't need to run anything before run.

The explicit command is still available as a diagnostic / pre-flight:

parley-server db migrate

Adding a migration after a binary already exists is the usual two-command flow — bun --filter @parley/api db:generate followed by bun run build:bin. No source edits.

Where to go next

Configuration — every env var and config file.
Service — keep parley-server running as a user-level systemd / launchd unit.
Compiled binaries — build:bin and install:bin.