> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cubby.pro/llms.txt
> Use this file to discover all available pages before exploring further.

# Using Cubby with Cursor

> Build and ship Cubby apps in Cursor using the CLI and the generated .cursor/rules

# Using Cubby with Cursor

Cursor works with Cubby through the **CLI** and the `.cursor/rules/cubby.mdc` rule file
that `cubby init` generates in your project. Cursor applies that rule to every request,
so it follows Cubby's conventions automatically — no MCP server required.

<Info>
  The fastest start is the agent-neutral [Expert from paste](/tutorials/expert-from-paste)
  prompt — it works in Cursor verbatim. This page is the Cursor-specific detail.
</Info>

## How Cursor gets Cubby context

`cubby init` writes `.cursor/rules/cubby.mdc` with `alwaysApply: true`, so Cursor treats
the Cubby contract as a standing rule on every prompt — same canonical order and
data-scoping doctrine as `AGENTS.md` / `CLAUDE.md`, generated per template. You do not
need to `@`-mention it; it applies automatically. The richer `CUBBY.md` is in the project
root for deep-dives.

## Recommended flow

<Steps>
  <Step title="Paste the bootstrap prompt">
    Drop the [Expert from paste](/tutorials/expert-from-paste) prompt into Cursor's chat
    with your email filled in.
  </Step>

  <Step title="Install and log in">
    `npm install -g cubbypro`, then `cubby login <email>`; confirm with `cubby whoami`.
  </Step>

  <Step title="Scaffold with an explicit template">
    `cubby init <name> --template <choice>`. **Default is SQLite, not Postgres** — pass
    `--template` so the choice is deliberate. (Run it in Cursor's integrated terminal.)
  </Step>

  <Step title="Confirm the rule is active">
    After `cubby init`, `.cursor/rules/cubby.mdc` exists and applies automatically. If
    Cursor ignores Cubby conventions, open the rule and confirm `alwaysApply: true`.
  </Step>

  <Step title="Decide scope, then build">
    Default to a **shared** dataset. Only key by `x-cubby-user-id` for an explicitly
    per-user app — the header is an access gate, not a partition key.
  </Step>

  <Step title="Local dev — Cursor should ask you">
    SQLite / no-DB → `npm run dev` (no Docker). Neon → `cubby dev` (Docker).
  </Step>

  <Step title="Check and deploy">
    `cubby check`, then `cubby deploy` in the integrated terminal.
  </Step>

  <Step title="Secrets after the first deploy">
    `cubby secrets set <NAME> --env prod`, then redeploy or `cubby secrets apply --env prod`.
  </Step>
</Steps>

## Common pitfalls (and the current truth)

* **Default scaffold is SQLite, not Postgres.** Choose `nextjs-neon` only when you need
  real Postgres features.
* **No local Docker rabbit hole on SQLite apps.** `npm run dev` needs no DB; Cubby runs
  `prisma db push` on deploy. For a live local DB, create the `data/` dir first
  (`mkdir -p data`) before `npx prisma db push` (which creates the SQLite file) or you hit `P1003`.
* **Secrets need `--env prod`.** The default env is `local`.
* **Run the CLI in Cursor's integrated terminal**, in the project root, so it picks up
  `cubby.yaml` and the generated files.

## Related

* [Expert from paste](/tutorials/expert-from-paste) — the paste prompt
* [Using Cubby with Codex](/tutorials/using-with-codex)
* [Using Cubby with Claude](/tutorials/using-with-claude) — adds an optional MCP path
* [CUBBY.md file](/platform/cubby-md)