Render Service Types

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

type: web
name: my-api
runtime: node
buildCommand: npm ci
startCommand: npm start

Best Practices

1. Bind to environment PORT:

const PORT = process.env.PORT || 3000
app.listen(PORT, '0.0.0.0')

2. Add health check endpoint:

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

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:

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:

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:

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

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:

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:

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:

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

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:

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:

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:

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

type: pserv
name: internal-api
runtime: node
buildCommand: npm ci
startCommand: npm start

Accessing Private Services

From other services in the same account:

// Use .render-internal.com domain
const API_URL = 'http://internal-api.render-internal.com:10000'

Or use service references:

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

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