Tech Stack

GenerateSaaS pairs a Next.js App Router frontend with a fully typed Hono RPC backend, sharing one set of @repo/* packages. Every layer is picked for type safety, deploy portability, and a boilerplate you fully own.

The stack at a glance

Each layer maps to a workspace package or app dependency, with the version pinned in the repo.

There is no @repo/jobs or @repo/cache package - Inngest and Redis both live in @repo/runtime, which the app pulls in transitively through @repo/api.

How the pieces connect

• The Next.js app imports backend logic only through @repo/* packages - never from a sibling app.
• It builds a typed RPC client with hc<AppType>(), so a backend route change surfaces as a frontend type error.
• Server Components read data through the server client; Server Actions and the browser client handle mutations and client reads.
• next-intl drives i18n and next-themes drives dark mode.

Type safety end to end

The same types flow from database to UI with no codegen step.

// Drizzle schema → inferred row types → Hono route → typed RPC client
import { hc } from "hono/client";
import type { AppType } from "@repo/api";

const api = hc<AppType>(process.env.NEXT_PUBLIC_API_URL!);
const res = await api.posts.$get(); // fully typed response, no manual DTOs

The browser client lives in lib/api/client.ts; Server Components and Server Actions use getServerApi() from lib/api/server.ts, which forwards the session cookie.

Frequently asked questions

Do I have to deploy on Vercel? No. The Hono backend and @repo/* packages use web-standard APIs, so you can host on Vercel, Docker, Fly.io, Railway, or any Node host. See deployment.

Is there a separate API server? By default the Hono API runs inside the Next.js app. You can split it into a standalone backend later - see separate backend.

Is Redis optional? No. Redis backs caching, the rate limiter, and the distributed mutex in every environment. The self-hosted choice uses ioredis and requires REDIS_URL; the Upstash choice uses @upstash/redis and requires UPSTASH_REDIS_REST_URL + UPSTASH_REDIS_REST_TOKEN - see environment variables.

Where do I configure which features are on? Feature flags live in @repo/config; the typed client and env vars are wired around them. Start with configuration.

Can I still add more shadcn/ui components? Yes. Every components.json pins the base-vega style, so pnpm dlx shadcn add <component> fetches the Base UI build and it drops into @repo/ui-next matching the components already there. Leave that style value alone - changing it pulls a different primitive library into the same app.

Why are dropdown menus and selects frosted glass? Because components.json sets "menuColor": "default-translucent". The vega registry ships menu components with cn-menu-target and cn-menu-translucent markers, and the CLI rewrites those markers at add time into a real surface based on this setting - a bg-popover/70 panel with a blurred before: layer. The markers are build-time only: they are never CSS classes, and if you ever see one survive into a component file, that file was written without the transform running and the panel will render flat. The other values are default, inverted, and inverted-translucent. Change it in every components.json at once, or newly added menus will not match the ones you already have.

The blur strength that setting produces - backdrop-blur-2xl, 40px - is the house standard for every floating panel and for the navbar chrome. The registry only reaches dropdown menus and selects, so popover.tsx, navigation-menu.tsx, the navbar and the bottom nav carry the same surface by hand. Match it on anything new you float over the page.