Source: https://www.hype-stack.dev/docs/getting-started/technologies

# Technologies

Every dependency in the free Hype Stack starter earns its place. Here is what is inside, how the repository is laid out,
and why each piece is there.

## Runtime zones

| Runtime         | What runs there                                                            | Examples                                       |
| --------------- | -------------------------------------------------------------------------- | ---------------------------------------------- |
| **Browser**     | React UI, TanStack Router, HyperFetch client, theme tokens                 | `apps/frontend`, `apps/admin`                  |
| **Node.js API** | Hono server, Prisma, Kysely, Valkey, S3 client, WebSockets, cron scheduler | `apps/backend`                                 |
| **Electron**    | Same frontend codebase in a native window                                  | `pnpm --filter @hype-stack/frontend start:app` |
| **Mobile**      | Expo app with expo-router and NativeWind                                   | `apps/mobile`                                  |
| **Extension**   | Browser extension UI, same theme tokens                                    | `apps/extension`                               |
| **Local infra** | Postgres, Valkey, object storage                                           | `docker-compose.yml`                           |

Build and tooling (Vite, Nx, Prisma CLI, oxlint) run on Node at the workspace root. They are not part of the production
request path.

## Repository layout

The project is a pnpm monorepo with Nx orchestrating tasks:

```
apps/
  backend/    # Hono API server, Prisma schema, docker-compose.yml
  frontend/   # React SPA (web + Electron)
  admin/      # Operator app, a placeholder home until a starter fills it
  mobile/     # Expo app (expo-router, NativeWind)
  extension/  # Browser extension (Vite, Tailwind)
packages/     # Shared code (enums, types, configs)
nx.json
pnpm-workspace.yaml
stack.json    # apps, paths, installed packs, deploy records
```

Installing a **starter pack** fills `apps/admin` with its login and screens, and adds auth, organizations, permissions,
and admin routes under `apps/backend`. Feature packs (billing, teams, notifications) add more files into those apps.
Every app deploys independently and talks to the API over HTTP, so restarting the API does not rebuild the UI.

### Free template vs pack-added

| Present after `create`                                                         | Arrives with a starter / feature pack    |
| ------------------------------------------------------------------------------ | ---------------------------------------- |
| `apps/backend`, `apps/frontend`, `apps/admin`, `apps/mobile`, `apps/extension` | Admin login, users, orgs, dashboard rows |
| Prisma + Kysely + Valkey + S3 client + scheduler                               | Auth, orgs, invitations, RBAC, flags     |
| Error middleware, websockets, HyperFetch SDK, Paraglide messages               | Billing, teams, notifications, AI chat   |
| Docker Compose, CI, agent rules and skills                                     | Pack-specific env vars and Prisma models |

## Backend

| Technology         | Role                                                                                            |
| ------------------ | ----------------------------------------------------------------------------------------------- |
| **Hono**           | HTTP framework. Fast, typed, runs on Node, Bun, Deno, and edge runtimes.                        |
| **Prisma**         | Schema definition, migrations, and seeding. Also what packs merge into.                         |
| **Kysely**         | Typed query builder for the joins, CTEs, and window functions Prisma cannot express cleanly.    |
| **PostgreSQL**     | Primary database.                                                                               |
| **Valkey (Redis)** | Caching and session storage.                                                                    |
| **Zod**            | Request validation, and the source of the types the frontend SDK reads.                         |
| **croner**         | In-process cron scheduler. Jobs run once per fire across instances via Postgres advisory locks. |
| **pg-boss**        | Task queue on Postgres. Retries with backoff, transactional enqueue, no extra service to run.   |

Two query tools is deliberate. Prisma owns the schema and migrations, Kysely owns the hard queries, and each is used for
what it is good at.

## Frontend

| Technology          | Role                                                                         |
| ------------------- | ---------------------------------------------------------------------------- |
| **React 19**        | UI library.                                                                  |
| **TanStack Router** | Type-safe routing with typed params and plain-function loaders.              |
| **Tailwind CSS**    | Utility-first styling driven by semantic theme tokens.                       |
| **shadcn/ui**       | Accessible component primitives, copied into the repo rather than installed. |
| **HyperFetch**      | Data fetching, caching, and websockets through a generated typed SDK.        |
| **Paraglide**       | Compiled message catalogs (`messages/en.json`). Packs merge their copy in.   |
| **Electron**        | Desktop builds from the same codebase.                                       |

## Mobile

