ghostbus 0.5.5 → 0.5.6

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## 0.5.6 — 2026-10-11
+
+Security hardening, round 5 — load & abuse resilience: what happens when many agents share one process for a long time. This round built the first repeatable load bench before changing anything, and the honest headline is that load broke no correctness property — zero errors, zero lost writes, exact reconciliation at every size. What it (and the audit around it) found instead: an unbounded subscription surface, missing server timeouts whose platform defaults do not do what their names suggest, and a measured, structural scaling limit that is now documented instead of discovered by operators.
+
+- **Load bench (`scripts/load-bench.mjs`, new)** — boots the real hosted server with per-agent tokens enforced and drives N agents through mixed operations (register, heartbeat, send, inbox, task create→claim→complete, file put), reporting ops, errors, and p50/p95 latency per op class, plus a hard reconciliation: messages sent == messages stored, tasks created == tasks completed, files put == files stored. Baseline on the development machine (Node 24): **25 agents × 30 s → 2,506 ops, ~83 ops/s, 0 errors**, p50 ~280–360 ms / p95 ~390–595 ms per op class, reconciled exactly (650 messages, 300/300 tasks, 300 files); **25 agents × 60 s → 3,438 ops, ~57 ops/s, 0 errors**, also exact. Repeat 30 s runs on this shared VM varied between ~55 and ~112 ops/s with machine load; the invariants across every run were 0 errors and exact reconciliation. A reduced smoke (6 agents × 3 s) runs in the suite. One bench disclosure: at the shipped 300 req/min per-IP limiter, a single-IP bench measures the limiter, not the bus, so the bench raises that one knob for itself (printed in its output); every other limit is at its shipped default.
+- **What the load actually showed** — throughput declines as a workspace's state grows (~83 → ~57 ops/s across the captured 30 s/60 s pair as the state file grew ~0.9 → ~1.2 MB, p95 latency roughly doubling) because every operation loads and re-saves the whole state file (O(state) per op) and all operations serialize on the per-workspace lock: with 25 agents queued, most of the p50 is queue wait. Memory plateaued (RSS oscillated in a ~140–260 MB band under sustained load — garbage collection keeping up with per-op state copies), it did not grow with op count. No fix is claimed for the scaling shape: it is the single-file store's documented trade-off, now with numbers, in `docs/hosted.md` ("Capacity & limits"). Trims (10k messages / 5k events / per-file history) held throughout.
+- **SSE subscriptions were unbounded (fixed)** — before this round, any number of `/api/stream` connections could be held per workspace, each one a permanent bus listener plus a 25 s ping timer, reaped only on socket close. There are now caps, checked before the stream opens: **100 per workspace** (`GHOSTBUS_MAX_STREAMS_PER_WORKSPACE`) and **1000 per server** (`GHOSTBUS_MAX_STREAMS_TOTAL`), with a clean `429` JSON refusal over the cap. Cleanup is now idempotent across close/error/write-failure paths, and the suite proves the cap, that a freed slot reopens, and that bus listener counts return to exactly zero after stream churn — no listener leaks.
+- **Explicit server timeouts on both servers** — slow-loris room is closed. Both HTTP servers now take commented deadlines (defaults: headers 10 s, request body 30 s, keep-alive 5 s; overridable via `GHOSTBUS_HEADERS_TIMEOUT_MS` / `GHOSTBUS_REQUEST_TIMEOUT_MS`). The implementation notes are in the code because the platform defaults mislead: Node's own header enforcement was probed to leave a partial-headers socket alive past 15 s in this configuration, and its `requestTimeout` semantics proved unsafe to reason about for long-lived responses, so that property is pinned to 0 and both deadlines are enforced by a small connection-level guard that only ever destroys a socket whose request is genuinely incomplete. The guard's first cut armed its body timer on `req.complete` — which stays false for a bodyless GET nobody reads, exactly the `/api/stream` shape — and killed live streams in testing; the shipped guard arms only on a *declared* body (Content-Length / Transfer-Encoding). The suite proves all of it at tightened deadlines (400 ms / 800 ms): a partial-headers socket dies at the header deadline, a slow body drip dies at the body deadline, and an SSE stream plus a 2 s long-poll outlive both.
+- **Recovery drill (new suite proof)** — while three agents write against a hosted FileStore workspace, the server is SIGKILLed mid-load and restarted on the same data directory. Assertions: the state file parses (temp-file + atomic rename means a kill strands at most an inert `.tmp`), every operation already answered HTTP 200 is present after restart, each agent's stored messages form a contiguous prefix of its attempts (nothing half-applied), acked files are present, and the restarted server's counts agree with the file. This is the durability claim for the JSON store, stated at its true scope: single file, one writer process, last-writer semantics per op.
+- **Long-poll pile-up (new suite proof)** — 25 concurrent `/api/wait` holders all wake with the event on a single broadcast (none hang, none miss it), and 10 idle waits all resolve on their own timeout with `waited: true` and no events, with no unhandled rejections in the server log.
+- **Limiter hygiene** — the per-IP/workspace rate limiter is now tunable (`GHOSTBUS_RATE_LIMIT_PER_MIN`, default unchanged at 300) and its over-limit message reports the live value; the limiter map and the hosted failed-auth map prune stale buckets opportunistically instead of only ever growing under address churn.
+- **Tests** — five new checks (69 in the main suite, was 64): bench smoke with exact reconciliation, server timeouts (loris + drip + SSE/long-poll survival), SSE caps + reaping, wait pile-up, and the SIGKILL recovery drill. The suite now takes ~22 s because three of the new checks are real-time proofs (a 3 s bench window, a 2 s long-poll, a 1.2 s kill drill) — that time is the evidence, not overhead. Serverless stays 6/6 and both demos pass.
+- **Scope boundary, honestly** — what did NOT change: the storage format and every API shape are untouched; the local trust model is untouched; the bench figures are one machine's evidence, not a hosted SLA; and the networked multi-writer store remains future work — this round measured the single-file store's limits rather than relitigating them.
+
 ## 0.5.5 — 2026-10-11
 
 Security hardening, round 4 — the client side of the wire. Rounds 2–3 hardened what the server stores and how it authenticates; this round fuzzed what a client can *send*: MCP tool arguments over stdio JSON-RPC, board payloads end-to-end, and raw HTTP parameters. One real crash, a class of silent state corruption, and a set of numeric edge cases were found and fixed. Several surfaces audited clean and are now pinned by tests instead — the entry says which, as usual.

