The backend is one pnpm and Turborepo workspace at backend/. It builds a single Node process, apps/core-api, that serves three things at once:
  • The domain REST API under /v1 (Express 5).
  • The auth, billing and admin tier under /api (a Hono app with better-auth, oRPC procedures and the payments webhook, mounted inside Express).
  • Every BullMQ worker and scheduler. There is no separate worker process.
A second app, apps/mcp-server, is a small stdio binary that a coach can run on their own machine. The hosted MCP endpoint (/mcp) lives in core-api.
Older notes describe the web app as the owner of auth and billing and the backend as domain only. That is no longer true. The @repo/auth, @repo/api, @repo/payments, @repo/mail and @repo/database packages now live in this repo and run in the API process. See Legacy docs corrections.

Workspace layout

Two package scopes exist for a historical reason. @perform/* packages were written for this API. @repo/* packages were ported from the web app’s server tier and kept their names and internal imports. See Packages overview.

Runtime dependencies

Request lifecycle

createApp in apps/core-api/src/app.ts builds the middleware chain in this order. Order matters, and the reasons are on the Middleware page. A domain request under /v1 ends in one of two shapes:
Three surfaces use a different shape on purpose: the automation API (/v1/automation), the public signing lane (/v1/public/sign) and everything under /api. See Responses and errors.

Where to go next

Bootstrap and AppContext

What server.ts builds and how modules receive their dependencies.

Route lanes

Every mount point under /v1 and how each one authenticates.

Module pattern

The five-file layout with a real module walked through.

Queues and jobs

Every queue name, what its job does and when it runs.