Local daemon lifecycle for command-line applications: state bookkeeping, detached spawning, health polling, and the up / down / status / logs / reset surface.

createDaemonKit() owns the parts every local daemon repeats — a state directory holding state.json, pid, and server.log; an atomic state write; detached spawn with the log file as stdio; health polling until the listener answers; SIGTERM with a grace period before SIGKILL. An application contributes only its own config: where its home directory is, how to find its entrypoint, how to probe health, and what extra fields status should show.

const kit = createDaemonKit({
  bin: { installHint: 'Install my-daemon.', resolveFromUrl: import.meta.url },
  dirName: 'my-daemon',
  displayName: 'my daemon',
  health: { path: '/health' },
  homeDir: () => path.join(homedir(), '.myapp'),
  host: nodeProcessHost,
  baseUrl: state => `http://127.0.0.1:${state.port}`,
})

await kit.up(() => ({
  buildState: pid => ({ pid, port: 8080, startedAt: new Date().toISOString() }),
  env: process.env,
  healthUrl: 'http://127.0.0.1:8080',
  timeoutMs: 10_000,
}))

Output routes through the kit-supplied ProcessHost, so a spec can drive the whole surface against a recording host. Colors are the application's to supply through the optional style hook — the kit owns message text and layout and stays dependency-free.

status() and logs() return their exit code rather than assigning process.exitCode, so the caller keeps exit-code authority. The status convention is 0 healthy, 2 running but unresponsive, 3 not running.