Cursor Rules Template: Node.js Express PostgreSQL Kanban SaaS

Overview

The Cursor rules configuration described here targets a complete project management SaaS built with workspaces, tasks, boards, timelines, comments, and file uploads on a Node.js/Express backend with PostgreSQL. This is a Cursor rules template designed to be copy-pasted into your project root as a .cursorrules configuration to guide AI-assisted development.

Direct answer: Use this Cursor rules template to enforce a consistent architecture, safe AI generation, and stack-specific constraints for a scalable, multi-tenant SaaS.

When to Use These Cursor Rules

Starting a new multi-tenant SaaS MVP with workspace scoping.
Guiding AI to generate repository structure, migrations, and services for Node.js/Express + PostgreSQL.
Enforcing security, authentication, and RBAC patterns from the outset.
Ensuring testable, linted, and CI-ready code with clear modular boundaries.
Defining file-upload flows to S3-compatible storage and associated access rules.

Copyable .cursorrules Configuration

framework: Node.js, Express, PostgreSQL

Framework Role & Context:
- You are a senior backend engineer building a multi-tenant SaaS for project management (workspaces, tasks, boards, timelines, comments, file uploads) using Node.js, Express, and PostgreSQL.
- Produce code and DB schemas that Cursor AI can apply directly in the project root.

Code Style and Style Guides:
- Use ESLint with the AirBnB style or standard style; prefer TypeScript where possible.
- Adhere to Prettier formatting and JSDoc for JS.

Architecture & Directory Rules:
- Monorepo layout with apps/api/src and packages/{db, storage}.
- Models under src/models; services under src/services; routes under src/routes.
- Migrations under db/migrations; seeds under db/seeds.

Authentication & Security Rules:
- Implement JWT-based auth with RBAC by workspace.
- Do not log secrets; store credentials in environment variables; enforce TLS in production.

Database and ORM patterns:
- PostgreSQL with parameterized queries; use a repository pattern; avoid tying to a specific ORM.
- Use migrations for schema changes and proper indexing for query-heavy tables (workspaces, boards, tasks, comments, files).

Testing & Linting Workflows:
- Jest for unit/integration; eslint and prettier hooks; CI runs tests on push.

Prohibited Actions and Anti-patterns for the AI:
- Do not generate hard-coded secrets or production credentials.
- Do not rely on string concatenation to build SQL; always use parameterized queries.
- Do not assume Prisma, Mongoose, or Drizzle; keep ORM-agnostic abstractions.
- Do not perform destructive schema changes in prompts without migrations.

Recommended Project Structure

project-root/
  ├─ apps/
  │  └─ api/
  │     └─ src/
  │        ├─ controllers/
  │        ├─ routes/
  │        ├─ services/
  │        ├─ models/
  │        ├─ repositories/
  │        ├─ middlewares/
  │        └─ config/
  ├─ packages/
  │  ├─ db/
  │  │  ├─ migrations/
  │  │  └─ models/
  │  └─ storage/
  ├─ tests/
  ├─ .env.example
  └─ package.json

Core Engineering Principles

Clear module boundaries and a strict folder layout to separate API, data access, and domain logic.
Security-by-design: RBAC, least privilege, token-based auth, and encrypted secrets.
Schema-Driven Development: migrations for all changes and index-first optimization for queries.
Testable by default: unit and integration tests with deterministic fixtures.
AI-assisted coding with explicit prohibitions on unsafe patterns and anti-patterns.

Code Construction Rules

Use repository pattern for data access; controllers call services, services call repositories.
All public API routes follow RESTful conventions; use proper HTTP status codes.
Input validation at boundary layers; sanitize and escape user input; avoid SQL injection risks.
File uploads go through a dedicated service with size/type validation and storage to S3-compatible buckets.
Multi-tenant data isolation via workspace_id context; enforce per-tenant access in services.

Security and Production Rules

Use TLS, store secrets in environment variables, rotate credentials, and implement RBAC.
Enable logging with structured JSON and redact sensitive fields.
Implement rate limiting and IP allow/deny lists for API endpoints.
Require CSRF protection for state-changing requests; validate JWT expiry and audience.

Testing Checklist

Unit tests for controllers, services, and repositories.
Integration tests for multi-tenant flows: workspace creation, board operations, timeline queries, and file uploads.
End-to-end tests to verify user journeys from workspace creation to board updates.
Linting and type checks during CI; run migrations in test env.

Common Mistakes to Avoid

Relying on ORM-specific patterns that hinder portability; keep abstractions ORM-agnostic.
Storing secrets in code or in.env files accidentally; always use environment variables.
Overly permissive RBAC; avoid global admin access by default.
Skipping migrations; alter schemas without migrations leads to drift.

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

FAQ

What stack is this Cursor Rules Template tailored for?

It targets a Node.js with Express backend and PostgreSQL database, designed for a multi-tenant SaaS with workspaces, boards, and file uploads.

How does workspace isolation work in this template?

Workspaces provide tenant-scoped data partitions. Access controls enforce per-workspace permissions, and repository patterns ensure queries always filter by active workspace context, preventing cross-tenant data leakage.

How should file uploads be handled?

Uploads go to a dedicated storage service with validation on size/type, signed URLs for clients, and strict access controls surrounding files attached to tasks, comments, and boards.

What testing strategy is recommended?

Use unit tests for isolated components, integration tests for API and DB interactions, and end-to-end tests for user journeys. CI runs linting, tests, and migrations on every push.

What AI restrictions does this template enforce?

Avoid generating secrets, unsafe SQL, or production credentials. Do not assume a specific ORM; prefer repository patterns and parameterized queries. Ensure prompts do not mutate production data or rely on in-memory seeds.

Target User

Use Cases