Kirill Dubovitskiy
16ea2acc73
d2d2f730renamed packages/happy-server to happy-server-self-host so the self-host runtime could be published to npm, but that directory is also the production backend, and the rename left /Dockerfile.server and /Dockerfile running `pnpm --filter happy-server ...`. pnpm exits 0 on an unmatched filter, so the production image's build step became a no-op and its CMD became a container that prints one line and exits 0 instead of serving. Production has not been redeployed since. Actually split the two roles: - packages/happy-server goes back to being private "happy-server", the production backend. It is never published, so npm's squatted bare name is irrelevant to it. - packages/happy-server-self-host is a new publishing shell that keeps the published name and version. Its build bun-bundles the sibling's sources/standalone.ts into dist/ and copies prisma/ in, both of which must live inside the package because the runtime resolves migrations from cwd. It asserts its dependency list matches the sibling's, since the bundle externalizes every dependency and drift would otherwise fail at require time. Fixing the Docker filters alone was not enough: `build` now also bundles the npm runtime via bun, which neither image installs, and the full typecheck includes machinesRoutes.spec.ts, which imports happy-app source that the builder stage does not copy. Production therefore gets tsconfig.build.json, which excludes specs, and `build` runs that typecheck only. Every pnpm filter invocation gets --fail-if-no-match so a future rename fails the build instead of silently doing nothing, and Dockerfile.server's CMD no longer depends on the package name at all. Add .github/workflows/server.yml: the server package had no CI coverage, which is why this went unnoticed for 74 days. It typechecks and tests the package and builds both images and boots them, asserting they serve — the only check that catches a no-op CMD. Also revert450f29e9, a hardcoded voice grant for one account that was written to deploy immediately and never shipped.
Happy Docs
This folder documents how Happy works internally, with a focus on protocol, backend architecture, deployment, and the CLI tool. Start here.
Index
- protocol.md: Wire protocol (WebSocket), payload formats, sequencing, and concurrency rules.
- realtime-sync-and-rpc.md: High-level overview of realtime socket management and RPC control flow.
- api.md: HTTP endpoints and authentication flows.
- encryption.md: Encryption boundaries and on-wire encoding.
- backend-architecture.md: Internal backend structure, data flow, and key subsystems.
- deployment.md: How to deploy the backend and required infrastructure.
- cli-architecture.md: CLI and daemon architecture and how they interact with the server.
- multi-process.md: Deeper multi-replica Socket.IO + Redis streams behavior, failure modes, and integration-test history.
- dev-environments.md: Local
environments/data/workflow, lab-rat project provisioning,env:clipassthrough behavior, and daemon usage. - session-protocol.md: Unified encrypted chat event protocol.
- session-protocol-claude.md: Claude-specific session-protocol flow (local vs remote launchers, dedupe/restarts).
- plans/provider-envelope-redesign.md: Proposed replacement for the current provider/session envelope design.
- permission-resolution.md: State-based permission mode resolution across app and CLI (including sandbox behavior).
- happy-wire.md: Shared wire schemas/types package and migration notes.
- voice-architecture.md: ElevenLabs voice assistant integration, session routing, context batching, and VAD detection.
- research/: general research notes and exploratory writeups.
- competition/: competitor research, protocol analysis, and comparison notes.
- competition/AGENTS.md: structure and rules for storing competitor research results without committing raw checkouts.
Conventions
- Paths and field names reflect the current implementation in
packages/happy-server. - Examples are illustrative; the canonical source is the code.