package/README.md

@@ -23,7 +23,7 @@ Built and in use: 29 MCP tools across presence, messages, tasks, a shared worksp
 ```bash
 git clone https://github.com/littlestjames82-sys/ghostbus.git ghostbus && cd ghostbus
 node examples/two-agent-demo.mjs   # watch a planner and a builder cooperate
-node test.mjs                      # 64 checks: core, tokens, capsules, dependencies, sync, persistence, concurrency, MCP stdio, HTTP, SSE, CLI, hosted security, hostile input, input fuzz
+node test.mjs                      # 69 checks: core, tokens, capsules, dependencies, sync, persistence, concurrency, MCP stdio, HTTP, SSE, CLI, hosted security, hostile input, input fuzz, load & resilience
 node examples/three-agent-team.mjs # planner + builder + reviewer, no human relaying
 ```
 

package/docs/hosted.md

@@ -189,6 +189,67 @@ including MCP clients and any agent driving one:
   and referers. `/health` and `/probe` return exactly their documented
   counts-only shapes.
 
+## Capacity & limits (measured, v0.5.6)
+
+First published load figures, from `scripts/load-bench.mjs` — a repeatable
+bench that boots the real hosted server (per-agent tokens enforced) and
+drives N agents through mixed register/heartbeat/send/inbox/task/file
+operations, then reconciles the final state **exactly** (messages sent ==
+messages stored, tasks created == tasks completed, files put == files
+stored). One development machine (Node 24, local disk); treat these as
+evidence about the shape of the limits, not as a hosted SLA.
+
+| run | ops | throughput | errors | latency (p50 / p95) |
+|---|---|---|---|---|
+| 25 agents × 30 s | 2,506 | ~83 ops/s | 0 | ~280–360 ms / ~390–595 ms per op class |
+| 25 agents × 60 s | 3,438 | ~57 ops/s | 0 | ~315–470 ms / ~910–1,870 ms per op class |
+
+Repeat runs vary with machine load — five 30 s runs on the shared
+development VM landed between ~55 and ~112 ops/s. What did not vary, in
+any run: **0 errors, and exact reconciliation.**
+
+What the numbers mean:
+
+- **Correctness holds under concurrency.** Zero errors and exact
+  reconciliation at every size — the per-workspace lock serializes
+  operations, so nothing is lost or double-applied.
+- **Throughput is bounded by design, and declines as a workspace grows.**
+  Every operation loads and re-saves the workspace's whole state file, so
+  per-operation cost is O(state size), and operations queue behind each
+  other: with 25 agents active, most of the ~300 ms p50 is queue wait, not
+  work. The 60 s run is slower per op than the 30 s run because its state
+  file grew from ~0.9 MB to ~1.2 MB during the run. History trims (10k
+  messages, 5k events, per-file history) bound how large that cost can
+  get, but a hot workspace is a real cost center — split hot work into
+  more workspaces rather than feeding one forever.
+- **Memory plateaus.** Under sustained load the server's RSS climbed,
+  then oscillated in a ~140–260 MB band (garbage collection keeping up
+  with per-operation state copies). It did not grow linearly with the
+  operation count; no leak was found.
+- **Durability under a hard kill is proven, not assumed.** The suite's
+  recovery drill SIGKILLs the server mid-load and restarts on the same
+  data directory: the state file parses (writes are temp-file + atomic
+  rename, so a kill can strand at most an inert `.tmp` file), every
+  operation the server had already answered with HTTP 200 is present, and
+  each agent's stored messages form a contiguous prefix of what it
+  attempted — nothing half-applied.
+
+Abuse limits an operator can tune (environment variables):
+
+| variable | default | meaning |
+|---|---|---|
+| `GHOSTBUS_MAX_STREAMS_PER_WORKSPACE` | 100 | concurrent `/api/stream` subscribers per workspace; over the cap → `429` |
+| `GHOSTBUS_MAX_STREAMS_TOTAL` | 1000 | concurrent streams across the whole server (hosted) |
+| `GHOSTBUS_HEADERS_TIMEOUT_MS` | 10000 | deadline for a client to deliver complete request headers |
+| `GHOSTBUS_REQUEST_TIMEOUT_MS` | 30000 | deadline to deliver a declared request body (never bounds a response — SSE and long-poll outlive it by design) |
+| `GHOSTBUS_RATE_LIMIT_PER_MIN` | 300 | per-IP, per-workspace request budget (the v0.4 limiter, now tunable) |
+
+When to scale out: one process serving a handful of team-sized workspaces
+is the design point. If a single workspace's sustained op rate or state
+size becomes the bottleneck, the honest answer today is "more, smaller
+workspaces" — the networked multi-writer store that would lift the
+single-file ceiling is documented future work, not a flag you can flip.
+
 ## Option B — serverless on Netlify (Blobs)
 
 `deploy/netlify/` contains a Netlify Function implementing the same multi-workspace semantics over Netlify Blobs (strong consistency):

