Infrastructure — How systems are deployed¶

This doc describes where each part of Jadu Auth runs and how it is deployed. It does not describe CI pipelines or workflow files; it focuses on deployment targets and artifacts.

1. Auth backend (be/)¶

What it is: The central auth server (Express, MongoDB, Better Auth). Handles signup, login, sessions, email OTP, SMS OTP (login), password reset, RBAC, and admin API.

Deployment target: AWS App Runner.

Artifact: A Docker image. The image is built from the monorepo root using be/Dockerfile:

Build context is the repo root (so package.json and package-lock.json are available for workspaces).
The Dockerfile copies the root and the workspace directories (fe, be, package), runs npm ci, builds only the backend workspace (npm run build -w jadu-auth-be), then produces a minimal runtime image with production dependencies and the built be/dist output.
Runtime: Node 20, PORT=8080 (App Runner default), start command runs the backend with New Relic loaded (node -r newrelic dist/index.js).

Registry: The image is pushed to Amazon ECR (Elastic Container Registry). The repository name used in deployment is jadu-auth-be. Image tags typically follow the branch (e.g. latest for main, or the branch name for staging).

App Runner: The running service pulls the image from ECR and runs it. You configure environment variables (e.g. MONGODB_URI_JADU_AUTH, BETTER_AUTH_SECRET, BETTER_AUTH_URL, TRUSTED_ORIGINS) and secrets in the App Runner service definition. The backend does not assume a specific CI system; it only assumes that the built image is available in ECR and that App Runner is configured to use it.

Summary: Backend → Docker image (from repo root, be/Dockerfile) → ECR (image name jadu-auth-be) → AWS App Runner.

2. SDK (package/ — @scenarix/jadu-auth)¶

What it is: The npm package consumed by React apps and Node backends for authentication (provider, hooks, JWT verification).

Deployment target: GitHub Packages (npm registry for the @scenarix scope).

Artifact: An npm package. The package is built from the package/ workspace (TypeScript compiled, assets prepared). Publishing is done from the monorepo (e.g. on release or via a manual publish step). Consumers install it with:

npm install @scenarix/jadu-auth

and use the Scenarix GitHub Packages registry. No server is “deployed” for the SDK; it is a library distributed via the registry.

Summary: SDK → built from package/ → published to GitHub Packages as @scenarix/jadu-auth. Consumers pull it via npm with appropriate registry and auth (e.g. GITHUB_PKG_TOKEN or .npmrc).

3. Admin frontend (fe/)¶

What it is: Next.js app that provides an admin UI for the auth service (users, RBAC, invitations, etc.). It talks to the auth backend API.

Deployment target: Typically Vercel (or any host that supports Next.js and monorepos).

Artifact: The frontend is a static/Node build produced from the fe/ directory. The host must be configured to use fe as the root directory (or equivalent) so that build and start commands run in fe/. The repo is the single source; the deployment system builds from the fe workspace only.

Configuration: In production, the frontend must know the auth backend URL (often set via env vars in the host). CORS and TRUSTED_ORIGINS on the backend must include the frontend’s origin.

Summary: Admin frontend → built from fe/ (root directory fe in the repo) → deployed to a host such as Vercel. Backend must allow the frontend origin in TRUSTED_ORIGINS.

4. Playground (package/playground/)¶

What it is: Example React app and Express API that use the SDK and talk to the auth backend. Used for development and demos.

Deployment: The playground is not part of production infrastructure. It is run locally (e.g. via npm run dev from the repo root). No separate deployment target; it is for local or ad-hoc testing only.

5. Dependencies between deployed systems¶

Backend must have: MongoDB (e.g. Atlas), env vars (auth secret, URL, trusted origins, optional mail and JaduSpine).
SDK has no runtime dependency on this repo’s backend; apps that use the SDK point their config at whatever auth server URL they use (this backend or another).
Admin frontend depends on the backend: it calls the backend API, so the backend must be deployed and reachable, and must list the frontend’s origin in TRUSTED_ORIGINS.

Reference¶

System	Deploy target	Artifact / build	Notes
Auth backend	AWS App Runner	Docker image → ECR	Image built from root, `be/Dockerfile`
SDK	GitHub Packages	npm package	Built from `package/`, published to npm
Admin frontend	e.g. Vercel	Next.js app from `fe/`	Root directory = `fe`
Playground	—	—	Local only, not deployed