.cursorrules in survivorforge/cursor-rules runs 1,050 words across 13 headings.
🤖 Curated collection of .cursorrules files for Cursor IDE — boost your AI coding with framework-specific rules for React, Next.js, Python, Node.js, and more
Covers
7 of the 20 section tags
In the order a file is read inHeadings
13 headings, in the order the file writes them
01DevOps & Infrastructure — Cursor Rules
02Production infrastructure: Terraform, Docker, CI/CD, Kubernetes, and operational excellence
03Project Context
04Terraform Patterns
05Terraform Best Practices
06Docker Best Practices
07CI/CD Pipeline (GitHub Actions)
08Kubernetes Patterns
09Monitoring and Alerting
10Secret Management
11Disaster Recovery
12Security
13Common Mistakes to Avoid
Commands
6 commands this file writes down
Extracted from the file, verbatimterraform.tfvars
terraform plan
terraform apply -auto-approve
node:20.11-alpine
node:latest
docker scout
The file
rules/devops-infrastructure/.cursorrules
First 160 of 214 lines1# DevOps & Infrastructure — Cursor Rules
2# Production infrastructure: Terraform, Docker, CI/CD, Kubernetes, and operational excellence
3
4# Project Context
5You are managing infrastructure-as-code and CI/CD pipelines for a production system. The project
6uses Terraform for cloud infrastructure provisioning, Docker for containerization, GitHub Actions
7for CI/CD, and Kubernetes for orchestration. All infrastructure changes are version-controlled,
8reviewed, and applied through automation.
9
10# Terraform Patterns
11- Organize Terraform by environment and component:
12 ```
13 infrastructure/
14 modules/
15 networking/ # VPC, subnets, security groups
16 database/ # RDS, ElastiCache
17 compute/ # ECS, EKS, EC2
18 monitoring/ # CloudWatch, alerts
19 environments/
20 production/
21 main.tf # Module composition
22 variables.tf # Environment variables
23 terraform.tfvars # Variable values
24 backend.tf # Remote state config
25 staging/
26 ...
27 ```
28- Use modules for reusable infrastructure components.
29- Use remote state (S3 + DynamoDB for AWS) with state locking.
30- Tag ALL resources with: `Environment`, `Project`, `ManagedBy=terraform`, `Owner`.
31- Use `data` sources to reference existing resources, not hardcoded IDs.
32- Use `terraform plan` output in PR reviews before applying.
33
34# Terraform Best Practices
35- Use variables for all configurable values:
36 ```hcl
37 variable "instance_type" {
38 description = "EC2 instance type for application servers"
39 type = string
40 default = "t3.medium"
41 validation {
42 condition = can(regex("^t3\\.", var.instance_type))
43 error_message = "Only t3 instances are allowed."
44 }
45 }
46 ```
47- Use `locals` for computed values used multiple times.
48- Use `output` to expose values needed by other configurations.
49- Use `lifecycle` blocks for zero-downtime updates:
50 ```hcl
51 resource "aws_instance" "web" {
52 lifecycle {
53 create_before_destroy = true
54 }
55 }
56 ```
57- Use `prevent_destroy` on critical resources (databases, S3 buckets with data).
58- DON'T: Store secrets in Terraform state — use a secrets manager.
59- DON'T: Use `terraform apply -auto-approve` in production.
60- DON'T: Hardcode AWS account IDs, regions, or ARNs — use data sources and variables.
61
62# Docker Best Practices
63- Multi-stage builds for minimal production images:
64 ```dockerfile
65 # Build stage
66 FROM node:20-alpine AS builder
67 WORKDIR /app
68 COPY package*.json ./
69 RUN npm ci --only=production && npm cache clean --force
70 COPY . .
71 RUN npm run build
72
73 # Production stage
74 FROM node:20-alpine
75 RUN addgroup -S appgroup && adduser -S appuser -G appgroup
76 WORKDIR /app
77 COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
78 COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
79 USER appuser
80 EXPOSE 3000
81 HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/health || exit 1
82 CMD ["node", "dist/main.js"]
83 ```
84- Always use specific image tags, never `latest`: `node:20.11-alpine`, not `node:latest`.
85- Scan images for vulnerabilities: `docker scout`, `trivy`, or `snyk container`.
86- Keep images small: use Alpine base, multi-stage builds, minimal dependencies.
87- One process per container — don't run multiple services in one container.
88- Use `.dockerignore` to exclude: `.git`, `node_modules`, `tests`, `docs`, `.env`.
89
90# CI/CD Pipeline (GitHub Actions)
91- Standard pipeline stages: lint -> test -> build -> deploy:
92 ```yaml
93 name: CI/CD
94 on:
95 push:
96 branches: [main]
97 pull_request:
98 branches: [main]
99
100 jobs:
101 lint:
102 runs-on: ubuntu-latest
103 steps:
104 - uses: actions/checkout@v4
105 - uses: actions/setup-node@v4
106 with: { node-version: 20, cache: npm }
107 - run: npm ci
108 - run: npm run lint
109
110 test:
111 needs: lint
112 runs-on: ubuntu-latest
113 services:
114 postgres:
115 image: postgres:16
116 env: { POSTGRES_PASSWORD: test }
117 ports: ['5432:5432']
118 steps:
119 - uses: actions/checkout@v4
120 - run: npm ci
121 - run: npm test -- --coverage
122 - uses: actions/upload-artifact@v4
123 with: { name: coverage, path: coverage/ }
124
125 deploy:
126 needs: test
127 if: github.ref == 'refs/heads/main'
128 runs-on: ubuntu-latest
129 environment: production
130 steps:
131 - uses: actions/checkout@v4
132 - run: docker build -t app:${{ github.sha }} .
133 - run: docker push registry/app:${{ github.sha }}
134 - run: kubectl set image deployment/app app=registry/app:${{ github.sha }}
135 ```
136- Cache dependencies between runs (npm cache, Docker layer cache).
137- Run security scans (SAST, dependency audit) in CI.
138- Use GitHub Environments with approval gates for production deploys.
139- Store secrets in GitHub Secrets, not in code or CI config.
140
141# Kubernetes Patterns
142- Use Deployments for stateless services, StatefulSets for stateful.
143- Define resource requests AND limits on every container:
144 ```yaml
145 resources:
146 requests:
147 cpu: 100m
148 memory: 128Mi
149 limits:
150 cpu: 500m
151 memory: 512Mi
152 ```
153- Use ConfigMaps for configuration, Secrets for sensitive data.
154- Define liveness, readiness, and startup probes:
155 ```yaml
156 livenessProbe:
157 httpGet: { path: /health, port: 3000 }
158 initialDelaySeconds: 15
159 periodSeconds: 10
160 readinessProbe:
54 more lines are in the file. Read the raw file.
The rest of the repository
survivorforge/cursor-rules ships 20 other instruction files
rules/api-design-rest/.cursorrulesrules/database-sql/.cursorrulesrules/docker-devops/.cursorrulesrules/go-gin/.cursorrulesrules/nextjs-14-app-router/.cursorrulesrules/nextjs-typescript/.cursorrulesrules/python-django/.cursorrulesrules/python-modern/.cursorrulesrules/react-typescript/.cursorrulesrules/rust-actix/.cursorrulesrules/rust-production/.cursorrulesrules/tailwind-ui/.cursorrulesrules/tailwindcss/.cursorrulesrules/testing-tdd/.cursorrulesrules/typescript/.cursorrulesrules/vue3-composition/.cursorrulesrules/langchain-ai/.cursorrulesrules/saas-starter/.cursorrulesrules/api-microservices/.cursorrulesrules/mobile-react-native/.cursorrules
This listing
Whoever runs survivorforge/cursor-rules can claim it
This is yours? Claim this config and we will write to you when the measurement moves. The check is one token placed where only you can place it, and there is no account and no password.