Docs / Getting Started / Introduction
Introduction
Keel is source code, not a hosted service. You buy it once, clone or unzip it, and it's yours: a Next.js 16 App Router codebase with auth, teams and RBAC, three swappable billing providers, AI chat with a credit system, and an admin panel already wired together. The parts every SaaS rebuilds from scratch are done; what's left is the product you're actually trying to ship.
Why it exists
Auth, multi-tenant teams, billing that survives webhook replay and duplicate events, and a credit ledger that can't go negative under concurrent load are all solvable problems, but solving them correctly takes real time, and getting them subtly wrong (a race in a webhook handler, a permission check that's checked in the UI but not the API) is the kind of bug that doesn't show up until production. Keel exists so you start from a version of that plumbing that's already been audited for exactly those failure modes, not a tutorial-grade first pass.
Proven tools underneath, custom code only where it counts
Keel doesn't write its own auth, ORM, payments, or email sending, it wires together libraries that already do those well: Better Auth for sessions, OAuth, and magic links, Drizzle over Postgres for the database, Stripe, Polar, and LemonSqueezy for billing, Resend for transactional email, and shadcn/ui on Tailwind for the interface, with the Vercel AI SDK behind the AI chat feature.
Custom code is reserved for the parts no library ships: a credit ledger that can't go negative under concurrent load, webhook handlers that stay correct across retries and duplicate events from three different billing providers, and the team/RBAC layer (lib/permissions.ts, lib/dal/*.ts) that gates every route the same way. That's the part actually specific to a multi-tenant SaaS, everything else is a well-maintained library doing the job it was already built for.
It's a Next.js app, not a new framework
Keel doesn't wrap Next.js in its own abstraction layer or invent its own conventions for routing, data fetching, or rendering. Every page is a normal App Router route, every mutation is a normal route.ts handler. If something isn't covered in these docs, it's standard Next.js behavior, and the official Next.js documentation is the right place to look, not a separate Keel-specific mental model to learn.
Check the installed Next.js version before assuming an API shape
Keel tracks current Next.js releases, which can differ from what a general-purpose AI assistant's training data expects, APIs, conventions, and file structure have all changed across major versions. AGENTS.md in the repo root flags this explicitly: verify against node_modules/next/dist/docs/ (or the live docs above) before assuming an API shape, rather than trusting memory. The same caution applies to Better Auth, see Auth providers.
Read memory/ before an architectural change
The memory/ folder (architecture.md, conventions.md, decisions.md) and the repo-root AGENTS.md are Keel's AI-native context layer, written so an AI coding assistant (or you) understands why something non-obvious was built the way it was before changing it. architecture.md covers Keel's own design decisions; decisions.md starts empty, it's where you log your own as you build on top. See The memory/ system for the full picture.
Where to go next
Setup gets a local instance running in five steps. Project structure maps out where everything lives and which routes are static versus dynamic.