Skip to main content

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

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.
The fastest start is the agent-neutral Expert from paste prompt — it works in Cursor verbatim. This page is the Cursor-specific detail.

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.
1

Paste the bootstrap prompt

Drop the Expert from paste prompt into Cursor’s chat with your email filled in.
2

Install and log in

npm install -g cubbypro, then cubby login <email>; confirm with cubby whoami.
3

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.)
4

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.
5

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.
6

Local dev — Cursor should ask you

SQLite / no-DB → npm run dev (no Docker). Neon → cubby dev (Docker).
7

Check and deploy

cubby check, then cubby deploy in the integrated terminal.
8

Secrets after the first deploy

cubby secrets set <NAME> --env prod, then redeploy or cubby secrets apply --env prod.

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.