NestJS + Redis Enterprise + Auth0 Auth + RedisOM Cache Ingestion Inlines — CLAUDE.md Template (CLAUDE.md template)

Overview

This CLAUDE.md template page documents a full-stack NestJS + Redis Enterprise + Auth0 authentication flow with RedisOM cache ingestion inlines. It targets a production-ready API stack where NestJS provides the API surface, Redis Enterprise stores and caches domain aggregates, Redis OM maps entities to Redis, and Auth0 handles authentication and authorization. The included copyable CLAUDE.md block enables you to bootstrap Claude Code instructions for this exact stack.

Direct answer: This page yields a complete CLAUDE.md template with concrete guidance for architecture, file structure, security, tests, and deployment for a NestJS + Redis Enterprise + Auth0 + RedisOM ingestion pipeline.

When to Use This CLAUDE.md Template

• You are building a NestJS API that relies on Redis Enterprise for persistence and cache layers.
• You need Auth0 for OAuth/OIDC authentication and fine grained access controls.
• Redis OM is used to map TypeScript classes to Redis hashes for rapid caching and ingestion pipelines.
• You require a copyable CLAUDE.md template to enforce architecture, security, and deployment rules.
• You want inline cache ingestion patterns that keep latency predictable in a high-throughput API.

Copyable CLAUDE.md Template

# CLAUDE.md

Project role
- You are Claude Code, a precision-focused assistant that outputs a complete CLAUDE.md template for a NestJS + Redis Enterprise + Auth0 + RedisOM stack.
- You must provide a ready-to-paste CLAUDE.md block that includes architecture rules, file structure rules, authentication rules, database rules, validation rules, security rules, testing rules, deployment rules, and explicit Things Claude Must Not Do.

Architecture rules
- Use a modular NestJS architecture: api, domain, application, and infra layers.
- Redis Enterprise is the source of truth for domain aggregates and session/cache data; Redis OM maps TS classes to Redis entities.
- Auth0 is the sole authentication/authorization boundary; validate and refresh tokens on every protected route.
- All communication between services uses TLS; secrets and credentials are stored in environment variables or a secrets manager.
- Use explicit, typed Redis OM schemas for each aggregate; avoid dynamic string keys without types.
- Ingest data via a dedicated IngestionService that normalizes and caches results on write.

File structure rules
- apps/api/src/
- apps/api/src/main.ts
- apps/api/src/app.module.ts
- apps/api/src/modules/auth/
- apps/api/src/modules/cache/
- apps/api/src/modules/ingest/
- infra/redis/
- infra/auth0/
- config/
- lib/types/

Authentication rules
- All protected endpoints require a valid Auth0 JWT with audience and scope checks.
- Use Passport strategies for JWTs and enforce RBAC/ABAC where applicable.
- Do not store Auth0 credentials in code; pull from environment/config vaults.

Database rules
- Redis Enterprise used via Redis OM models; all models must have explicit schemas.
- Use Redis secured connections with ACL-based access control.
- Do not mix Redis OM models with raw string keys for the same data; prefer typed models.

Validation rules
- Use class-validator with DTOs for request validation.
- Fail fast with clear, actionable error messages.
- Validate input shapes for ingestion pipelines; reject malformed payloads.

Security rules
- Do not hard-code secrets; fetch from environment or vault.
- Enforce JWT expiry/issuer checks and token revocation handling.
- Enforce TLS and secure cookies for web clients; use HttpOnly, Secure flags.
- Minimize surface area on auth to service accounts only; use role-based access control in Redis ACLs.

Testing rules
- Unit tests for AuthService, Redis OM models, IngestionService.
- Integration tests validating Auth0 JWT verification, Redis OM CRUD paths, and ingestion endpoints.
- E2E tests that simulate a token-protected request flow from a client to the API.

Deployment rules
- Ensure TLS termination at the edge; use proper secret provisioning in CI/CD.
- Run type checks, lint, unit/integration tests in CI before merge.
- Use immutable deployments for API services; rollout canary tests first.

