Rust Leptos SSR Cursor rules template for Cargo | Cursor Rules Template

Overview

This Cursor rules configuration defines how Cursor AI should assist in building a Rust Leptos SSR (Server-Side Rendering) stack managed by Cargo. It establishes role, context, stack-specific constraints, and safe AI guidance for architecture, security, testing, and deployment. The goal is a copyable, production-ready .cursorrules block that developers can paste into their project root to align Cursor AI behavior with this stack.

Direct answer: Paste the code block in the Copyable .cursorrules Configuration section to enable Cursor AI to operate under Rust Leptos SSR constraints, powered by Cargo, SQLx for data access, and JWT-based auth in a secure, testable environment.

When to Use These Cursor Rules

• Starting a Rust Leptos SSR project and enabling Cursor AI to guide development.
• Enforcing architecture boundaries between server, client, and shared code in a SSR app.
• Integrating SQLx for safe DB access and ensuring prepared statements usage.
• Setting up authentication patterns (JWT, cookies) and session handling securely.
• Automating linting and testing workflows in CI for a Cargo-based project.

Copyable .cursorrules Configuration

// Cursor rules configuration for Rust Leptos SSR with Cargo
cursorrules {
  // Framework Role & Context
  frameworkRole: "Cursor AI acts as a senior Rust Leptos SSR engineer guiding safe AI-assisted development. You operate in a Cargo-based server-rendered web app with a WASM client, SQLx data access, and JWT-based auth. Maintain strict boundaries between server and client code.",
  context: "Rust, Leptos, SSR, Cargo, WASM client, SQLx, JWT, rustfmt, clippy, and CI/CD. Focus on secure defaults, explicit APIs, and clear module ownership.",

  // Code Style and Style Guides
  codeStyle: "rustfmt for formatting; clippy with -D warnings; idiomatic Rust; avoid unsafe blocks unless documented; consistent module layout.",

  // Architecture & Directory Rules
  architecture: {
    root: "/",
    serverDir: "src/server",
    clientDir: "src/client",
    sharedDir: "src/shared",
    dbDir: "src/db",
    routesDir: "src/routes",
    testsDir: "tests"
  },

  // Authentication & Security Rules
  auth: {
    jwt: true,
    cookies_secure: true,
    http_only: true,
    csrf_protect: true
  },

  // Database and ORM patterns
  database: {
    orm: "sqlx",
    migrations: "sqlx migrate run",
    poolSize: 15,
    patterns: ["use prepared statements", "parameterized queries", "avoid string-concat SQL"]
  },

  // Testing & Linting Workflows
  testing: {
    unit: true,
    integration: true,
    endToEnd: false,
    ci: "github-actions",
    commands: ["cargo test -- --nocapture", "cargo fmt -- --check", "cargo clippy -- -D warnings"]
  },

  // Prohibited Actions and Anti-patterns for the AI
  antiPatterns: [
    "Do not use unsafe Rust blocks without explicit justification and code review.",
    "Do not bypass wasm-bindgen conventions or create unsafe FFI surfaces.",
    "Do not construct SQL via string concatenation; always use prepared statements.",
    "Do not mix server and client secrets; avoid leaking credentials in code.",
    "Do not bypass type-safe boundaries between server, routes, and data access layers."
  ]
}

Recommended Project Structure

/project-root
├─ src
│  ├─ server
│  │  ├─ main.rs
│  │  ├─ routes
│  │  │  └─ mod.rs
│  │  ├─ handlers
│  │  │  └─ mod.rs
│  │  └─ middleware
│  │     └─ mod.rs
│  ├─ client
│  │  ├─ index.html
│  │  └─ app.ts
│  ├─ shared
│  │  └─ lib.rs
│  ├─ db
│  │  ├─ mod.rs
│  │  └─ models.rs
│  └─ routes
│     └─ mod.rs
├─ tests
│  └─ integration
│     └─ mod.rs
├─ Cargo.toml
└─ README.md

Core Engineering Principles

• Clear separation of concerns between server, client, and data access layers.
• Rule-driven AI assistance with explicit architecture and security constraints.
• Type-safe interfaces and minimal unsafe usage with rigorous reviews.
• Automated testing and linting integrated into CI/CD pipelines.
• Immutable configuration and explicit dependency versions to reduce drift.

Code Construction Rules

• All DB access must use parameterized queries via SQLx; never concatenate SQL.
• Server routes must be clearly separated from client code; shared types must live in src/shared.
• Authentication must use JWTs stored in httpOnly, secure cookies; implement CSRF protection.
• Rust code must follow rustfmt formatting and pass clippy with -D warnings.
• All crates should compile with a stable toolchain; pin to exact versions in Cargo.lock for reproducibility.
• Cursor AI responses should not infer privileged secrets or bypass auth checks.

Security and Production Rules

• Enable CSRF protection for state-changing endpoints and validate JWTs on protected routes.
• Use secure, httpOnly cookies with SameSite policies appropriate to your app.
• Do not expose DB credentials or API keys in frontend bundles; use server-side vaults and environment separation.
• Restrict WASM module imports and apply strict content security policies for client code.
• Audit dependencies regularly; prefer crates with active maintenance and known security records.

Testing Checklist

• Unit tests for server handlers and shared types.
• Integration tests for routes, auth flows, and DB interactions via SQLx.
• Smoke tests in CI to ensure build, test, and lint succeed on push and PRs.
• Run cargo test, cargo fmt, and cargo clippy as part of PR checks.
• Verify WASM client compatibility and end-to-end rendering with SSR pages.

Common Mistakes to Avoid

• Using unsafe code blocks without documented justification and review.
• Mixing server and client secrets or bypassing secure storage patterns.
• Building SQL strings with concatenation; never interpolate user input directly.
• Neglecting to validate JWTs or invalidate stale sessions on logout.
• Overloading routes with business logic that should reside in domain services.

FAQ

What is this Cursor rules template for Rust Leptos SSR with Cargo?

This Cursor rules template defines how Cursor AI should operate in a Rust Leptos SSR stack managed by Cargo. It presets roles, context, patterns, and anti-patterns to guide AI-assisted development, secure coding practices, and testable architecture.

What should be included in the Framework Role & Context?

The role informs Cursor AI that it is a senior Rust Leptos SSR engineer guiding safe AI-powered decisions. Context covers SSR, WASM client, Cargo, SQLx, and JWT-based auth, emphasizing clear module ownership and secure defaults.

How do I structure Architecture & Directory Rules for this stack?

Define a clear boundary: server code under src/server, client under src/client, shared types under src/shared, database access under src/db, and tests under tests. Keep routes and handlers modular and avoid cross-layer leakage of concerns.

What testing and linting workflows are recommended?

Adopt cargo test for unit/integration tests, cargo fmt for formatting checks, and cargo clippy for linting with -D warnings. Integrate into CI (GitHub Actions) and ensure tests cover server routes, data access, and SSR rendering.

What common mistakes should I avoid?

Avoid unsafe blocks without justification, concatenated SQL, leaking credentials, and mixing server/client concerns. Ensure proper JWT handling, CSRF protection, and consistent module boundaries to prevent architecture drift.