Self-host Production Starter
Product-neutral self-host starter

Self-host Production Starter

A fork-ready Docker monorepo for real web apps: SSR storefront, SPA-style admin console, typed Hono API, app-scoped auth, PostgreSQL, S3, BullMQ, Valkey, and WebSockets.

Services
3
Contract
Typed
Gate
verify

What ships

A starter that already has the hard edges.

The repo is intentionally product-neutral, but it starts with the infrastructure most production web apps need before the first product feature lands.

Three service boundary
Separate API, storefront, and admin services communicate over HTTP so sensitive infrastructure stays server-side.
Typed API spine
Hono AppType flows into the shared API client for storefront SSR reads and TanStack Query hooks.
App-scoped auth
Per-app cookies, JWT audience checks, explicit scopes, RBAC permissions, CSRF, and rate limits are wired in.
Open service adapters
PostgreSQL/PostGIS, S3-compatible uploads, Valkey state, BullMQ jobs, and WebSockets are represented in the stack.

Request path

One route, one contract, one data path.

The default architecture keeps product code easy to trace from the browser to storage.

  1. 01

    SSR storefront

    Public routes render on the server and pass interactive work to focused client islands.

  2. 02

    Typed client

    Hooks call the shared Hono RPC client, not hand-written fetch wrappers.

  3. 03

    API route

    Routes validate, authorize, and map service results to HTTP responses.

  4. 04

    Feature service

    Use cases, ownership, idempotency, and transitions live in one place.

  5. 05

    Store and bindings

    Repositories shape Drizzle queries and never return raw rows to the SPA.

Enforced discipline

The starter keeps architecture drift visible.

Custom checks catch the common regressions that make a starter decay after the first few features.

Frontend boundary check

No server actions or direct data-layer imports in storefront or admin apps.

API route boundary

Product routes go through feature services instead of bypassing the use-case layer.

Migration and timestamp checks

Drizzle schema remains the source of truth with timezone-aware database timestamps.

Locale parity

English and Thai message catalogs stay aligned across both frontend apps.

Single verification gate

Format, typecheck, unit, integration, e2e, dry-run, compatibility, and build run under pnpm verify.

Start with the stack, then replace the product surface.

Keep the contracts and guardrails; swap the content and domain model for the real app.