@rebasepro/cli 0.17.3 → 0.18.0

package/templates/template/.windsurfrules

@@ -1,2 +1,3 @@
 # Rebase AI Rules
 Please refer to and follow the instructions defined in [ai-instructions.md](./ai-instructions.md).
+Install the Rebase skills for this assistant: `rebase skills install --agent windsurf`.

package/templates/template/AGENTS.md

@@ -1,2 +1,3 @@
 # Rebase AI Rules
 Please refer to and follow the instructions defined in [ai-instructions.md](ai-instructions.md).
+Install the Rebase skills for this assistant: `rebase skills install --agent codex`.

package/templates/template/CLAUDE.md

@@ -1,2 +1,3 @@
 # Rebase AI Rules
-Please refer to and follow the instructions defined in [ai-instructions.md](ai-instructions.md).
+Please refer to and follow the instructions defined in [ai-instructions.md](./ai-instructions.md).
+Install the Rebase skills for this assistant: `rebase skills install --agent claude`.

package/templates/template/README.md

@@ -12,10 +12,12 @@ point for this project.
 
 ### Prerequisites
 
-- [Node.js](https://nodejs.org) >= 18
+- [Node.js](https://nodejs.org) >= 22.22
 - [pnpm](https://pnpm.io) or [npm](https://www.npmjs.com) (v7+)
-- [Docker](https://www.docker.com) (to run the included PostgreSQL container),
-  or your own PostgreSQL database
+
+That is the whole list. There is no database to install: with no `DATABASE_URL`
+set, `rebase dev` starts a managed PostgreSQL (PGlite) inside this project, and
+the runtime creates your collections' tables at boot.
 
 ### Run it
 
@@ -25,26 +27,20 @@ point for this project.
 pnpm install   # or: npm install
 ```
 
-2. Start the PostgreSQL database container:
-
-```bash
-docker compose up -d db
-```
-
-3. Create the database tables from your collections:
-
-```bash
-pnpm run db:push   # or: npm run db:push
-```
-
-4. Start the dev servers:
+2. Start the dev servers:
 
 ```bash
 pnpm dev   # or: npm run dev
 ```
 
-`rebase dev` prints the two URLs it actually bound and opens the admin panel
-there. The first account you register becomes the admin.
+That is the whole first run. `rebase dev` generates the Drizzle schema from
+`config/collections`, starts the database, creates the tables — including the
+example `posts`, `authors` and `tags` — and serves the API and the admin panel.
+
+`rebase dev` prints the two URLs it actually bound. The first account you
+register becomes the admin. `REBASE_ADMIN_EMAIL` and `REBASE_ADMIN_PASSWORD` in
+`.env` are ignored here and read by the production boot below, where that window
+is shut — see [Self-hosting](#self-hosting-with-docker).
 
 Ports are **derived from this project's path**, not fixed at 3001/5173, so
 several Rebase projects can run at once without colliding. That is why the URL
@@ -52,10 +48,30 @@ in your terminal is the one to trust — and why the `PORT` and `VITE_API_URL` i
 `.env` are ignored by `rebase dev` (they apply to `rebase start`, the production
 server). Pin a port with `rebase dev --port 3001` if you need a stable one.
 
-> The `db:push` step is what creates the tables for the example `posts`,
-> `authors`, and `tags` collections. Skip it and the admin panel still opens,
-> but those collections will be empty and their API calls will fail until the
-> tables exist.
+### Variant: your own PostgreSQL
+
+Uncomment `DATABASE_URL` in `.env` and run `pnpm dev` again. Nothing else
+changes. A `DATABASE_URL` that is already set is never touched.
+
+With your own database you also get the migration commands, which the managed
+one cannot offer — they plan changes with Atlas, which needs a second empty
+database to compare against, and PGlite serves exactly one:
+
+```bash
+pnpm run db:push
+```
+
+Boot already creates missing tables and columns additively, so `db push` is for
+what it deliberately leaves alone: junction-table RLS on many-to-many relations,
+and any change that is not purely additive — a renamed column, a narrowed type,
+a removed field.
+
+The `docker-compose.yml` in this project runs PostgreSQL in a container if you
+would rather not install one:
+
+```bash
+docker compose up -d db
+```
 
 ## Project Structure
 
@@ -104,7 +120,9 @@ export default defineFunction((app) => {
 });
 ```
 
-Call from the client SDK: `client.call("functions/hello", { name: "World" })`
+Call from the client SDK: `client.functions.invoke("hello", { name: "World" })`.
+It sends POST by default — for the GET route above, pass
+`{ method: "GET" }` as the third argument.
 
 **Functions are not authenticated for you.** The functions router parses the
 caller's token into the request context but does not reject anonymous requests —
@@ -122,7 +140,7 @@ Collections are defined once in `config/collections/` and used by both the front
 
 All configuration is managed through a single `.env` file in the project root. Both the backend and frontend read from this file:
 
-- **Backend**: loads via `dotenv` from `../../.env` (relative to `backend/src/`)
+- **Backend**: the runtime loads the project root's `.env` before it boots
 - **Frontend**: Vite reads `VITE_*` variables via `envDir` pointing to the project root
 - **Scripts**: load via `dotenv` from the project root
 
@@ -133,15 +151,20 @@ All configuration is managed through a single `.env` file in the project root. B
 Two containers: PostgreSQL, and the Rebase runtime with your built project
 mounted into it. There is no application image to build.
 
-The runtime creates its auth tables at boot but **not** your collection tables —
-a container restart must not be able to change a schema as a side effect — so
-push the schema once, while the database is up.
+This is the [variant above](#variant-your-own-postgresql), packaged: the
+compose database is a database of your own, so step 0 is the same one line.
 
 ```bash
+# 0. Point the project at the compose database: uncomment DATABASE_URL in .env
+#    (the line whose host is 127.0.0.1 and whose password matches
+#    DATABASE_PASSWORD — `rebase init` wrote it there, commented out)
+
 # 1. Build your project into ./dist-bundle
 pnpm run build          # or: npm run build
 
-# 2. Start the database and create the tables from your collections
+# 2. Start the database. Boot creates the tables from your collections;
+#    `db:push` is for what it leaves alone — junction-table RLS, and any
+#    change that is not purely additive.
 docker compose up -d db
 pnpm run db:push        # or: npm run db:push
 
@@ -161,6 +184,14 @@ docker compose down -v
 One container now serves the API at `/api` and the admin at `/` — same origin,
 so there is no CORS between them and no second web server to run.
 
+Sign in as `REBASE_ADMIN_EMAIL` with `REBASE_ADMIN_PASSWORD`, both in `.env`.
+This stack runs with `NODE_ENV=production`, where the first-account-becomes-admin
+window is shut — it has to be, because the container answers on a hostname
+before you have typed anything, so whoever reached the sign-up form first would
+own the deployment. The runtime creates that one account while the user table is
+empty and never again. Change the email to yours before the first boot, and
+change the password after signing in.
+
 To upgrade Rebase, set `REBASE_VERSION` in `.env` and restart. Your bundle is
 untouched.
 

package/templates/template/ai-instructions.md

@@ -1,22 +1,39 @@
 # Rebase AI Coding Rules
 
-Rebase provides agent skills for AI coding assistants (Cursor, Claude Code, Windsurf, Gemini CLI, Antigravity, and more) with detailed guidelines, architecture, SDK APIs, and troubleshooting guides.
+`.mcp.json` in this directory wires the Rebase MCP server up already — no login, no token: it reads `.rebase/state.json` while `pnpm dev` is running. For the full skills (collections, auth, RLS, deployment, the UI kit), run `pnpm skills:install`, or `rebase skills install --agent <claude|cursor|windsurf|gemini>` to pick one.
 
-To install skills for your environment, run:
+## Commands
 
-```
-rebase skills install
-```
+| Command | What it does |
+|---|---|
+| `pnpm dev` | Backend, frontend and the managed development database, together |
+| `pnpm schema:generate` then `pnpm db:push` | The same loop with `pnpm dev` not running, plus the changes boot leaves alone: collections → Drizzle schema → development database |
+| `pnpm db:generate` then `pnpm db:migrate` | The production path — write the migration file, then apply it |
+| `pnpm schema:introspect` | The other direction: existing tables → collection definitions |
+| `pnpm generate:sdk` | Regenerate the typed client from the collections |
+| `pnpm build` then `pnpm start` | Build the deployable bundle, then run it |
+| `pnpm skills:install` | Install the Rebase skills for your assistant |
+| `pnpm example` | Run `scripts/example.ts` against the running backend — the SDK, end to end |
+| `rebase doctor` | What disagrees between collections, generated schema and the live database — run this before guessing |
+| `rebase resources --write` | After declaring a database, bucket or topic in `config/resources.ts`: regenerate `rebase.resources.json` and commit it (`pnpm build` does this too) |
+| `pnpm deploy` | Deploys this project. Never run it; see below |
 
-## Core Tenets (Quick Reference)
+## Never
 
-1. **Schema-as-Code**: Always define or edit collections in `config/collections/` (e.g., `config/collections/posts.ts`). Never modify generated Drizzle schemas or PostgreSQL tables manually.
-2. **Two-Step Migrations**:
-   - Step 1: Run `rebase schema generate` to compile collections to the Drizzle schema.
-   - Step 2: Run `rebase db push` (development) or `rebase db generate && rebase db migrate` (production) to apply schema changes to the database.
-3. **Use the SDK**: Always use the Rebase SDK (`rebase.data.<slug>`) to fetch or modify data. Bypassing it with raw SQL or direct Drizzle/PG queries circumvents model validations, lifecycle hooks, and Row-Level Security (RLS).
+- **Never deploy.** `pnpm deploy`, `rebase cloud deploy`, `firebase deploy`, `gcloud run deploy` — print the command and let the human run it, even when the task list ends in "deploy" and the tests are green.
+- **Never edit `.env`.** It holds generated secrets and the connection string. Add a variable by asking, and document it in `.env.example`.
+- **Never edit `backend/src/schema.generated.ts`.** It is overwritten by `pnpm schema:generate`; the collection file is the source.
+- **Never edit `rebase.resources.json`.** It is generated from `config/resources.ts` — declare there, then `rebase resources --write`.
+- **Never pass `--allow-destructive`** to anything pointed at a database that is not the local development one. It drops columns and tables.
+- **Never write raw SQL or Drizzle queries against application tables.** That path skips validation, hooks and row-level security.
+
+## Core rules
+
+1. **Schema-as-code**: define and edit collections in `config/collections/` with `defineCollection` from `@rebasepro/cms-types`, and register each one in that directory's `index.ts` — a collection missing from the barrel does not exist. Never hand-edit generated schemas or Postgres tables.
+2. **Applying a collection change**: while `pnpm dev` is running, saving a file in `config/collections/` is the whole step — it regenerates `backend/src/schema.generated.ts`, restarts the backend, and boot creates the tables and columns that are missing. With `pnpm dev` stopped, that is `pnpm schema:generate`. `pnpm db:push` is only for what boot deliberately leaves alone — a renamed column, a narrowed type, a removed field, junction-table RLS — and it needs your own PostgreSQL, not the managed development database. In production the pair is `pnpm db:generate` then `pnpm db:migrate`.
+3. **Use the SDK**: server-side that is `rebase.dataAsAdmin.<slug>` for work done as the service identity, or `getDriver(c)` inside a function when the read should run as the caller. The server client has no plain `data` accessor — it is omitted precisely so that the choice of identity is written down.
 4. **Guard every custom route**: routes in `backend/functions/` are mounted **without** an auth requirement — webhook receivers need that — so each one is public until you guard it. Import `requireAuth` / `requireAdmin` from `@rebasepro/server/functions` and pass them in the route's own middleware slot (`app.post("/", requireAuth, handler)`), not via `app.use()`, which only covers routes declared below it. Reading `getUser(c)` is not a guard: an anonymous caller gets `undefined` and the handler still runs. See `backend/functions/hello.ts` for all three tiers.
 5. **In `backend/functions/`, always import from `@rebasepro/server/functions`** — never from `@rebasepro/server`. Both work today; the subpath is the portable one, and it also gives you the typed context accessors (`getUser`, `getDriver`, `requireDriver`) instead of casting `c.get("user")`. The package root is for a server entrypoint, not for route handlers.
 6. **Never read `process.env` at the top of a function file.** A module-scope read that comes back undefined throws at import time, and the loader reports that as a *skipped function* — the route simply 404s with no error attached to it. Read configuration inside the handler with `requireEnv(c, "NAME")`, or build a client once with `lazyResource(env => new Client(env.KEY))`.
 7. **Work that outlives the response goes in `waitUntil(c, promise)`**, not a floating promise. A floating promise is dropped when the process shuts down mid-deploy; `waitUntil` is what a graceful shutdown waits for.
-8. **Build UI from the kit, never from scratch**: any custom view, home page, dashboard or entity tab must be composed from `@rebasepro/ui` components (`Card`, `Typography`, `Button`, `Chip`, `Alert`, …) and the theme's colour tokens (`text-surface-*`, `bg-surface-accent-*`, `text-primary`), with a `dark:` value beside every light one. Do **not** invent a palette, a type scale, or hand-written CSS: a hardcoded colour like `#111` is invisible in one of the two themes and nothing will catch it. The live reference ships in your `node_modules` — read `@rebasepro/app/src/components/Debug/UIReferenceView.tsx` before building a view, and see [Styling Custom UI](https://rebase.pro/docs/frontend/styling). The `rebase-design-language` and `rebase-ui-components` skills cover this in full; install them with `rebase skills install`.
+8. **Build UI from the kit, never from scratch**: any custom view, home page, dashboard or entity tab must be composed from `@rebasepro/ui` components (`Card`, `Typography`, `Button`, `Chip`, `Alert`, …) and the theme's colour tokens (`text-surface-*`, `bg-surface-accent-*`, `text-primary`), with a `dark:` value beside every light one. Do **not** invent a palette, a type scale, or hand-written CSS: a hardcoded colour like `#111` is invisible in one of the two themes and nothing will catch it. The live reference ships in your `node_modules` — read `@rebasepro/app/src/components/Debug/UIReferenceView.tsx` before building a view, and see [Styling Custom UI](https://rebase.pro/docs/frontend/styling).

package/templates/template/backend/functions/hello.ts

@@ -15,7 +15,11 @@ import {
  *   GET  /api/functions/hello/stats    (admins only)
  *
  * Call from the client SDK:
- *   const result = await client.call("functions/hello", { name: "World" });
+ *   const result = await client.functions.invoke("hello", { name: "World" });
+ *
+ * `invoke` sends POST by default, which is why the POST route below is the one
+ * that takes a body. For the public GET above, pass the method:
+ *   await client.functions.invoke("hello", undefined, { method: "GET" });
  *
  * Authored with `defineFunction`, which hands you a pre-typed Hono app (so
  * `c.get("user")` / `c.get("driver")` are typed) and the `rebase` singleton via

package/templates/template/backend/package.json

@@ -17,13 +17,13 @@
         "@hono/node-server": "^2.0.12",
         "pg": "^8.11.3",
         "ws": "^8.16.0",
-        "dotenv": "^16.0.0",
+        "dotenv": "^17.4.2",
         "zod": "^4.4.3",
         "ts-morph": "28.0.0"
     },
     "devDependencies": {
         "@types/pg": "^8.6.5",
-        "@types/node": "^20.10.5",
+        "@types/node": "^22.19.4",
         "@types/ws": "^8.5.10",
         "tsx": "^4.20.6",
         "typescript": "^5.9.2"

package/templates/template/backend/src/schema.generated.ts

@@ -1,7 +1,12 @@
-// This file is auto-generated by `pnpm db:generate`.
-// Do not edit manually.
+// This file is generated from config/collections/. Do not edit manually.
 //
-// Run `pnpm db:generate` to regenerate this file from your collections.
+// `rebase dev` regenerates it before it starts anything, so the stub below is
+// replaced on your first run and you should not have to think about this file.
+// To regenerate it by hand: `pnpm run schema:generate`.
+//
+// Not `db:generate` — that one plans an Atlas migration and needs a real
+// PostgreSQL. `schema:generate` only reads your collections and writes this
+// file, so it works on any database, including the managed development one.
 
 export const tables = {};
 export const enums = {};

package/templates/template/backend/tsconfig.json

@@ -2,7 +2,7 @@
   "compilerOptions": {
     "target": "ES2022",
     "module": "ESNext",
-    "moduleResolution": "node",
+    "moduleResolution": "bundler",
     "lib": ["ES2022"],
     "outDir": "./dist",
     "strict": true,

package/templates/template/config/cms.d.ts

@@ -7,3 +7,9 @@
 //
 // A BaaS project has no admin panel and no reason for this file. Without it, `admin` on
 // a collection or a property is a type error, which is the guarantee.
+//
+// It is only needed by a file that annotates a collection with the *type* —
+// `const posts: PostgresCollectionConfig = { … }`. Every collection here is written with
+// `defineCollection()` instead, which is imported from `@rebasepro/cms-types` and brings
+// the augmentation with it. The reference stays because it costs one line and covers the
+// case where somebody reaches for the annotation.

package/templates/template/config/package.json

@@ -16,7 +16,7 @@
     "@rebasepro/types": "workspace:*"
   },
   "devDependencies": {
-    "@types/node": "^20.19.41",
+    "@types/node": "^22.19.4",
     "typescript": "^5.9.2"
   },
   "exports": {

package/templates/template/config/resources.ts

@@ -35,17 +35,31 @@ export const main = database();
  * Object storage.
  *
  * Uncomment to give this project a bucket. The default-keyed one binds from the
- * plain `S3_BUCKET` / `GCS_BUCKET` / `STORAGE_BUCKET`; a named one appends its
- * key, so `bucket("media")` reads `S3_BUCKET__MEDIA`.
+ * plain `S3_BUCKET` / `GCS_BUCKET`; a named one appends its key, so
+ * `bucket("media")` reads `S3_BUCKET__MEDIA`. In development an unbound bucket
+ * is a local directory until you bind it; in production it is off, and
+ * `rebase status` tells you which variable it is waiting on.
  *
  * export const files = bucket({ engine: "s3" });
  * export const media = bucket("media", { engine: "s3" });
  *
+ * One of them has to be the one an upload reaches when the property names no
+ * `storageSource` — the default-keyed `bucket()` above, or a named bucket
+ * marked `bucket("media", { engine: "s3", default: true })`. A project of named
+ * buckets with no default refuses to boot rather than have one chosen for it:
+ * that choice used to be made by declaration order, and it came out differently
+ * in development and in production.
+ *
+ * Point a property at it by handle — the same name, spelled once:
+ *
+ * import { media } from "../resources";
+ * cover: { type: "string", storage: { storageSource: media } }
+ *
  * ## When you have several on one provider
  *
  * Name an `account` and they share one credential set instead of repeating it:
  *
- * export const media   = bucket("media",   { engine: "s3", account: "minio" });
+ * export const media   = bucket("media",   { engine: "s3", account: "minio", default: true });
  * export const avatars = bucket("avatars", { engine: "s3", account: "minio" });
  *
  * That reads `S3_BUCKET__MEDIA` and `S3_BUCKET__AVATARS` — each bucket keeps its
@@ -55,3 +69,28 @@ export const main = database();
  * one, so a single source can be moved to another provider without breaking the
  * rest off their shared account.
  */
+
+/**
+ * Background work.
+ *
+ * A topic fans out: every subscription gets each event, and each retries on
+ * its own. A queue is a work list with one handler. Both ride on the durable
+ * job queue in this project's database, so declaring either turns it on, and
+ * neither needs any environment configuration.
+ *
+ * Add them to the import above when you declare one — they are named here, not
+ * imported, because an import of a symbol nothing uses is an import that breaks
+ * the moment the pinned `@rebasepro/types` predates it:
+ *
+ * import { topic, queue } from "@rebasepro/types";
+ *
+ * export const signups = topic<{ userId: string }>("signups");
+ * signups.subscription("send-welcome", async ({ userId }) => { … });
+ *
+ * export const thumbnails = queue<{ key: string }>("thumbnails");
+ * thumbnails.handler(async ({ key }) => { … });
+ *
+ * Crons and functions are files: `backend/crons/<name>.ts` and
+ * `backend/functions/<name>.ts`. They appear in `rebase resources` under the
+ * name of the file.
+ */

package/templates/template/config/storage.ts

@@ -60,7 +60,8 @@ import { isPublicStoragePath, type StorageAuthorize } from "@rebasepro/types";
  * `storagePublicRead: true` when the bucket genuinely is a public read-only CDN,
  * or `storageInsecureAllowAnyAuthenticated: true` for a single-tenant app where
  * every signed-in user is trusted with every file. Both are set on
- * `initializeRebaseBackend` in `backend/src/index.ts`.
+ * `initializeRebaseBackend`, which this project does not call: the published
+ * runtime boots it. `rebase eject` writes that entry point if you want one.
  */
 export const storageAuthorize: StorageAuthorize = ({ key, user, operation }) => {
     // The `public/` prefix is the framework's convention for world-readable

package/templates/template/docker-compose.yml

@@ -12,14 +12,27 @@
 #
 #   rebase build              # produces ./dist-bundle
 #   docker compose up -d db
-#   rebase db push            # create the collection tables, once
-#   docker compose up
+#   docker compose up         # boot creates the tables it is missing
+#
+# `rebase db push` is the separate step for what boot deliberately leaves
+# alone: junction-table RLS, and any change that is not purely additive.
 #
 # One container then serves the API at /api and the admin at / — same origin, so
 # there is no CORS to configure between them and no second web server.
 #
 # For development, use `rebase dev` instead.
 #
+# This file is the recommended one for a scaffolded project: it is in your
+# repository, `rebase init` filled in its secrets, its first admin account and
+# its pinned runtime version, and it is booted by the framework's own acceptance
+# gate on every push. The copy in the Rebase repository
+# (`infra/docker/docker-compose.selfhost.yml`) is the reference for a deployment
+# with no scaffold behind it, and adds a pgbouncer profile and the split-process
+# shapes. The two agree on every environment variable except the database
+# password: this file reads DATABASE_PASSWORD, which `rebase init` also embeds
+# in the DATABASE_URL in your .env; that one reads POSTGRES_PASSWORD, generated
+# by its own quickstart script.
+#
 # To upgrade Rebase, change REBASE_VERSION and restart. Your bundle is untouched.
 # To run your OWN server code instead, `rebase eject` — it writes the entrypoint,
 # a Dockerfile and a compose file that builds them.
@@ -97,9 +110,35 @@ services:
       # its allowed origins is one that eventually allows the wrong one.
       CORS_ORIGINS: ${CORS_ORIGINS:?set CORS_ORIGINS to the origin you browse to, e.g. http://localhost:3001}
 
-      # Auth tables are created at boot. Collection tables are not: run
-      # `rebase db push` once, against the database above. A container restart
-      # must not be able to change a schema as a side effect.
+      # ─── The first account ───────────────────────────────────────────────
+      #
+      # This service runs with NODE_ENV=production, and in production the
+      # first-registration-becomes-admin window is CLOSED. That window is right
+      # for a laptop, where the person at the keyboard is the operator, and
+      # wrong the moment this stack answers on a hostname: the container is
+      # serving before you have typed anything, so whoever reaches the sign-up
+      # form first would own the deployment.
+      #
+      # So the first admin is named here instead. The runtime creates it once,
+      # while the user table is empty, and does nothing on every boot after
+      # that — nothing is left to be claimed, and nothing to race for.
+      #
+      # `rebase init` wrote both into .env with a generated password. Change
+      # the email to yours, sign in, and change the password.
+      REBASE_ADMIN_EMAIL: ${REBASE_ADMIN_EMAIL:?set REBASE_ADMIN_EMAIL in .env — `rebase init` writes one}
+      REBASE_ADMIN_PASSWORD: ${REBASE_ADMIN_PASSWORD:?set REBASE_ADMIN_PASSWORD in .env — `rebase init` generates one, min 12 characters}
+      # Open sign-up instead: set this to false in .env and clear the two above
+      # — but then the first person to reach the form becomes the administrator.
+      DISABLE_SELF_REGISTRATION: ${DISABLE_SELF_REGISTRATION:-true}
+
+      # `ensure` (the default) creates missing tables and columns at boot —
+      # your collections' as well as auth's — and is additive only: nothing is
+      # dropped, narrowed or rewritten, because that must never happen as a
+      # side effect of a container restart.
+      #
+      # `rebase db push` is still what applies the rest: junction-table RLS on
+      # many-to-many relations, and any change that is not purely additive.
+      # Set this to `none` to take a deployment out of provisioning entirely.
       REBASE_MIGRATE_ON_BOOT: ${REBASE_MIGRATE_ON_BOOT:-ensure}
 
       # Uploads land on the named volume below, which survives restarts. That is
@@ -111,10 +150,12 @@ services:
       STORAGE_PATH: /uploads
       FORCE_LOCAL_STORAGE: "true"
     volumes:
-      # Your built project. Writable, because the runtime installs the bundle's
-      # declared dependencies into it on first start — `rebase build` emits a
-      # package.json but not a node_modules.
-      - ./dist-bundle:/bundle
+      # Your built project. `rebase build` installs its declared dependencies
+      # into the bundle by default, so `node_modules` is already there and the
+      # mount can be read-only — a compromised hook then cannot rewrite the code
+      # that runs after it. Drop the `:ro` if you build with `--no-vendor`: the
+      # runtime installs at every start instead, and needs to write here.
+      - ./dist-bundle:/bundle:ro
       - uploads:/uploads
 
 volumes:

package/templates/template/frontend/index.html

@@ -2,7 +2,6 @@
 <html lang="en">
   <head>
     <meta charset="UTF-8" />
-    <link rel="icon" type="image/svg+xml" href="/favicon.ico" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
     <title>{{PROJECT_NAME}}</title>
   </head>

package/templates/template/frontend/package.json

@@ -5,7 +5,6 @@
     "type": "module",
     "dependencies": {
         "@rebasepro/app": "workspace:*",
-        "@rebasepro/plugin-ai": "workspace:*",
         "@rebasepro/client": "workspace:*",
         "@rebasepro/cms": "workspace:*",
         "@rebasepro/studio": "workspace:*",
@@ -40,7 +39,7 @@
     "devDependencies": {
         "@tailwindcss/typography": "^0.5.16",
         "@tailwindcss/vite": "^4.1.12",
-        "@types/node": "^20.19.41",
+        "@types/node": "^22.19.4",
         "@types/react": "^19.0.8",
         "@types/react-dom": "^19.0.3",
         "@vitejs/plugin-react": "^4.4.1",

package/templates/template/frontend/src/App.tsx

@@ -11,8 +11,12 @@ import { RebaseStudio } from "@rebasepro/studio";
 import { createRebaseClient } from "@rebasepro/client";
 import { collections } from "virtual:rebase-collections";
 
-// Configuration from environment
-const API_URL = import.meta.env.VITE_API_URL || (import.meta.env.DEV ? "http://localhost:3001" : undefined);
+// `rebase dev` injects VITE_API_URL with the port it actually bound, and that
+// port is derived from this project's path rather than fixed — so a
+// `http://localhost:3001` fallback here names a port nothing is listening on.
+// A deployed build serves the admin from the same origin as the API, where an
+// empty value is exactly what you want.
+const API_URL = import.meta.env.VITE_API_URL;
 const GOOGLE_CLIENT_ID = import.meta.env.VITE_GOOGLE_CLIENT_ID;
 
 export function App() {
@@ -34,6 +38,8 @@ export function App() {
                 client={rebaseClient}
                 authController={authController}
             >
+                {/* The sign-in screen. On its own this changes nothing —
+                    it is where you pass `loginView` to replace it. */}
                 <RebaseAuth />
                 <RebaseCMS
                     collections={collections}

package/templates/template/frontend/vite.config.ts

@@ -35,6 +35,14 @@ export default defineConfig({
         sourcemap: true,
         rollupOptions: {
             output: {
+                // These rules are copied in rather than taken from
+                // `rebaseManualChunks` in `@rebasepro/app/vitePlugin`, which is
+                // the same function and would let an upgrade improve them. The
+                // export does not exist in the `@rebasepro/app` version this
+                // scaffold pins, and a template may only import what the
+                // version it pins publishes — `pnpm check:templates` enforces
+                // that. Switch to the import in the first release that
+                // publishes it.
                 manualChunks(id) {
                     // Heavy vendor libraries — split into individually cached chunks.
                     //

package/templates/template/gitignore

@@ -26,11 +26,29 @@ drizzle/meta/
 # Uploads
 uploads/
 
+# Database dumps (`rebase db backup`)
+#
+# The default destination is `backups/` under wherever the command was run, and
+# `rebase db --help`'s own example (`--out ./backups`) lands in the tree too. A
+# dump carries every row, including `rebase.users` password hashes, so this is
+# not tidiness. `*.dump` covers the ones written somewhere else; the
+# `.globals.sql` roles sidecar beside them carries no passwords.
+backups/
+*.dump
+
 # Rebase dev
 .rebase-dev-url
 .rebase-dev-port
 .rebase-dev-secrets.json
 
 # Built project bundle (`rebase build`)
-dist-bundle/
+#
+# The glob, not the one directory: a static app declared in `rebase.json` gets
+# its own `dist-bundle-<name>/` beside this one, so the stock scaffold's first
+# build left 307 untracked files behind `dist-bundle-admin/`.
+dist-bundle*/
 .rebase/
+
+# Generated SDK (`rebase generate-sdk`) — regenerated from the collections,
+# and stale copies in review diffs are noise nobody reads.
+generated/

package/templates/template/npmrc

@@ -3,8 +3,17 @@
 # This makes the project compatible with both pnpm and npm workspaces.
 link-workspace-packages=true
 
-# Disable automatic dependency check before running scripts to prevent background install failures in read-only environments
-verify-deps-before-run=false
+# `verify-deps-before-run` and `confirm-modules-purge` used to be here too.
+# They moved to pnpm-workspace.yaml, in their camelCase spelling: pnpm 11 no
+# longer reads them from this file (it answers `undefined` for both), so they
+# were doing nothing, while npm 12 warned about them on every install and every
+# `npm run` — two lines of noise, in a first run, for settings that had already
+# stopped applying.
 
-# Prevent pnpm from prompting for confirmation when purging modules in non-TTY environments (e.g. Docker, CI)
-confirm-modules-purge=false
+# Refuse to install on a Node older than `engines.node` in package.json.
+#
+# npm-only: pnpm reads the same setting as `engineStrict` from
+# pnpm-workspace.yaml, and answers `undefined` for this spelling. Kept here
+# because a scaffold may be installed with either manager, and npm's default is
+# a warning it then ignores — EBADENGINE, exit 0.
+engine-strict=true

package/templates/template/package.json

@@ -20,15 +20,21 @@
         "schema:generate": "rebase schema generate --collections ../config/collections",
         "generate:sdk": "rebase generate-sdk",
         "skills:install": "rebase skills install",
+        "example": "tsx scripts/example.ts",
         "deploy": "rebase cloud deploy"
     },
     "devDependencies": {
         "@rebasepro/cli": "workspace:*",
         "@rebasepro/types": "workspace:*",
+        "tsx": "^4.20.6",
         "typescript": "^5.9.2"
     },
+    "dependencies": {
+        "@rebasepro/client": "workspace:*",
+        "dotenv": "^17.4.2"
+    },
     "engines": {
-        "node": ">=18.0.0"
+        "node": ">=22.22.0"
     },
     "pnpm": {
         "onlyBuiltDependencies": [
@@ -36,5 +42,8 @@
             "sharp",
             "@ariga/atlas"
         ]
+    },
+    "allowScripts": {
+        "@ariga/atlas": true
     }
 }