DeepSeek V3 DevOps and Infrastructure Rules

# DeepSeek V3 DevOps Rules

## Infrastructure as Code Standards
- All infrastructure MUST be defined in code (Terraform, CDK, or Pulumi)
- No manual changes to production infrastructure
- State files stored in remote backends with locking (S3+DynamoDB, GCS)
- Modules for reusable components, with versioned releases

## Security Requirements (NON-NEGOTIABLE)
1. No hardcoded secrets — use AWS Secrets Manager, Vault, or SSM Parameter Store
2. All S3 buckets: block public access, enable versioning, enable encryption
3. IAM: least privilege, no wildcard (*) permissions in production policies
4. Network: private subnets for databases, public subnets only for load balancers
5. Encryption: at-rest (AES-256) and in-transit (TLS 1.2+) for all data stores
6. Audit logging: CloudTrail, VPC Flow Logs, or equivalent enabled

## CI/CD Pipeline Rules
- Build, test, security scan, deploy — in that order
- Deployments to production require manual approval gate
- Rollback capability for every deployment (blue-green or canary)
- Secret scanning on every commit (truffleHog, git-secrets)
- Dependency vulnerability scanning (Snyk, npm audit, safety)

## Monitoring and Alerting
- Service Level Objectives (SLOs) defined for all critical services
- Dashboards: latency (p50/p95/p99), error rate, saturation
- Alerts: page for SLO burn rate, ticket for non-urgent
- On-call runbooks for every alert that pages

## Docker Rules
- Multi-stage builds to minimize image size
- Non-root user (USER 1001)
- Health checks defined
- No latest tag in production — pin exact versions
- .dockerignore excluding node_modules, .git, tests