Things Claude must not do
- Do not expose plain Redis keys or private credentials in code blocks.
- Do not bypass Auth0 or skip token validation.
- Do not rely on in-memory caches for production critical data without Redis OM backing.

Recommended Project Structure

apps/api/
  src/
    main.ts
    app.module.ts
    modules/
      auth/
        auth.controller.ts
        auth.service.ts
        jwt.strategy.ts
      cache/
        cache.controller.ts
        cache.service.ts
        redis-om-models.ts
      ingest/
        ingest.controller.ts
        ingest.service.ts
        ingest.processor.ts
  test/
  tsconfig.json
infra/redis/
  redis.config.ts
  redis.client.ts
infra/auth0/
  auth0.config.ts
  auth0.middleware.ts
config/
  environment.ts
  secrets.config.ts
lib/types/
  redis-om-types.ts
  dto-types.ts

Core Engineering Principles

• Clear architectural boundaries between API, domain, and infrastructure.
• Typed data with Redis OM to reduce runtime casting and errors.
• Immutable deployment and repeatable environments (CI/CD).
• Security-first: Auth0, TLS, and Redis ACLs are mandatory.
• Idempotent ingestion and deterministic cache invalidation.

Code Construction Rules

• Use NestJS Modules for auth, cache, and ingestion separately.
• Define Redis OM models with explicit schemas; avoid ad-hoc keys.
• DTOs with class-validator for all API requests; fail-fast on invalid data.
• Use environment-based configuration; never hard-code secrets.
• In ingestion, validate and coerce payloads before Redis writes; use deterministic keys for caches.
• Do not mix Redis OM with non-typed Redis commands for critical data.

Security and Production Rules

• Enforce Auth0 JWT validation on all protected routes; validate audience and issuer.
• Use TLS for all external calls; rotate secrets regularly via a secret store.
• Implement Redis ACLs per service role and limit cache access to the minimal required keys.
• Do not disable HTTP security headers; enable CSP, HSTS, and secure cookies where appropriate.

Testing Checklist

• Unit tests for AuthService, Redis OM models, ingest logic.
• Integration tests for JWT validation and Redis OM CRUD flows.
• End-to-end tests across login, token retrieval, and a sample ingestion path.
• Performance tests to ensure Redis OM returns within SLA during ingestion bursts.
• Deployment checks for secret provisioning and environment parity.

Common Mistakes to Avoid

• Skipping token validation or using static tokens in tests only.
• Writing raw Redis calls without Redis OM typing leading to schema drift.
• Ignoring Redis Enterprise ACLs and credential rotation during deployment.
• Overloading an API route with heavy ingestion logic, breaking single-responsibility principle.

Related implementation resources: AI Agent Use Case for Packaging Designers Using Box Drop-Test Telemetry To Design Shock-Absorbent Corrugated Structures.

FAQ

Q: What is the purpose of this CLAUDE.md Template page?
A: It provides a copyable CLAUDE.md template for a NestJS + Redis Enterprise + Auth0 + RedisOM stack with inline cache ingestion to expedite reproducible architecture and Claude Code guidance.

Q: Which stack components are covered?
A: NestJS API, Redis Enterprise data/cache store, Auth0 for authentication, and Redis OM for model-backed caching and ingestion.

Q: What should Claude implement in the CLAUDE.md block?
A: Project role, architecture rules, file structure, authentication rules, database rules, validation rules, security rules, testing rules, deployment rules, and explicit Things Claude Must Not Do.

Q: How is security enforced in this template?
A: OAuth2/OIDC with Auth0, TLS, Redis ACLs, environment-based secrets, and explicit do-not-use guidance to avoid unsafe patterns.

Q: Where can I find the recommended project structure?
A: In the Recommended Project Structure section, showing a NestJS + Redis OM + Auth0 layout.