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.

Related implementation resources: AI Use Case for Geotechnical Firms Using Core Sample Records To Predict Soil Stability for Heavy Foundation Building and Why AI-assisted product development needs repeatable, production-grade systems.

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.