Referenta is split across several Next.js apps, supporting services (mostly Docker, a couple of standalone Rust binaries), and shared workspace packages. This page is the map: what each piece is, which port it runs on, and how the root pnpm dev command stitches the developer-facing surface together.

For the dev loop and environment model, see Developer Setup. For local-only admin tooling specifics, see Admin App.

Applications

Services

Long-running services live under services/. They split into two groups by lifecycle: services the root pnpm dev command boots locally for the dashboard, and services that only run in production (Railway).

Local (booted by pnpm dev)

Host ports are configurable through KREUZBERG_PORT, PRESIDIO_PORT, GOTENBERG_PORT, PRESS_PORT, REDIS_PORT env vars (see docker-compose.yml). The dashboard reads *_BASE_URL / PRESS_API_UPSTREAM_URL env vars to find them; those URLs are auto-written into apps/dashboard/.env.development.local by supabase/dev.sh (see pnpm dev orchestration below).

Production-only (not booted by pnpm dev)

Local Supabase

The repo root supabase/ directory is the only supported Supabase CLI project. When pnpm db:start (or the supabase/dev.sh wrapper) brings up the local stack, the Docker bundle exposes these ports — declared in supabase/config.toml:

Packages

Shared workspace packages live under packages/:

• packages/ui — shared React component library (shadcn/ui based) consumed by the apps.
• packages/editor — Tiptap v3 rich-text editor used by Research and the Assistant document tools. Carries the collaboration extensions for Yjs-backed editing.
• packages/quill-markdown — small, dependency-free Quill Delta ↔ Markdown converter. Retained to read documents written before the Tiptap migration.
• packages/migration — scripts for converting raw data during data migrations.
• packages/typescript-config — shared TypeScript configurations (base.json, nextjs.json, etc.).

Linting is Biome, configured once at the repo root (biome.json) — there is no shared ESLint package.

What pnpm dev orchestrates

The root pnpm dev runs turbo run dev filtered to the long-running tasks needed for end-to-end dashboard development:

turbo run dev \
  --filter=www \
  --filter=dashboard \
  --filter=docs \
  --filter=@referenta/presidio \
  --filter=@referenta/kreuzberg \
  --filter=@referenta/gotenberg \
  --filter=@referenta/press \
  --filter=@referenta/redis \
  --filter=@referenta/supabase

In plain English, that starts:

• Three Next.js dev servers — dashboard (3000), www (3001), docs (3002).
• Five Docker services — kreuzberg, presidio, gotenberg, press, redis (each via docker compose -f docker-compose.yml up <service>).
• The local Supabase stack — @referenta/supabase is the repo-root supabase/ directory, and its dev script runs supabase/dev.sh. That script starts supabase start if it isn't already running, then writes apps/dashboard/.env.development.local with the local Supabase API URL + anon / publishable / service-role keys, plus REDIS_PUBLIC_URL, KREUZBERG_BASE_URL, PRESIDIO_BASE_URL, GOTENBERG_BASE_URL, and PRESS_API_UPSTREAM_URL. The dashboard auto-points at the local stack on next restart — no manual env wiring needed.

What is not in pnpm dev

These boot separately on purpose:

• apps/admin — start with pnpm --filter admin dev. It targets hosted dev / prod Supabase directly (not local) and shouldn't run alongside the orchestrated local stack by default. See Admin App.
• apps/cms — start with pnpm --filter cms dev. Strapi is only needed when working on CMS-managed marketing content.
• services/external/bundestag — Rust service that runs on Railway in production. Use cargo run inside the service directory when developing against it locally.
• services/uptime-kuma — Railway-only; no local dev mode.