@vodailoc/kilo-kit-mcp 1.1.0 → 1.2.0

package/skills/engineering/render-deploy/references/service-types.md

@@ -1,450 +1,450 @@
-# Render Service Types
-
-Detailed explanation of each service type available on Render. Choose the right service type based on your application's needs.
-
-## Web Services (`type: web`)
-
-### Purpose
-
-Web services are HTTP servers that handle incoming requests from the internet. They're publicly accessible via HTTPS URLs.
-
-### Use Cases
-
-- **REST APIs**: JSON APIs for mobile apps or frontend applications
-- **GraphQL servers**: GraphQL endpoints for client queries
-- **Web applications**: Server-rendered websites (Django, Rails, Express)
-- **Full-stack frameworks**: Next.js, Nuxt.js, Remix, SvelteKit
-- **WebSocket servers**: Real-time communication servers
-- **SSR applications**: Server-side rendered React, Vue, or Angular apps
-
-### Key Characteristics
-
-- **Public URL**: Automatically assigned `https://[service-name].onrender.com`
-- **Port binding required**: Must bind to `0.0.0.0:$PORT`
-- **Health checks**: Render pings your service to verify it's running
-- **HTTPS**: Automatic SSL/TLS certificates
-- **Load balancing**: Traffic distributed across multiple instances
-- **Custom domains**: Support for your own domain names
-
-### Required Configuration
-
-```yaml
-type: web
-name: my-api
-runtime: node
-buildCommand: npm ci
-startCommand: npm start
-```
-
-### Best Practices
-
-1. **Bind to environment PORT**:
-```javascript
-const PORT = process.env.PORT || 3000;
-app.listen(PORT, '0.0.0.0');
-```
-
-2. **Add health check endpoint**:
-```javascript
-app.get('/health', (req, res) => {
-  res.status(200).json({ status: 'ok' });
-});
-```
-
-3. **Use appropriate timeouts**: Web requests should complete within 30 seconds
-
-4. **Implement graceful shutdown**: Handle SIGTERM signals properly
-
----
-
-## Worker Services (`type: worker`)
-
-### Purpose
-
-Worker services run background tasks without handling HTTP requests. They're not publicly accessible.
-
-### Use Cases
-
-- **Queue processors**: Redis queue, BullMQ, Celery, Sidekiq
-- **Background jobs**: Email sending, image processing, data exports
-- **Event consumers**: Message queue consumers (Kafka, RabbitMQ, etc.)
-- **Data pipeline workers**: ETL processes, data transformation
-- **Scheduled background tasks**: Continuous processes (not cron)
-- **WebSocket backend**: Dedicated WebSocket handler services
-
-### Key Characteristics
-
-- **No public URL**: Not accessible from internet
-- **No port binding**: Doesn't need to listen on a port
-- **No health checks**: Render monitors process health differently
-- **Long-running**: Can run indefinitely
-- **Private communication**: Access via internal networking
-- **Restart on crash**: Automatically restarted if process dies
-
-### Required Configuration
-
-```yaml
-type: worker
-name: queue-processor
-runtime: python
-buildCommand: pip install -r requirements.txt
-startCommand: celery -A tasks worker --loglevel=info
-```
-
-### Best Practices
-
-1. **Connect to message queue**:
-```python
-import redis
-r = redis.from_url(os.environ['REDIS_URL'])
-```
-
-2. **Implement retry logic**: Handle failures gracefully
-
-3. **Monitor queue depth**: Track pending jobs
-
-4. **Log processing status**: Make debugging easier
-
-5. **Graceful shutdown**: Finish current jobs before exiting
-
-### Common Patterns
-
-**Node.js with BullMQ:**
-```yaml
-type: worker
-name: job-processor
-runtime: node
-buildCommand: npm ci
-startCommand: node worker.js
-envVars:
-  - key: REDIS_URL
-    fromDatabase:
-      name: redis
-      property: connectionString
-```
-
-**Python with Celery:**
-```yaml
-type: worker
-name: celery-worker
-runtime: python
-buildCommand: pip install -r requirements.txt
-startCommand: celery -A app.celery worker
-envVars:
-  - key: REDIS_URL
-    fromDatabase:
-      name: redis
-      property: connectionString
-```
-
----
-
-## Cron Jobs (`type: cron`)
-
-### Purpose
-
-Cron jobs run scheduled tasks on a repeating schedule. They execute, complete, and shut down.
-
-### Use Cases
-
-- **Database backups**: Regular automated backups
-- **Report generation**: Daily/weekly reports
-- **Data cleanup**: Delete old records periodically
-- **Cache warming**: Pre-populate caches
-- **Email digests**: Send scheduled email summaries
-- **Data synchronization**: Sync between systems
-- **Batch processing**: Process accumulated data
-
-### Key Characteristics
-
-- **Scheduled execution**: Runs on cron schedule
-- **Automatic shutdown**: Shuts down after completing
-- **No persistent port**: Doesn't maintain listening port
-- **No health checks**: Task either completes or fails
-- **UTC timezone**: All schedules in UTC
-- **Maximum runtime**: Jobs timeout after configured limit
-
-### Required Configuration
-
-```yaml
-type: cron
-name: daily-backup
-runtime: node
-schedule: "0 2 * * *"  # Daily at 2 AM UTC
-buildCommand: npm ci
-startCommand: node scripts/backup.js
-```
-
-### Schedule Format
-
-Standard cron syntax: `minute hour day month weekday`
-
-**Common schedules:**
-
-| Schedule | Description |
-|----------|-------------|
-| `*/5 * * * *` | Every 5 minutes |
-| `0 * * * *` | Every hour |
-| `0 0 * * *` | Daily at midnight UTC |
-| `0 9 * * 1-5` | Weekdays at 9 AM UTC |
-| `0 0 1 * *` | First day of each month |
-| `0 9 * * 1` | Every Monday at 9 AM UTC |
-
-### Best Practices
-
-1. **Handle failures gracefully**: Jobs should be idempotent
-
-2. **Log completion status**: Track success/failure
-
-3. **Set appropriate timeouts**: Match expected job duration
-
-4. **Use UTC times**: All schedules are UTC-based
-
-5. **Test thoroughly**: Test with different data scenarios
-
-### Example Use Cases
-
-**Daily Database Backup:**
-```yaml
-type: cron
-name: db-backup
-runtime: python
-schedule: "0 1 * * *"  # 1 AM UTC daily
-buildCommand: pip install -r requirements.txt
-startCommand: python scripts/backup.py
-envVars:
-  - key: DATABASE_URL
-    fromDatabase:
-      name: postgres
-      property: connectionString
-  - key: S3_BUCKET
-    value: my-backups
-```
-
-**Hourly Cache Refresh:**
-```yaml
-type: cron
-name: cache-refresh
-runtime: node
-schedule: "0 * * * *"  # Top of every hour
-buildCommand: npm ci
-startCommand: node scripts/refresh-cache.js
-```
-
----
-
-## Static Sites (`type: web` + `runtime: static`)
-
-### Purpose
-
-Serve static HTML, CSS, and JavaScript files via CDN. No backend runtime.
-
-### Use Cases
-
-- **Single Page Applications (SPAs)**: React, Vue, Angular apps
-- **Static site generators**: Gatsby, Next.js (static export), Hugo
-- **Documentation sites**: MkDocs, Docusaurus, VitePress
-- **Landing pages**: Marketing sites
-- **Portfolio sites**: Personal websites
-- **JAMstack sites**: Static sites with API integration
-
-### Key Characteristics
-
-- **CDN delivery**: Global edge caching
-- **No backend runtime**: Only serves built files
-- **Build output only**: Serves contents of build directory
-- **Routing support**: Rewrite rules for SPA routing
-- **Custom headers**: Cache control, security headers
-- **Fast deployment**: Quick to build and deploy
-
-### Required Configuration
-
-```yaml
-type: web
-name: frontend
-runtime: static
-buildCommand: npm ci && npm run build
-staticPublishPath: ./dist  # or ./build, ./out, ./public
-```
-
-### Routing for SPAs
-
-Single Page Applications need rewrite rules to handle client-side routing:
-
-```yaml
-type: web
-name: react-app
-runtime: static
-buildCommand: npm ci && npm run build
-staticPublishPath: ./build
-routes:
-  - type: rewrite
-    source: /*
-    destination: /index.html
-```
-
-### Custom Headers
-
-Add cache control and security headers:
-
-```yaml
-type: web
-name: static-site
-runtime: static
-buildCommand: npm ci && npm run build
-staticPublishPath: ./dist
-headers:
-  # Cache static assets
-  - path: /static/*
-    name: Cache-Control
-    value: public, max-age=31536000, immutable
-
-  # Security headers
-  - path: /*
-    name: X-Frame-Options
-    value: DENY
-  - path: /*
-    name: X-Content-Type-Options
-    value: nosniff
-```
-
-### Build Filters
-
-For monorepos, only build when frontend files change:
-
-```yaml
-type: web
-name: frontend
-runtime: static
-buildCommand: npm ci && npm run build
-staticPublishPath: ./dist
-buildFilter:
-  paths:
-    - frontend/**
-  ignoredPaths:
-    - frontend/**/*.test.js
-    - frontend/README.md
-```
-
-### Best Practices
-
-1. **Optimize build output**: Minify, compress, tree-shake
-
-2. **Use proper cache headers**: Long cache for hashed assets
-
-3. **Add security headers**: Protect against common attacks
-
-4. **Configure SPA routing**: Add rewrite rules for client routing
-
-5. **Handle 404s**: Create custom 404.html page
-
----
-
-## Private Services (`type: pserv`)
-
-### Purpose
-
-Internal services accessible only within your Render account. Not exposed to the internet.
-
-### Use Cases
-
-- **Internal APIs**: Services accessed only by other services
-- **Database proxies**: Connection pools, read replicas
-- **Microservices**: Service mesh architectures
-- **Admin tools**: Internal dashboards
-- **Cache layers**: Internal caching services
-- **Message brokers**: Internal message queues
-
-### Key Characteristics
-
-- **No public URL**: Only accessible via internal DNS
-- **Internal networking**: Fast, low-latency connections
-- **Port binding required**: Must bind to `0.0.0.0:$PORT`
-- **Private DNS**: `[service-name].render-internal.com`
-- **Same-account only**: Only accessible from same account
-- **No internet access**: Traffic stays within Render network
-
-### Required Configuration
-
-```yaml
-type: pserv
-name: internal-api
-runtime: node
-buildCommand: npm ci
-startCommand: npm start
-```
-
-### Accessing Private Services
-
-From other services in the same account:
-
-```javascript
-// Use .render-internal.com domain
-const API_URL = 'http://internal-api.render-internal.com:10000';
-```
-
-Or use service references:
-
-```yaml
-services:
-  - type: web
-    name: frontend
-    runtime: node
-    envVars:
-      - key: INTERNAL_API_URL
-        fromService:
-          name: internal-api
-          type: pserv
-          property: hostport
-```
-
-### Best Practices
-
-1. **Use internal DNS**: Always use `.render-internal.com` domains
-
-2. **No authentication needed**: Already isolated to account
-
-3. **Fast communication**: Low latency between services
-
-4. **Simplify architecture**: No need for external load balancers
-
----
-
-## Comparison Table
-
-| Feature | Web | Worker | Cron | Static | Private |
-|---------|-----|--------|------|--------|---------|
-| Public URL | ✅ Yes | ❌ No | ❌ No | ✅ Yes | ❌ No |
-| Port Binding | ✅ Required | ❌ Not needed | ❌ Not needed | ❌ N/A | ✅ Required |
-| Health Checks | ✅ Yes | ❌ No | ❌ No | ❌ N/A | ✅ Yes |
-| Runtime | ✅ Yes | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes |
-| Persistent | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes |
-| Scaling | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes |
-| Use Case | HTTP servers | Background jobs | Scheduled tasks | Static files | Internal services |
-
-## Choosing the Right Service Type
-
-**Use Web Service when:**
-- Your app handles HTTP requests
-- Users need to access it via URL
-- You need load balancing and scaling
-
-**Use Worker Service when:**
-- Processing background jobs
-- Consuming from message queues
-- Running long-lived processes without HTTP
-
-**Use Cron Job when:**
-- Running scheduled tasks
-- Processing doesn't need to be always-on
-- Tasks run periodically (hourly, daily, weekly)
-
-**Use Static Site when:**
-- Serving pre-built HTML/CSS/JS
-- No backend processing needed
-- Want CDN caching and fast delivery
-
-**Use Private Service when:**
-- Service only accessed by other services
-- Want internal-only communication
-- Building microservice architectures
+# Render Service Types
+
+Detailed explanation of each service type available on Render. Choose the right service type based on your application's needs.
+
+## Web Services (`type: web`)
+
+### Purpose
+
+Web services are HTTP servers that handle incoming requests from the internet. They're publicly accessible via HTTPS URLs.
+
+### Use Cases
+
+- **REST APIs**: JSON APIs for mobile apps or frontend applications
+- **GraphQL servers**: GraphQL endpoints for client queries
+- **Web applications**: Server-rendered websites (Django, Rails, Express)
+- **Full-stack frameworks**: Next.js, Nuxt.js, Remix, SvelteKit
+- **WebSocket servers**: Real-time communication servers
+- **SSR applications**: Server-side rendered React, Vue, or Angular apps
+
+### Key Characteristics
+
+- **Public URL**: Automatically assigned `https://[service-name].onrender.com`
+- **Port binding required**: Must bind to `0.0.0.0:$PORT`
+- **Health checks**: Render pings your service to verify it's running
+- **HTTPS**: Automatic SSL/TLS certificates
+- **Load balancing**: Traffic distributed across multiple instances
+- **Custom domains**: Support for your own domain names
+
+### Required Configuration
+
+```yaml
+type: web
+name: my-api
+runtime: node
+buildCommand: npm ci
+startCommand: npm start
+```
+
+### Best Practices
+
+1. **Bind to environment PORT**:
+```javascript
+const PORT = process.env.PORT || 3000;
+app.listen(PORT, '0.0.0.0');
+```
+
+2. **Add health check endpoint**:
+```javascript
+app.get('/health', (req, res) => {
+  res.status(200).json({ status: 'ok' });
+});
+```
+
+3. **Use appropriate timeouts**: Web requests should complete within 30 seconds
+
+4. **Implement graceful shutdown**: Handle SIGTERM signals properly
+
+---
+
+## Worker Services (`type: worker`)
+
+### Purpose
+
+Worker services run background tasks without handling HTTP requests. They're not publicly accessible.
+
+### Use Cases
+
+- **Queue processors**: Redis queue, BullMQ, Celery, Sidekiq
+- **Background jobs**: Email sending, image processing, data exports
+- **Event consumers**: Message queue consumers (Kafka, RabbitMQ, etc.)
+- **Data pipeline workers**: ETL processes, data transformation
+- **Scheduled background tasks**: Continuous processes (not cron)
+- **WebSocket backend**: Dedicated WebSocket handler services
+
+### Key Characteristics
+
+- **No public URL**: Not accessible from internet
+- **No port binding**: Doesn't need to listen on a port
+- **No health checks**: Render monitors process health differently
+- **Long-running**: Can run indefinitely
+- **Private communication**: Access via internal networking
+- **Restart on crash**: Automatically restarted if process dies
+
+### Required Configuration
+
+```yaml
+type: worker
+name: queue-processor
+runtime: python
+buildCommand: pip install -r requirements.txt
+startCommand: celery -A tasks worker --loglevel=info
+```
+
+### Best Practices
+
+1. **Connect to message queue**:
+```python
+import redis
+r = redis.from_url(os.environ['REDIS_URL'])
+```
+
+2. **Implement retry logic**: Handle failures gracefully
+
+3. **Monitor queue depth**: Track pending jobs
+
+4. **Log processing status**: Make debugging easier
+
+5. **Graceful shutdown**: Finish current jobs before exiting
+
+### Common Patterns
+
+**Node.js with BullMQ:**
+```yaml
+type: worker
+name: job-processor
+runtime: node
+buildCommand: npm ci
+startCommand: node worker.js
+envVars:
+  - key: REDIS_URL
+    fromDatabase:
+      name: redis
+      property: connectionString
+```
+
+**Python with Celery:**
+```yaml
+type: worker
+name: celery-worker
+runtime: python
+buildCommand: pip install -r requirements.txt
+startCommand: celery -A app.celery worker
+envVars:
+  - key: REDIS_URL
+    fromDatabase:
+      name: redis
+      property: connectionString
+```
+
+---
+
+## Cron Jobs (`type: cron`)
+
+### Purpose
+
+Cron jobs run scheduled tasks on a repeating schedule. They execute, complete, and shut down.
+
+### Use Cases
+
+- **Database backups**: Regular automated backups
+- **Report generation**: Daily/weekly reports
+- **Data cleanup**: Delete old records periodically
+- **Cache warming**: Pre-populate caches
+- **Email digests**: Send scheduled email summaries
+- **Data synchronization**: Sync between systems
+- **Batch processing**: Process accumulated data
+
+### Key Characteristics
+
+- **Scheduled execution**: Runs on cron schedule
+- **Automatic shutdown**: Shuts down after completing
+- **No persistent port**: Doesn't maintain listening port
+- **No health checks**: Task either completes or fails
+- **UTC timezone**: All schedules in UTC
+- **Maximum runtime**: Jobs timeout after configured limit
+
+### Required Configuration
+
+```yaml
+type: cron
+name: daily-backup
+runtime: node
+schedule: "0 2 * * *"  # Daily at 2 AM UTC
+buildCommand: npm ci
+startCommand: node scripts/backup.js
+```
+
+### Schedule Format
+
+Standard cron syntax: `minute hour day month weekday`
+
+**Common schedules:**
+
+| Schedule | Description |
+|----------|-------------|
+| `*/5 * * * *` | Every 5 minutes |
+| `0 * * * *` | Every hour |
+| `0 0 * * *` | Daily at midnight UTC |
+| `0 9 * * 1-5` | Weekdays at 9 AM UTC |
+| `0 0 1 * *` | First day of each month |
+| `0 9 * * 1` | Every Monday at 9 AM UTC |
+
+### Best Practices
+
+1. **Handle failures gracefully**: Jobs should be idempotent
+
+2. **Log completion status**: Track success/failure
+
+3. **Set appropriate timeouts**: Match expected job duration
+
+4. **Use UTC times**: All schedules are UTC-based
+
+5. **Test thoroughly**: Test with different data scenarios
+
+### Example Use Cases
+
+**Daily Database Backup:**
+```yaml
+type: cron
+name: db-backup
+runtime: python
+schedule: "0 1 * * *"  # 1 AM UTC daily
+buildCommand: pip install -r requirements.txt
+startCommand: python scripts/backup.py
+envVars:
+  - key: DATABASE_URL
+    fromDatabase:
+      name: postgres
+      property: connectionString
+  - key: S3_BUCKET
+    value: my-backups
+```
+
+**Hourly Cache Refresh:**
+```yaml
+type: cron
+name: cache-refresh
+runtime: node
+schedule: "0 * * * *"  # Top of every hour
+buildCommand: npm ci
+startCommand: node scripts/refresh-cache.js
+```
+
+---
+
+## Static Sites (`type: web` + `runtime: static`)
+
+### Purpose
+
+Serve static HTML, CSS, and JavaScript files via CDN. No backend runtime.
+
+### Use Cases
+
+- **Single Page Applications (SPAs)**: React, Vue, Angular apps
+- **Static site generators**: Gatsby, Next.js (static export), Hugo
+- **Documentation sites**: MkDocs, Docusaurus, VitePress
+- **Landing pages**: Marketing sites
+- **Portfolio sites**: Personal websites
+- **JAMstack sites**: Static sites with API integration
+
+### Key Characteristics
+
+- **CDN delivery**: Global edge caching
+- **No backend runtime**: Only serves built files
+- **Build output only**: Serves contents of build directory
+- **Routing support**: Rewrite rules for SPA routing
+- **Custom headers**: Cache control, security headers
+- **Fast deployment**: Quick to build and deploy
+
+### Required Configuration
+
+```yaml
+type: web
+name: frontend
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./dist  # or ./build, ./out, ./public
+```
+
+### Routing for SPAs
+
+Single Page Applications need rewrite rules to handle client-side routing:
+
+```yaml
+type: web
+name: react-app
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./build
+routes:
+  - type: rewrite
+    source: /*
+    destination: /index.html
+```
+
+### Custom Headers
+
+Add cache control and security headers:
+
+```yaml
+type: web
+name: static-site
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./dist
+headers:
+  # Cache static assets
+  - path: /static/*
+    name: Cache-Control
+    value: public, max-age=31536000, immutable
+
+  # Security headers
+  - path: /*
+    name: X-Frame-Options
+    value: DENY
+  - path: /*
+    name: X-Content-Type-Options
+    value: nosniff
+```
+
+### Build Filters
+
+For monorepos, only build when frontend files change:
+
+```yaml
+type: web
+name: frontend
+runtime: static
+buildCommand: npm ci && npm run build
+staticPublishPath: ./dist
+buildFilter:
+  paths:
+    - frontend/**
+  ignoredPaths:
+    - frontend/**/*.test.js
+    - frontend/README.md
+```
+
+### Best Practices
+
+1. **Optimize build output**: Minify, compress, tree-shake
+
+2. **Use proper cache headers**: Long cache for hashed assets
+
+3. **Add security headers**: Protect against common attacks
+
+4. **Configure SPA routing**: Add rewrite rules for client routing
+
+5. **Handle 404s**: Create custom 404.html page
+
+---
+
+## Private Services (`type: pserv`)
+
+### Purpose
+
+Internal services accessible only within your Render account. Not exposed to the internet.
+
+### Use Cases
+
+- **Internal APIs**: Services accessed only by other services
+- **Database proxies**: Connection pools, read replicas
+- **Microservices**: Service mesh architectures
+- **Admin tools**: Internal dashboards
+- **Cache layers**: Internal caching services
+- **Message brokers**: Internal message queues
+
+### Key Characteristics
+
+- **No public URL**: Only accessible via internal DNS
+- **Internal networking**: Fast, low-latency connections
+- **Port binding required**: Must bind to `0.0.0.0:$PORT`
+- **Private DNS**: `[service-name].render-internal.com`
+- **Same-account only**: Only accessible from same account
+- **No internet access**: Traffic stays within Render network
+
+### Required Configuration
+
+```yaml
+type: pserv
+name: internal-api
+runtime: node
+buildCommand: npm ci
+startCommand: npm start
+```
+
+### Accessing Private Services
+
+From other services in the same account:
+
+```javascript
+// Use .render-internal.com domain
+const API_URL = 'http://internal-api.render-internal.com:10000';
+```
+
+Or use service references:
+
+```yaml
+services:
+  - type: web
+    name: frontend
+    runtime: node
+    envVars:
+      - key: INTERNAL_API_URL
+        fromService:
+          name: internal-api
+          type: pserv
+          property: hostport
+```
+
+### Best Practices
+
+1. **Use internal DNS**: Always use `.render-internal.com` domains
+
+2. **No authentication needed**: Already isolated to account
+
+3. **Fast communication**: Low latency between services
+
+4. **Simplify architecture**: No need for external load balancers
+
+---
+
+## Comparison Table
+
+| Feature | Web | Worker | Cron | Static | Private |
+|---------|-----|--------|------|--------|---------|
+| Public URL | ✅ Yes | ❌ No | ❌ No | ✅ Yes | ❌ No |
+| Port Binding | ✅ Required | ❌ Not needed | ❌ Not needed | ❌ N/A | ✅ Required |
+| Health Checks | ✅ Yes | ❌ No | ❌ No | ❌ N/A | ✅ Yes |
+| Runtime | ✅ Yes | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes |
+| Persistent | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes |
+| Scaling | ✅ Yes | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes |
+| Use Case | HTTP servers | Background jobs | Scheduled tasks | Static files | Internal services |
+
+## Choosing the Right Service Type
+
+**Use Web Service when:**
+- Your app handles HTTP requests
+- Users need to access it via URL
+- You need load balancing and scaling
+
+**Use Worker Service when:**
+- Processing background jobs
+- Consuming from message queues
+- Running long-lived processes without HTTP
+
+**Use Cron Job when:**
+- Running scheduled tasks
+- Processing doesn't need to be always-on
+- Tasks run periodically (hourly, daily, weekly)
+
+**Use Static Site when:**
+- Serving pre-built HTML/CSS/JS
+- No backend processing needed
+- Want CDN caching and fast delivery
+
+**Use Private Service when:**
+- Service only accessed by other services
+- Want internal-only communication
+- Building microservice architectures