Render Scaling

This skill covers how to scale Web Services, Private Services, and Background Workers on Render: manual instance counts, autoscaling with a Pro workspace or higher, 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 running more or larger instances
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 only with a Pro workspace or higher.
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).
Web services support free through pro ultra; private services and workers support starter through pro ultra. See references/instance-types.md for the valid Blueprint plan names and CPU/RAM.

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

Scaling changes the amount of billable compute by changing the number and size of running instances.
Confirm current compute charges at Render pricing.
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

render-scaling