@shaferllc/keel 0.83.5 → 0.83.7

package/llms-full.txt

@@ -7,6 +7,357 @@ https://github.com/shaferllc/keel/blob/main/docs. Generated by `npm run build:ai
 
 
 
+---
+
+<!-- source: docs/from-install-to-deploy.md -->
+
+# From install to deploy
+
+One path from zero to a live Keel app — locally, on Cloudflare yourself, or on
+**Keel Cloud** with an AI agent. Pick the track that matches how you want to
+ship; everything else is optional.
+
+```text
+  create-keeljs  →  npm run dev  →  (optional MCP)  →  deploy
+                                              ↘
+                                         Keel Cloud (optional)
+```
+
+## Requirements
+
+- Node.js **≥ 22**
+- npm
+- For self-hosted edge deploys: a [Cloudflare](https://dash.cloudflare.com) account
+  and [Wrangler](https://developers.cloudflare.com/workers/wrangler/) (ships with
+  the kits as a devDependency)
+- For Keel Cloud: an invite / allowlisted email at [app.keeljs.cloud](https://app.keeljs.cloud)
+  during private alpha
+
+## 1. Create an app
+
+```bash
+npm create keeljs@latest my-app                 # full-stack "app" preset (default)
+# npm create keeljs@latest my-api  -- --preset api
+# npm create keeljs@latest my-saas -- --preset saas
+# npm create keeljs@latest bare    -- --preset minimal
+cd my-app
+npm install
+cp .env.example .env                            # if the kit didn't already
+```
+
+| Preset | Use when |
+|--------|----------|
+| `minimal` | Hello-world / learning — routes, a view, Tailwind. No database. |
+| `api` | JSON API — models, migrations, token auth, OpenAPI, tests. |
+| `app` *(default)* | Product with views, sessions, register/login, password reset, 2FA. |
+| `saas` | Multi-tenant product — teams, roles, invitations, billing. |
+
+Templates live **inside** `@shaferllc/keel`, so the kit version matches the
+framework version you just installed. Details: [Starter kits](./starter-kits.md).
+
+## 2. Run it locally
+
+```bash
+npm run migrate          # if the preset has a database (api / app / saas)
+npm run dev              # http://localhost:3000 — Node + local SQLite
+```
+
+Useful next commands:
+
+```bash
+npm run keel -- routes                 # what is mounted
+npm run keel -- make:controller Post   # scaffold, then wire a route
+npm test
+npm run typecheck
+```
+
+Local tip: `DB_CONNECTION` defaults to a SQLite file. Switching drivers later is
+config only — see [Database](./database.md) and [Starter kits](./starter-kits.md).
+
+For a guided first hour inside the codebase (routes, controllers, views, config),
+read [Getting Started](./getting-started.md).
+
+## 3. Optional — AI agents (local)
+
+Keel is designed to be written with an agent. Point Cursor / Claude Code at the
+MCP server that ships with the package:
+
+```json
+{
+  "mcpServers": {
+    "keel": {
+      "command": "npx",
+      "args": ["-y", "keel-mcp"]
+    }
+  }
+}
+```
+
+Then have the agent call `keel_overview` first. It can search docs, look up the
+public API, and scaffold controllers/jobs/… without inventing imports.
+
+Full map: [Building with AI](./ai.md).
+
+## 4. Deploy yourself (Cloudflare Workers)
+
+Every kit includes `wrangler.jsonc`, a `worker.ts` entry, and `npm run deploy`.
+You own the Cloudflare account and the hostname.
+
+```bash
+# one-time
+npx wrangler login
+npx wrangler d1 create my-app          # paste database_id into wrangler.jsonc
+
+# ship
+npm run deploy                         # css:build + wrangler deploy
+```
+
+Migrations against remote D1 use the HTTP driver from your laptop / CI — the
+binding only exists inside the Worker. Set Cloudflare API credentials as
+documented in [Database](./database.md) (D1 HTTP) and your kit’s README.
+
+Edge preview without deploying:
+
+```bash
+npm run dev:edge                       # wrangler + local D1
+```
+
+Hosting helpers (hostname utils, SQL dump, secrets encryption) live in
+[`@shaferllc/keel/hosting`](./hosting.md) if you build your own control plane.
+
+## 5. Optional — Keel Cloud (`*.keeljs.cloud`)
+
+Ship without owning a Cloudflare account: **Keel Cloud** creates the site,
+runs preview/production Workers on `*.keeljs.cloud`, vaults secrets, and lets
+you export git + SQL anytime — driven from the **same `keel-mcp`** you already
+use for docs.
+
+**Dedicated guide:** [Keel Cloud (deploy from MCP)](./keel-cloud.md).
+
+Quick path:
+
+1. Sign up at [app.keeljs.cloud](https://app.keeljs.cloud) → mint a token at `/tokens`
+2. Add `KEEL_CLOUD_TOKEN` (+ `KEEL_CLOUD_URL`) to your MCP config
+3. Agent: `keel_cloud_create_site` → edit `storage_path` → `keel_cloud_preview` →
+   `keel_cloud_publish { confirm: true }`
+
+Use Cloud when you want the platform to own deploys and hostnames. Skip it when
+you already have Cloudflare / your own pipeline (§4). Don’t mix Cloud and
+self-host for the same app.
+
+## Which path should I pick?
+
+| Goal | Path |
+|------|------|
+| Learn Keel / ship a side project on your CF account | §§1–4 |
+| Build with an agent in your IDE, deploy yourself | §§1–4 + §3 |
+| Let the platform host preview/prod on `*.keeljs.cloud` via MCP | [Keel Cloud](./keel-cloud.md) |
+| Multi-tenant SaaS with billing | Preset `saas`, then §4 or §5 |
+
+Cloud **create_site** scaffolds a kit the same way `create-keeljs` does — you do
+not need both for the same app. Use `create-keeljs` for apps you own end-to-end;
+use Cloud when you want hosted preview/publish under `*.keeljs.cloud`.
+
+## Where next
+
+- [Keel Cloud (deploy from MCP)](./keel-cloud.md) — create / preview / publish
+  on `*.keeljs.cloud` from `keel-mcp`
+- [Getting Started](./getting-started.md) — first route, controller, view
+- [Starter kits](./starter-kits.md) — presets and the Node/edge seam
+- [Building with AI](./ai.md) — MCP tools (local + Cloud)
+- [Hosting](./hosting.md) — Cloudflare / dump / secrets primitives
+- [Accounts](./accounts.md) · [Teams](./teams.md) · [Billing](./billing.md) — what
+  `app` / `saas` already mount
+
+
+
+---
+
+<!-- source: docs/keel-cloud.md -->
+
+# Keel Cloud (deploy from MCP)
+
+**Keel Cloud** hosts your Keel apps on `*.keeljs.cloud` — preview and production
+Workers, D1, secrets vault, and full export (git + SQL). You build in your IDE
+with an AI agent; the same `keel-mcp` binary that knows the framework also
+**creates sites and deploys them** when you set a Cloud token.
+
+| Host | Role |
+|------|------|
+| [app.keeljs.cloud](https://app.keeljs.cloud) | Control plane (dashboard + `/api/v1`) |
+| `preview-{slug}.keeljs.cloud` | Preview Worker |
+| `{slug}.keeljs.cloud` | Production Worker |
+| [keeljs.com](https://keeljs.com) | Framework docs (this site) |
+
+Private alpha: registration needs an invite code or allowlisted email. Free tier
+is limited (typically one site); Pro adds more sites and custom domains.
+
+> Prefer owning Cloudflare yourself? Use
+> [From install to deploy](./from-install-to-deploy.md) §4 (`create-keeljs` +
+> `wrangler deploy`). Cloud and self-host are **alternate** paths — don’t mix
+> them for the same app.
+
+## Why deploy from MCP
+
+Agents already use `keel-mcp` for docs and scaffolding. With a token they also
+get `keel_cloud_*` tools against the control plane — no separate CLI, no
+copy-pasting wrangler credentials into the agent. The loop is:
+
+```text
+create_site → edit storage_path → set_secret → preview → publish (confirm)
+```
+
+## 1. Sign up and mint a token
+
+1. Open [app.keeljs.cloud](https://app.keeljs.cloud) and register (invite /
+   allowlist during alpha).
+2. Go to **`/tokens`** → create a personal access token.
+3. Copy the plaintext once — it looks like `keel_<selector>.<verifier>`.
+
+The token binds to your **first team**. Switch teams in the dashboard before
+minting if you need a different team context.
+
+## 2. Wire `keel-mcp` for Cloud
+
+Same server as local docs/API — add env so Cloud tools register:
+
+**Cursor / `.mcp.json` / Windsurf:**
+
+```json
+{
+  "mcpServers": {
+    "keel": {
+      "command": "npx",
+      "args": ["-y", "keel-mcp"],
+      "env": {
+        "KEEL_CLOUD_TOKEN": "keel_….…",
+        "KEEL_CLOUD_URL": "https://app.keeljs.cloud"
+      }
+    }
+  }
+}
+```
+
+**Claude Code:**
+
+```bash
+claude mcp add keel -e KEEL_CLOUD_TOKEN=keel_….… -e KEEL_CLOUD_URL=https://app.keeljs.cloud -- npx -y keel-mcp
+```
+
+Reload the MCP client. Stderr should say `Cloud tools enabled`. Call
+`keel_overview` — it lists the Cloud loop when a token is present.
+
+Local-only (docs + scaffold, no deploy): omit the env vars.
+[Building with AI](./ai.md) covers that surface.
+
+## 3. Deploy a site from the agent
+
+Tell your agent something like: *“Create an app preset site named Acme on Keel
+Cloud, then preview it.”* Or drive the tools yourself:
+
+### Create
+
+```text
+keel_cloud_create_site { "name": "Acme", "preset": "app" }
+```
+
+Presets: `minimal` | `api` | `app` | `saas` (same kits as
+[`create-keeljs`](./starter-kits.md)).
+
+Response includes `storage_path` (real Keel app on disk) and hostnames. Open that
+path in your IDE and edit like any Keel project.
+
+### Secrets (optional, before deploy)
+
+```text
+keel_cloud_set_secret { "site_id": 1, "key": "STRIPE_SECRET_KEY", "value": "sk_…" }
+keel_cloud_list_secrets { "site_id": 1 }    # keys only — values never returned
+```
+
+Secrets are vaulted (not in git) and injected on the next preview/publish.
+
+### Preview (safe to repeat)
+
+```text
+keel_cloud_preview { "site_id": 1 }
+```
+
+Deploys the preview Worker → `preview-{slug}.keeljs.cloud`. Iterate freely.
+
+### Publish production (confirm required)
+
+```text
+keel_cloud_publish { "site_id": 1, "confirm": true }
+```
+
+Agents must get your explicit approval before `confirm: true`. Production lands
+on `{slug}.keeljs.cloud`.
+
+### Check status
+
+```text
+keel_cloud_get_site { "site_id": 1 }
+keel_cloud_deploys { "site_id": 1 }       # logs + preview/production history
+keel_cloud_me                             # plan, site_limit, team
+```
+
+### Custom domain (Pro)
+
+```text
+keel_cloud_set_custom_domain {
+  "site_id": 1,
+  "hostname": "app.example.com",
+  "attach": true
+}
+```
+
+Returns CNAME instructions (point at `{slug}.keeljs.cloud`). The customer zone
+must live on the same Cloudflare account as Keel Cloud. Clear with
+`keel_cloud_clear_custom_domain`.
+
+### Escape hatch
+
+```text
+keel_cloud_export { "site_id": 1 }
+keel_cloud_export_sql { "site_id": 1, "env": "production" }
+```
+
+Always yours: clone `storage_path` / `git_url`, restore the `.sql` dump on a
+self-hosted Keel app anytime.
+
+## Tool cheat sheet
+
+| Tool | Deploy role |
+|------|-------------|
+| `keel_cloud_create_site` | Scaffold kit under Cloud storage |
+| `keel_cloud_preview` | Deploy preview Worker |
+| `keel_cloud_publish` | Deploy production (`confirm: true`) |
+| `keel_cloud_set_secret` / `_list_secrets` / `_delete_secret` | Runtime env for Workers |
+| `keel_cloud_set_custom_domain` / `_clear_custom_domain` | Pro hostname |
+| `keel_cloud_deploys` / `_get_site` | Status and logs |
+| `keel_cloud_billing` / `_checkout` / `_portal` | Plan / upgrade (owner) |
+| `keel_cloud_export` / `_export_sql` | Leave with code + data |
+| `keel_cloud_delete_site` / `_restore_site` | Soft-delete / restore |
+
+Full API table and local-docs tools: [Building with AI](./ai.md).
+
+## Dashboard parity
+
+Everything above is also available in the browser at
+[app.keeljs.cloud](https://app.keeljs.cloud) (`/sites`, `/billing`, `/tokens`).
+MCP is the agent-first path; the UI is the same control plane.
+
+## Related
+
+- [From install to deploy](./from-install-to-deploy.md) — full journey including
+  self-hosted Cloudflare
+- [Building with AI](./ai.md) — MCP docs + complete `keel_cloud_*` list
+- [Starter kits](./starter-kits.md) — what each preset contains
+- [Hosting](./hosting.md) — primitives Cloud uses under the hood
+- [Gates](./gates.md) — invite / allowlist signup gating
+
+
+
 ---
 
 <!-- source: docs/getting-started.md -->
@@ -28,32 +379,20 @@ Keel targets modern Node and web-standard APIs, so a current runtime matters —
 
 ## Install
 
-Keel ships as two repos: the **framework** (`@shaferllc/keel`, published to
-npm) and a **starter app** (`shaferllc/keel-app`) you build on. Which path you
-take depends on whether you're starting fresh or bolting Keel onto something
-that already exists. See [Architecture](./architecture.md#two-repos-library-and-starter)
-for why it's split this way.
-
-### From the starter (recommended)
-
-The fastest route to a running app is the starter — a working skeleton with the
-folders, config, and scripts already wired:
+The fastest path to a running app is the generator — it copies a curated kit
+from the same `@shaferllc/keel` version you install, so the template cannot lag
+the framework:
 
 ```bash
-git clone https://github.com/shaferllc/keel-app.git my-app
+npm create keeljs@latest my-app
 cd my-app
 npm install
+npm run dev        # http://localhost:3000
 ```
 
-The starter depends on `@shaferllc/keel`, so you pick up framework updates with
-an ordinary `npm update @shaferllc/keel` — your app code in `app/` stays put.
-
-A fresh checkout ships with a working `.env`. To start from the template
-instead:
-
-```bash
-cp .env.example .env
-```
+For the full journey (presets, Cloudflare deploy, optional Keel Cloud + MCP),
+see **[From install to deploy](./from-install-to-deploy.md)**. Kit details:
+[Starter kits](./starter-kits.md).
 
 ### Into an existing app
 
@@ -70,22 +409,24 @@ import { Application, Router, config } from "@shaferllc/keel/core";
 ```
 
 You supply the four convention folders yourself — `app/`, `config/`, `routes/`,
-`bootstrap/` — plus an entry that calls `createApplication()`. The starter's
+`bootstrap/` — plus an entry that calls `createApplication()`. A generated kit’s
 `bootstrap/app.ts` is the reference; copy it and trim to taste.
 
 ### Hacking on the framework itself
 
-To work on Keel proper, clone the framework repo — it carries an example app you
-can run directly:
+To work on Keel proper, clone the framework repo:
 
 ```bash
 git clone https://github.com/shaferllc/keel.git
 cd keel
 npm install
-npm run dev        # example app on http://localhost:3000
-npm run build      # compile the package to dist/
+npm test
+npm run typecheck
 ```
 
+Generate a disposable app against your checkout with
+`npm create keeljs@latest …` and point its dependency at `file:../keel`.
+
 ## Run the server
 
 ```bash
@@ -280,9 +621,10 @@ unsure what's mounted. [The Console](./console.md) lists every command.
 ## Where to go next
 
 You now have the shape of a Keel app: routes point at controllers, controllers
-render views and read config, and the console scaffolds the pieces. The deep
-guides pick up from here:
+render views and read config, and the console scaffolds the pieces.
 
+- **[From install to deploy](./from-install-to-deploy.md)** — presets, Cloudflare,
+  optional Keel Cloud + MCP
 - [Architecture](./architecture.md) — how boot, the container, and the request
   lifecycle fit together
 - [The Service Container](./container.md) — how dependency injection works
@@ -297,6 +639,7 @@ guides pick up from here:
   the active-record layer on top of it
 - [Configuration](./configuration.md) and [The Console](./console.md) — settings
   and commands
+- [Building with AI](./ai.md) — MCP docs + Cloud tools
 
 When something isn't documented, open the source — the whole framework is a few
 hundred readable lines in `src/core/`, and [Built on Hono](./hono.md) explains
@@ -304,6 +647,116 @@ what you inherit from the layer underneath.
 
 
 
+---
+
+<!-- source: docs/starter-kits.md -->
+
+# Starter kits
+
+```bash
+npm create keeljs@latest my-app -- --preset saas
+```
+
+Four curated applications. Each is a complete, working app — not a scaffold you have
+to finish. For the full path from this command through Cloudflare or Keel Cloud,
+see [From install to deploy](./from-install-to-deploy.md).
+
+| Preset | What you get |
+| --- | --- |
+| `minimal` | Routes, a controller, a JSX view, Tailwind. No database. |
+| `api` | JSON only — models, migrations, validation, tests. No views. |
+| `app` *(default)* | Full-stack: views, sessions, register/login, password reset, two-factor. |
+| `saas` | `app` plus teams, roles, invitations, billing, and multi-tenancy. |
+
+## Pick a kit
+
+```bash
+npm create keeljs@latest my-app                 # app (default)
+npm create keeljs@latest my-api  -- --preset api
+npm create keeljs@latest my-saas -- --preset saas
+npm create keeljs@latest bare    -- --preset minimal
+cd my-app && npm install && npm run dev
+```
+
+Then open `http://localhost:3000`. The SaaS kit already has a team switcher,
+invites, and a billing stub wired through [teams](./teams.md) and
+[billing](./billing.md) — start by editing `app/Models` and `routes/web.ts`.
+
+## Every database, Cloudflare first
+
+Each kit ships with all four drivers wired. Switching is `DB_CONNECTION` and nothing
+else — no model or query changes, because they talk to a `Connection`, not a driver.
+
+| | |
+| --- | --- |
+| **D1** | The default for deploys. Inside the Worker Keel uses the binding; migrations and scripts reach the same database over [the HTTP API](./database.md), so `keel migrate` works from your laptop and from CI. |
+| **SQLite** (libSQL) | A local file. What `npm run dev` uses — no account, no wrangler. |
+| **Turso** | libSQL over the network. |
+| **Postgres** | For when you want it. |
+
+Local and production are both SQLite dialects, so one schema and one set of
+migrations serve both.
+
+```bash
+npm run dev            # Node, SQLite file, no setup
+npm run dev:edge       # wrangler, local D1
+npm run deploy         # wrangler deploy
+```
+
+To deploy:
+
+```bash
+wrangler d1 create my-app     # paste the id into wrangler.jsonc
+npm run deploy
+```
+
+## What's in the box
+
+`app` and `saas` mount [accounts](./accounts.md), so password reset, email
+verification, and two-factor already work — the flows live in the framework, tested
+once, rather than being copy-pasted into each new app. `saas` also mounts
+[teams](./teams.md) and [billing](./billing.md).
+
+In `saas`, a tenant-owned model is one word:
+
+```ts
+import { TenantModel } from "@shaferllc/keel/teams";
+
+class Project extends TenantModel {
+  static table = "projects";
+}
+
+await Project.all();                  // only the current team's. Always.
+await Project.create({ name: "Hi" }); // stamped with the current team
+```
+
+Another team's project isn't merely hidden from a list — `Project.find(id)` returns
+`null`. You never write `.where("team_id", …)`, which is what makes it impossible to
+forget.
+
+## Why a generator, and not a template repo
+
+Because a second repo rots. The old starter sat pinned to `0.78.2` while the
+framework was on `0.79.0`, and nothing noticed.
+
+The templates live **inside the framework package**, so the version a kit is
+generated from is, by construction, the version it was written for. And CI generates
+all four on every push, then typechecks, migrates, boots, serves a request, bundles
+the Worker, and runs their tests — so a breaking change fails in the pull request
+that caused it, not in your `npm create` three weeks later.
+
+## The Node/edge seam
+
+Each kit has two provider lists. `bootstrap/providers.ts` runs under Node;
+`bootstrap/providers.edge.ts` runs in the Worker and deliberately **omits the
+database provider** — it reaches for `pg`, which needs `net`/`tls`, and wrangler
+cannot bundle a TCP driver for the edge. `worker.ts` binds D1 before the app boots,
+so nothing on the edge needs to open a connection.
+
+If you add a provider that touches a Node-only module, add it to the Node list only.
+
+
+
 ---
 
 <!-- source: docs/architecture.md -->
@@ -4669,8 +5122,11 @@ AI-facing surface: an MCP server, machine-readable docs (`llms.txt` /
 `llms-full.txt`), an agent playbook (`AGENTS.md`), and code generators an agent
 can drive directly.
 
-If you only read one thing: point your agent at the [MCP server](#the-mcp-server)
-and have it call `keel_overview` first.
+If you only read one thing: follow
+[From install to deploy](./from-install-to-deploy.md). To **deploy on
+`*.keeljs.cloud` from your IDE**, see [Keel Cloud (deploy from MCP)](./keel-cloud.md).
+Then point your agent at the [MCP server](#the-mcp-server) and call
+`keel_overview` first.
 
 ## Why this exists
 
@@ -4726,8 +5182,12 @@ package, so it always matches your installed version.
 | `keel_scaffold` | Generate a controller/provider/middleware/factory/seeder/job/notification/transformer stub. Returns code + target path — it does **not** write to disk. |
 
 When `KEEL_CLOUD_TOKEN` (and optional `KEEL_CLOUD_URL`) is set, Cloud tools are
-also registered. Create a token at `/tokens` on the control plane — the plaintext
-looks like `keel_<selector>.<verifier>`.
+also registered — **create, preview, and publish sites on `*.keeljs.cloud`** from
+the same MCP server. Step-by-step:
+**[Keel Cloud (deploy from MCP)](./keel-cloud.md)**.
+
+Create a token at `/tokens` on [app.keeljs.cloud](https://app.keeljs.cloud) — the
+plaintext looks like `keel_<selector>.<verifier>`.
 
 | Tool | What it does |
 |------|--------------|
@@ -4777,11 +5237,13 @@ minting a token if you need a different team context.
 
 ### A typical Keel Cloud loop
 
+Full walkthrough: [Keel Cloud (deploy from MCP)](./keel-cloud.md).
+
 1. `keel_cloud_create_site { name: "Acme", preset: "app" }`
 2. Edit the returned `storage_path` (real Keel app + git)
 3. `keel_cloud_set_secret` for env the Worker needs
-4. `keel_cloud_preview { site_id }`
-5. `keel_cloud_publish { site_id, confirm: true }` after the user approves
+4. `keel_cloud_preview { site_id }` → `preview-{slug}.keeljs.cloud`
+5. `keel_cloud_publish { site_id, confirm: true }` → `{slug}.keeljs.cloud`
 6. Optional Pro: `keel_cloud_set_custom_domain { hostname, attach: true }`
 7. Escape hatch anytime: `keel_cloud_export` + `keel_cloud_export_sql`
 
@@ -17957,115 +18419,6 @@ const gitlab = social.driver(
 
 
 
----
-
-<!-- source: docs/starter-kits.md -->
-
-# Starter kits
-
-```bash
-npm create keeljs@latest my-app -- --preset saas
-```
-
-Four curated applications. Each is a complete, working app — not a scaffold you have
-to finish.
-
-| Preset | What you get |
-| --- | --- |
-| `minimal` | Routes, a controller, a JSX view, Tailwind. No database. |
-| `api` | JSON only — models, migrations, validation, tests. No views. |
-| `app` *(default)* | Full-stack: views, sessions, register/login, password reset, two-factor. |
-| `saas` | `app` plus teams, roles, invitations, billing, and multi-tenancy. |
-
-## Pick a kit
-
-```bash
-npm create keeljs@latest my-app                 # app (default)
-npm create keeljs@latest my-api  -- --preset api
-npm create keeljs@latest my-saas -- --preset saas
-npm create keeljs@latest bare    -- --preset minimal
-cd my-app && npm install && npm run dev
-```
-
-Then open `http://localhost:3000`. The SaaS kit already has a team switcher,
-invites, and a billing stub wired through [teams](./teams.md) and
-[billing](./billing.md) — start by editing `app/Models` and `routes/web.ts`.
-
-## Every database, Cloudflare first
-
-Each kit ships with all four drivers wired. Switching is `DB_CONNECTION` and nothing
-else — no model or query changes, because they talk to a `Connection`, not a driver.
-
-| | |
-| --- | --- |
-| **D1** | The default for deploys. Inside the Worker Keel uses the binding; migrations and scripts reach the same database over [the HTTP API](./database.md), so `keel migrate` works from your laptop and from CI. |
-| **SQLite** (libSQL) | A local file. What `npm run dev` uses — no account, no wrangler. |
-| **Turso** | libSQL over the network. |
-| **Postgres** | For when you want it. |
-
-Local and production are both SQLite dialects, so one schema and one set of
-migrations serve both.
-
-```bash
-npm run dev            # Node, SQLite file, no setup
-npm run dev:edge       # wrangler, local D1
-npm run deploy         # wrangler deploy
-```
-
-To deploy:
-
-```bash
-wrangler d1 create my-app     # paste the id into wrangler.jsonc
-npm run deploy
-```
-
-## What's in the box
-
-`app` and `saas` mount [accounts](./accounts.md), so password reset, email
-verification, and two-factor already work — the flows live in the framework, tested
-once, rather than being copy-pasted into each new app. `saas` also mounts
-[teams](./teams.md) and [billing](./billing.md).
-
-In `saas`, a tenant-owned model is one word:
-
-```ts
-import { TenantModel } from "@shaferllc/keel/teams";
-
-class Project extends TenantModel {
-  static table = "projects";
-}
-
-await Project.all();                  // only the current team's. Always.
-await Project.create({ name: "Hi" }); // stamped with the current team
-```
-
-Another team's project isn't merely hidden from a list — `Project.find(id)` returns
-`null`. You never write `.where("team_id", …)`, which is what makes it impossible to
-forget.
-
-## Why a generator, and not a template repo
-
-Because a second repo rots. The old starter sat pinned to `0.78.2` while the
-framework was on `0.79.0`, and nothing noticed.
-
-The templates live **inside the framework package**, so the version a kit is
-generated from is, by construction, the version it was written for. And CI generates
-all four on every push, then typechecks, migrates, boots, serves a request, bundles
-the Worker, and runs their tests — so a breaking change fails in the pull request
-that caused it, not in your `npm create` three weeks later.
-
-## The Node/edge seam
-
-Each kit has two provider lists. `bootstrap/providers.ts` runs under Node;
-`bootstrap/providers.edge.ts` runs in the Worker and deliberately **omits the
-database provider** — it reaches for `pg`, which needs `net`/`tls`, and wrangler
-cannot bundle a TCP driver for the edge. `worker.ts` binds D1 before the app boots,
-so nothing on the edge needs to open a connection.
-
-If you add a provider that touches a Node-only module, add it to the Node list only.
-
-
-
 ---
 
 <!-- source: docs/static-files.md -->