| Technology     | Role                                                                                |
| -------------- | ----------------------------------------------------------------------------------- |
| **Expo**       | The mobile app runtime, with `expo-router` for file-based navigation.               |
| **NativeWind** | Tailwind for React Native, reading the same theme tokens as the web apps.           |
| **EAS**        | Expo's build and submission service, driven by [`deploy mobile`](/docs/cli/deploy). |

Local device testing uses Expo Go from [sign.expo.dev](https://sign.expo.dev/). See [Mobile](/docs/mobile).

## Extension

| Technology       | Role                                                                                      |
| ---------------- | ----------------------------------------------------------------------------------------- |
| **Vite**         | Builds the extension per browser family (chrome and firefox targets).                     |
| **Manifest V3**  | The extension platform format the Chrome, Edge, and Firefox stores accept.                |
| **Tailwind CSS** | Same utility classes and semantic theme tokens as the frontend.                           |
| **Store APIs**   | [`deploy extension`](/docs/cli/deploy) publishes to the Chrome, Edge, and Firefox stores. |

Both apps talk to the same Hono API through HyperFetch, and both are themed by the CLI's theme picker alongside the
frontend and admin.

## Tooling

| Technology         | Role                                                                          |
| ------------------ | ----------------------------------------------------------------------------- |
| **TypeScript 6**   | Typecheck on every app, and the type bridge between backend and clients.      |
| **Vite 8**         | Bundler and dev server for web, admin, extension, and Electron, on Rolldown.  |
| **Nx 23**          | Monorepo task orchestration, so build, test, and lint run in the right order. |
| **pnpm 12**        | Package manager with workspace support.                                       |
| **oxlint / oxfmt** | Linter and formatter, Rust-based and fast enough to run on every save.        |
| **Vitest 5**       | Unit and integration tests on every side, `vitest-native` for mobile.         |
| **Docker Compose** | Local Postgres, Valkey, and RustFS in one command.                            |
| **Sentry**         | Error and performance monitoring, wired but optional.                         |

## How types travel

There is no code generation step to remember and no schema language to maintain. A Hono route validated with Zod exposes
its input and output types, HyperFetch builds a typed SDK from the Hono app type (`registerRoutes` return type), and the
frontend imports only that SDK. Add an endpoint on the backend and it is typed on the client immediately. Change a
response shape and the frontend stops compiling.

Read [end-to-end type safety](/docs/development/e2e-typesafety) for the full chain, and [HTTP](/docs/frontend/http) for
how components call the SDK.

## What the free starter already handles

These are wired before you install a single pack:

- **Error handling.** Typed error classes and one central error middleware that formats responses, logs, and reports to
  Sentry. Route code throws and moves on.
- **Real-time.** Websocket listeners and emitters through the same typed SDK, with reconnection handled.
- **Caching.** Valkey reads and writes that degrade gracefully instead of failing a request.
- **Background jobs.** A cron scheduler that boots with the API. The job list ships empty; packs append entries through
  the manifest, and your own jobs go in `apps/backend/src/jobs/index.ts`.
- **Task queue.** Slow work (file parsing, model calls, batch sends) runs as tasks on Postgres, with retries and a
  concurrency cap. It runs inside the API process, and it costs nothing until a pack registers a queue.
- **Translations.** Paraglide message catalogs in the frontend, admin, mobile, and backend. Add a locale file and every
  pack string is translatable.
- **A dashboard shell.** Sidebar navigation, settings screens, and the layout patterns features plug into.
- **Local infrastructure.** Postgres, Valkey, and RustFS in Docker Compose, plus Prisma migrations against them.
- **CI.** Lint, typecheck, and test pipelines that understand the monorepo graph.

Paid provider integrations, including WorkOS auth and Stripe billing, are not part of the free starter. They arrive with
the packs that need them.

## What the template does not ship

These show up in some other SaaS kits. Here is where each one stands in Hype Stack today:

| Capability                              | Status                                                                                                                                            |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Product analytics (PostHog and similar) | Not included. Add your own client if you need funnels.                                                                                            |
| Feature flags                           | In the two SaaS starters: typed flags defined in code, per-organization overrides, an admin tab. Not in the free starter. No percentage rollouts. |
| Background jobs / cron runners          | In the template: an in-process cron scheduler plus a task queue on Postgres. No broker and no worker to run.                                      |
| API rate limiting                       | Not included in generated apps. See [Security](/docs/getting-started/security).                                                                   |
| i18n framework                          | Paraglide is wired everywhere and every pack ships its copy as messages. Only English is included; you add the other locale files.                |

Documenting the boundaries matters so you do not expect dashboard toggles that are not there.