What is Swagg Bet

Swagg Bet is a crypto-first online casino. Players sign up, fund a wallet with crypto or fiat, play slots and live games sourced from third-party providers, and climb a VIP ladder that pays back a share of their wagering. Behind the scenes, an operations team manages players, promotions, payouts, and marketing through a separate admin panel.

The whole thing lives in a single pnpm + Turborepo monorepo, so the player site, the admin panel, the API, and the shared business logic are versioned and built together.

The moving parts

There are seven apps in the monorepo and a set of shared packages.

App	What it is
apps/web	The player-facing site — lobby, wallet, games, VIP, settings
apps/admin	The back office where operators manage the platform
apps/support	A focused workspace for support agents
apps/api	A Hono API that handles money, game sessions, and webhooks
apps/email	A small service that sends transactional email
apps/docs	This VitePress documentation site
apps/streamer	Worker that streams analytics events into ClickHouse

Most product logic does not live in the apps themselves. It sits in shared packages so the web app, the admin panel, and the API all behave consistently:

• packages/db — the database schema and every query, grouped by domain (users, wallet, segments, support, …).
• packages/wallet — balances, deposits, and the hooks that re-evaluate a player's segments after key events.
• packages/shared — types, the currency list, the fallback game catalog, and the dynamic-segment trigger definitions.
• packages/ui — the player-facing component library.
• packages/auth — NextAuth session handling and the unified token used for cross-origin API calls.
• packages/react-query — client data hooks for web, support, and admin UIs.
• packages/clickhouse — analytics schema and insert helpers.
• packages/email — email templates and Resend client (used by apps/email).
• packages/tailwind-config — shared Tailwind preset.

How a request flows

The player site rarely touches the database directly. It calls the API, which goes through the shared operations and wallet packages:

apps/web  →  apps/api  →  packages/db (operations)
                       →  packages/wallet (balances)
apps/web  →  packages/ui, packages/react-query

The admin panel is a little different. It is a Next.js app that can reach the database directly through packages/db operations, while still funneling sensitive actions (blocking a player, adjusting a balance) through audited operations rather than ad-hoc SQL.

Authentication in one sentence

Sign-in uses NextAuth with a JWT session. That session carries a unified token the browser attaches to every API call, so the same identity works across the web app and the Hono API even though they run on different origins.

Two kinds of "staff"

It is worth separating two ideas early, because they are easy to confuse:

• Admins are back-office users with role-based permissions (players.view, payments.manage, and so on). Roles live in the database, and a seeded superadmin role bypasses every check.
• Support staff are a separate kind of account — agents and managers who only work tickets. They are not the same as admins.

Where features are documented

The rest of these docs are split the same way the product is:

• Player experience covers what a customer can see and do — accounts, wallet & payments, games, rewards, and tips, alerts & support.
• Back office covers the operator tools — the dashboard and access model, players, segments, promotions, the games catalog, withdrawals, and marketing.