package/package.json

@@ -44,5 +44,5 @@
     "hosted": "node src/hosted-server.mjs"
   },
   "type": "module",
-  "version": "0.5.5"
+  "version": "0.5.6"
 }

package/src/core.mjs

@@ -14,7 +14,7 @@ import path from 'node:path';
 import crypto from 'node:crypto';
 import { AsyncLocalStorage } from 'node:async_hooks';
 
-export const GHOSTBUS_VERSION = '0.5.5';
+export const GHOSTBUS_VERSION = '0.5.6';
 const sha256 = (s) => crypto.createHash('sha256').update(String(s)).digest('hex');
 // Timing-safe equality for hex digests (v0.5.3): secret comparisons must not
 // short-circuit on the first differing character the way === does.

package/src/handler.mjs

@@ -75,16 +75,117 @@ export const HTML_SECURITY_HEADERS = {
 
 const TOO_LARGE = Symbol('body-too-large');
 
+// Per-IP request limiter (per workspace — one handler serves one workspace).
+// The default (300/min) is unchanged since v0.3; GHOSTBUS_RATE_LIMIT_PER_MIN
+// is an operator knob for two legitimate cases: many agents behind one NAT
+// address sharing a single source IP, and load benchmarking, where the
+// limiter — not the bus — would otherwise be the first ceiling (v0.5.6).
+const rateLimitPerMin = () => {
+  const n = Number(process.env.GHOSTBUS_RATE_LIMIT_PER_MIN);
+  return Number.isFinite(n) && n >= 1 ? Math.floor(n) : 300;
+};
+
+// Server timeouts (v0.5.6). Three different clocks, three different jobs:
+// - headersMs bounds how long a client may take to deliver complete request
+//   HEADERS (the classic slow-loris drip).
+// - requestMs bounds how long it may take to deliver the request BODY after
+//   that. It must never bound a response: /api/stream and /api/wait are
+//   long-lived BY DESIGN.
+// - keepAliveMs is Node's own idle keep-alive lifetime.
+// Why this is not just "set the three Node properties": Node's own
+// enforcement of both knobs was probed on Node 24 before this design was
+// chosen, and neither is a deterministic drop-in for the deadlines above.
+// - server.headersTimeout IS set (it only governs the header phase), but
+//   its enforcement rides on Node's socket-timeout machinery: with the
+//   default server.timeout of 0, a partial-headers socket was probed to
+//   survive 15 s at headersTimeout=1000.
+// - server.requestTimeout is pinned to 0: its semantics proved impossible
+//   to reason about safely for long-lived responses (a handler that
+//   writes constantly masks its clock entirely), and the deadline it is
+//   documented for — receiving the request — is exactly the one the
+//   guard below enforces deterministically instead.
+// The guard: arm the header deadline on connect, clear it when headers
+// land, bound a *declared* body from there, re-arm while the socket sits
+// between keep-alive requests. server.timeout stays 0 on purpose — socket
+// *inactivity* is not a deadline here, because a long-poll legitimately
+// idles for up to 55 s and an SSE stream between events for longer.
+export const SERVER_TIMEOUT_DEFAULTS = { headersMs: 10_000, requestMs: 30_000, keepAliveMs: 5_000 };
+export function applyServerTimeouts(server, opts = {}) {
+  const headersMs = opts.headersMs ?? SERVER_TIMEOUT_DEFAULTS.headersMs;
+  const requestMs = opts.requestMs ?? SERVER_TIMEOUT_DEFAULTS.requestMs;
+  const keepAliveMs = opts.keepAliveMs ?? SERVER_TIMEOUT_DEFAULTS.keepAliveMs;
+  server.headersTimeout = headersMs;
+  server.requestTimeout = 0; // see above — Node's clock kills live streams; the guard owns this deadline
+  server.keepAliveTimeout = keepAliveMs;
+  server.timeout = 0; // see above — inactivity is not the deadline
+  server.on('connection', (socket) => {
+    const armHeaderDeadline = () => {
+      clearTimeout(socket._gbHeaderTimer);
+      socket._gbHeaderTimer = setTimeout(() => socket.destroy(), headersMs);
+      socket._gbHeaderTimer.unref?.();
+    };
+    socket._gbArmHeaderDeadline = armHeaderDeadline;
+    armHeaderDeadline();
+    socket.on('close', () => clearTimeout(socket._gbHeaderTimer));
+  });
+  server.on('request', (req, res) => {
+    const socket = req.socket;
+    clearTimeout(socket._gbHeaderTimer); // headers are in — that deadline is met
+    clearTimeout(socket._gbBodyTimer);
+    // Bound the body ONLY when one was declared. req.complete cannot be
+    // the trigger: for a bodyless GET whose stream nobody reads (exactly
+    // the /api/stream and /api/wait shape) it stays false indefinitely, so
+    // a timer armed on it would destroy healthy long-lived exchanges —
+    // the first cut of this guard did precisely that to SSE streams.
+    const declaresBody = Number(req.headers['content-length'] || 0) > 0 || 'transfer-encoding' in req.headers;
+    if (declaresBody && !req.complete) {
+      socket._gbBodyTimer = setTimeout(() => socket.destroy(), requestMs);
+      socket._gbBodyTimer.unref?.();
+      const clear = () => clearTimeout(socket._gbBodyTimer);
+      req.on('end', clear);
+      req.on('close', clear);
+      res.on('finish', clear);
+      res.on('close', clear);
+    }
+    // Between keep-alive requests the socket owes us a fresh set of
+    // headers: re-arm the header deadline when this exchange finishes so a
+    // stalled *next* request is bounded too. A still-open response (SSE)
+    // never emits 'finish', and its request completed on arrival, so no
+    // timer is ever pending against a live stream or long-poll.
+    res.on('finish', () => { if (!socket.destroyed && socket._gbArmHeaderDeadline) socket._gbArmHeaderDeadline(); });
+    res.on('close', () => clearTimeout(socket._gbHeaderTimer));
+  });
+  return server;
+}
+
+// SSE stream caps (v0.5.6): before this round a workspace's /api/stream
+// subscribers were bounded by nothing but the request limiter — each one
+// holds a bus listener, a socket, and a 25 s ping interval, forever, and a
+// buggy client reconnect-looping could pile them up without limit. Caps are
+// generous against real teams (an agent holds at most a stream or two) and
+// refuse cleanly with 429 past them. The per-process total spans every
+// handler in the process, which is what protects the hosted server.
+const streamCap = (envName, def) => {
+  const n = Number(process.env[envName]);
+  return Number.isFinite(n) && n >= 1 ? Math.floor(n) : def;
+};
+let activeStreamsTotal = 0;
+
 export function createBusHandler({ id = 'default', bus, key = '' }) {
   const buckets = new Map();
+  const rateLimit = rateLimitPerMin();
   const rateOk = (req) => {
     const ip = (req.socket && req.socket.remoteAddress) || 'unknown';
     const t = Date.now();
+    // Opportunistic sweep: one bucket per source IP per minute would
+    // otherwise accumulate forever on a long-lived server (v0.5.6).
+    if (buckets.size > 4096) { for (const [k, v] of buckets) if (t - v.start > 60_000) buckets.delete(k); }
     let b = buckets.get(ip);
     if (!b || t - b.start > 60_000) { b = { start: t, count: 0 }; buckets.set(ip, b); }
     b.count += 1;
-    return b.count <= 300;
+    return b.count <= rateLimit;
   };
+  let activeStreams = 0; // this workspace's live /api/stream subscribers
   const keyOk = (req) => {
     if (!key) return true;
     const given = req.headers['x-bus-key'] || String(req.headers.authorization || '').replace(/^Bearer\s+/i, '');
@@ -99,7 +200,7 @@ export function createBusHandler({ id = 'default', bus, key = '' }) {
       res.writeHead(status, { 'content-type': type }); res.end(body);
     };
     if (!rateOk(req) && url.pathname !== '/health' && url.pathname !== '/probe') {
-      return send(429, { error: 'rate limit: 300 requests/min per IP per workspace' });
+      return send(429, { error: `rate limit: ${rateLimit} requests/min per IP per workspace` });
     }
     const send413 = () => {
       try {
@@ -124,15 +225,34 @@ export function createBusHandler({ id = 'default', bus, key = '' }) {
       if (req.method === 'GET' && url.pathname === '/api/stream') {
         const agent = url.searchParams.get('agent');
         if (!agent) return send(400, { error: 'agent query param required' });
+        // Stream caps (v0.5.6): refuse BEFORE opening the stream — a 429 the
+        // client can back off from, not a socket that dies later.
+        const maxPerWorkspace = streamCap('GHOSTBUS_MAX_STREAMS_PER_WORKSPACE', 100);
+        const maxTotal = streamCap('GHOSTBUS_MAX_STREAMS_TOTAL', 1000);
+        if (activeStreams >= maxPerWorkspace) return send(429, { error: `too many event streams for this workspace (limit ${maxPerWorkspace})` });
+        if (activeStreamsTotal >= maxTotal) return send(429, { error: `too many event streams on this server (limit ${maxTotal})` });
+        activeStreams += 1; activeStreamsTotal += 1;
         res.writeHead(200, { 'content-type': 'text/event-stream', 'cache-control': 'no-cache', connection: 'keep-alive' });
         res.write(`event: ready\ndata: ${JSON.stringify({ agent, workspace: id, version: GHOSTBUS_VERSION })}\n\n`);
+        let cleaned = false;
         const off = bus.onEvent((ev) => {
           const forMe = ev.type === 'message.send' ? (ev.to === agent || ev.to === '*' || ev.actor === agent) : true;
           if (!forMe) return;
-          res.write(`event: ${ev.type}\ndata: ${JSON.stringify(ev)}\n\n`);
+          try { res.write(`event: ${ev.type}\ndata: ${JSON.stringify(ev)}\n\n`); } catch { cleanup(); }
         });
-        const ping = setInterval(() => res.write(': ping\n\n'), 25000);
-        req.on('close', () => { clearInterval(ping); off(); });
+        const ping = setInterval(() => { try { res.write(': ping\n\n'); } catch { cleanup(); } }, 25000);
+        // Reaping (v0.5.6): whichever side of the connection dies first —
+        // request close, response close, or a write into a dead socket —
+        // the listener, the ping, and both cap slots are released exactly
+        // once, so churn can neither leak listeners nor strand cap slots.
+        function cleanup() {
+          if (cleaned) return; cleaned = true;
+          clearInterval(ping); off();
+          activeStreams -= 1; activeStreamsTotal -= 1;
+        }
+        req.on('close', cleanup);
+        res.on('close', cleanup);
+        res.on('error', cleanup);
         return;
       }
 

package/src/hosted-server.mjs

@@ -37,7 +37,7 @@ import fs from 'node:fs';
 import path from 'node:path';
 import crypto from 'node:crypto';
 import { createBus, FileStore, GHOSTBUS_VERSION, validateSnapshot } from './core.mjs';
-import { createBusHandler, keyMatches, hashMatches, readJsonBody, MAX_BODY_BYTES, HTML_SECURITY_HEADERS } from './handler.mjs';
+import { createBusHandler, keyMatches, hashMatches, readJsonBody, MAX_BODY_BYTES, HTML_SECURITY_HEADERS, applyServerTimeouts, SERVER_TIMEOUT_DEFAULTS } from './handler.mjs';
 
 const argv = process.argv.slice(2);
 const argVal = (flag) => { const i = argv.indexOf(flag); return i >= 0 ? argv[i + 1] : null; };
@@ -145,6 +145,9 @@ const authThrottled = (ip) => {
 };
 const noteAuthFail = (ip) => {
   const t = Date.now();
+  // Opportunistic sweep (v0.5.6): one entry per attacking IP per window
+  // would otherwise accumulate forever on a long-lived server.
+  if (authFails.size > 4096) { for (const [k, v] of authFails) if (t - v.start > AUTH_FAIL_WINDOW_MS) authFails.delete(k); }
   let b = authFails.get(ip);
   if (!b || t - b.start > AUTH_FAIL_WINDOW_MS) { b = { start: t, count: 0 }; authFails.set(ip, b); }
   b.count += 1;
@@ -316,6 +319,15 @@ const server = http.createServer(async (req, res) => {
   }
 });
 
+// Explicit server timeouts (v0.5.6): slow-loris header/body deadlines, set
+// here rather than inherited from Node defaults — see applyServerTimeouts
+// in handler.mjs for the scoping (long-lived streams are never bounded).
+const timeoutOpt = (envName, def) => { const n = Number(process.env[envName]); return Number.isFinite(n) && n > 0 ? Math.floor(n) : def; };
+applyServerTimeouts(server, {
+  headersMs: timeoutOpt('GHOSTBUS_HEADERS_TIMEOUT_MS', SERVER_TIMEOUT_DEFAULTS.headersMs),
+  requestMs: timeoutOpt('GHOSTBUS_REQUEST_TIMEOUT_MS', SERVER_TIMEOUT_DEFAULTS.requestMs),
+});
+
 server.listen(port, () => {
   process.stderr.write(`ghostbus HOSTED v${GHOSTBUS_VERSION} · http://127.0.0.1:${port} · data=${dataDir} · workspaces=${Object.keys(loadRegistry().workspaces).length} · agentTokens=${REQUIRE_TOKENS ? 'enforced' : 'issued, not enforced'}\n`);
 });

package/src/http-server.mjs

@@ -14,7 +14,7 @@
  */
 import http from 'node:http';
 import { createBus, MemoryStore, FileStore, GHOSTBUS_VERSION } from './core.mjs';
-import { createBusHandler } from './handler.mjs';
+import { createBusHandler, applyServerTimeouts, SERVER_TIMEOUT_DEFAULTS } from './handler.mjs';
 
 const argv = process.argv.slice(2);
 const argVal = (flag) => { const i = argv.indexOf(flag); return i >= 0 ? argv[i + 1] : null; };
@@ -32,6 +32,14 @@ const server = http.createServer((req, res) => {
   const url = new URL(req.url, 'http://localhost');
   handle(req, res, url).catch((e) => { process.stderr.write(`ghostbus relay: internal error: ${(e && e.stack) || e}\n`); try { res.writeHead(500, { 'content-type': 'application/json' }); res.end(JSON.stringify({ error: 'internal error' })); } catch {} });
 });
+// Explicit server timeouts (v0.5.6): slow-loris header/body deadlines, set
+// here rather than inherited from Node defaults — see applyServerTimeouts
+// in handler.mjs for the scoping (long-lived streams are never bounded).
+const timeoutOpt = (envName, def) => { const n = Number(process.env[envName]); return Number.isFinite(n) && n > 0 ? Math.floor(n) : def; };
+applyServerTimeouts(server, {
+  headersMs: timeoutOpt('GHOSTBUS_HEADERS_TIMEOUT_MS', SERVER_TIMEOUT_DEFAULTS.headersMs),
+  requestMs: timeoutOpt('GHOSTBUS_REQUEST_TIMEOUT_MS', SERVER_TIMEOUT_DEFAULTS.requestMs),
+});
 server.listen(port, () => {
   process.stderr.write(`ghostbus http relay v${GHOSTBUS_VERSION} · http://127.0.0.1:${port} · store=${storePath} · auth=${KEY ? 'workspace key required' : 'open (set GHOSTBUS_KEY)'}\n`);
   // Node's listen() with no host binds ALL network interfaces, not just