openai/render-scaling

Render Scaling

This skill covers how to scale Web Services, Private Services, and Background Workers on Render: manual instance counts, Professional+ autoscaling, plan (instance type) choices, and platform limits. Deeper tables and tuning guidance live under references/.

When to Use

• Setting or changing instance count (Dashboard, CLI, API, or Blueprint)
• Configuring autoscaling (min/max, CPU and memory targets)
• Choosing vertical (plan) vs horizontal (more instances) scaling
• Understanding constraints (disks, static sites, cron/workflows, 100-instance cap)
• Cost implications of multi-instance and per-second billing
• Blueprint fields: numInstances, scaling, plan

Manual Scaling

• Set instance count from 1 to 100 via the Dashboard, CLI, or API.
• All instances share the same instance type (plan); you cannot mix plans on one service.
• Changes apply immediately: Render provisions new instances and deprovisions excess capacity as needed.

Autoscaling

• Available on Professional and higher workspaces only.
• Configure minimum and maximum instances and targets for CPU and/or memory utilization (1–90% each).
• At least one metric must be enabled (CPU or memory). If both CPU and memory autoscaling toggles are off, autoscaling is disabled.
• If both manual instance settings and autoscaling are configured, autoscaling wins—manual count does not override the scaling policy in effect.

Autoscaling Formula

Render computes a candidate instance count from utilization vs target:

new_instances = ceil(current_instances * (current_utilization / target_utilization))

• When both CPU and memory targets are set, the platform uses the larger of the two new_instances values (the more conservative scale-out).

Scaling Constraints

| Constraint | Behavior | |------------|----------| | Per service | Maximum 100 instances | | Persistent disk | Cannot scale to multiple instances—single instance only | | Static sites | Not scalable (served by CDN) | | Cron jobs & Workflows | Scaling model does not apply (different execution model) |

Scale-Down Behavior

• Scale-up is immediate when utilization supports it.
• Scale-down waits a few minutes after conditions allow reduction (spike protection). This reduces flapping from brief load spikes.

Instance Types

• In Blueprints, the instance type is the plan field (e.g. standard, pro).
• Options span free / starter through standard, pro, pro_plus, pro_max, pro_ultra—each with defined CPU and RAM (see references/instance-types.md).

Vertical vs Horizontal

| Need | Approach | When | |------|----------|------| | More throughput | Horizontal (add instances) | Stateless services, request-based workloads | | More RAM/CPU per process | Vertical (upgrade plan) | Memory-intensive or single-threaded apps | | Both | Combine | Right-size plan, then scale out for traffic |

Cost Patterns

• Per-second billing; no separate fee for scaling actions.
• You pay roughly for compute time × number of running instances (see Render pricing for current rates).
• Right-size by monitoring CPU and memory utilization (see render-monitor).

Blueprint Configuration

Manual instance count:

numInstances: 3

Autoscaling:

scaling:
  minInstances: 1
  maxInstances: 10
  targetCPUPercent: 70
  targetMemoryPercent: 80

Instance type (plan):

plan: standard

Do not rely on numInstances to cap autoscaling when a scaling block is present—autoscaling takes precedence. Preview behavior for scaling is detailed in references/autoscaling-guide.md.

References

| Topic | File | |--------|------| | Plan names, CPU/RAM, flexible vs non-flexible, free tier | references/instance-types.md | | Enabling autoscaling, targets, min/max, mistakes, previews | references/autoscaling-guide.md |

Related Skills

• render-web-services — Web Service settings, disks, deploy lifecycle
• render-background-workers — Worker-specific configuration and scaling context
• render-blueprints — Full Blueprint schema and field reference
• render-monitor — Metrics, logs, and utilization for right-sizing