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
1---2name: render-scaling3description: Scales Render services—configures autoscaling targets, chooses instance types, sets manual instance counts, and optimizes cost. Use when the user needs to handle more traffic, set up autoscaling, pick the right instance type, reduce costs, or troubleshoot scaling behavior like slow scale-down or stuck instances.4license: MIT5---6
7# Render Scaling
8
9This 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/`.
10
11## When to Use
12
13- Setting or changing **instance count** (Dashboard, CLI, API, or Blueprint)
14- Configuring **autoscaling** (min/max, CPU and memory targets)
15- Choosing **vertical** (plan) vs **horizontal** (more instances) scaling
16- Understanding **constraints** (disks, static sites, cron/workflows, 100-instance cap)
17- **Cost** implications of running more or larger instances
18- **Blueprint** fields: `numInstances`, `scaling`, `plan`
19
20## Manual Scaling
21
22- Set **instance count** from **1 to 100** via the **Dashboard**, **CLI**, or **API**.
23- **All instances share the same instance type** (plan); you cannot mix plans on one service.
24- Changes apply **immediately**: Render **provisions** new instances and **deprovisions** excess capacity as needed.
25
26## Autoscaling
27
28- Available only with a **Pro workspace or higher**.
29- Configure **minimum** and **maximum** instances and targets for **CPU** and/or **memory** utilization (**1–90%** each).
30- **At least one metric must be enabled** (CPU or memory). If **both** CPU and memory autoscaling toggles are **off**, autoscaling is **disabled**.
31- If **both** manual instance settings and autoscaling are configured, **autoscaling wins**—manual count does not override the scaling policy in effect.
32
33## Autoscaling Formula
34
35Render computes a candidate instance count from utilization vs target:
36
37`new_instances = ceil(current_instances * (current_utilization / target_utilization))`
38
39- When **both** CPU and memory targets are set, the platform uses the **larger** of the two `new_instances` values (the more conservative scale-out).
40
41## Scaling Constraints
42
43| Constraint | Behavior |
44|------------|----------|
45| **Per service** | **Maximum 100** instances |
46| **Persistent disk** | **Cannot** scale to multiple instances—**single instance only** |
47| **Static sites** | **Not** scalable (served by CDN) |
48| **Cron jobs & Workflows** | Scaling model **does not apply** (different execution model) |
49
50## Scale-Down Behavior
51
52- **Scale-up** is **immediate** when utilization supports it.
53- **Scale-down** waits **a few minutes** after conditions allow reduction (**spike protection**). This reduces **flapping** from brief load spikes.
54
55## Instance Types
56
57- In Blueprints, the instance type is the **`plan`** field (e.g. `standard`, `pro`).
58- 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.
59
60### Vertical vs Horizontal
61
62| Need | Approach | When |
63|------|----------|------|
64| More throughput | **Horizontal** (add instances) | Stateless services, request-based workloads |
65| More RAM/CPU per process | **Vertical** (upgrade **plan**) | Memory-intensive or single-threaded apps |
66| Both | **Combine** | Right-size plan, then scale out for traffic |
67
68## Cost Patterns
69
70- Scaling changes the amount of billable compute by changing the number and size of running instances.
71- Confirm current compute charges at [Render pricing](https://render.com/pricing).
72- **Right-size** by monitoring **CPU and memory** utilization (see **render-monitor**).
73
74## Blueprint Configuration
75
76**Manual instance count:**
77
78```yaml
79numInstances: 3
80```
81
82**Autoscaling:**
83
84```yaml
85scaling:
86 minInstances: 1
87 maxInstances: 10
88 targetCPUPercent: 70
89 targetMemoryPercent: 80
90```
91
92**Instance type (plan):**
93
94```yaml
95plan: standard
96```
97
98Do 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`.
99
100## References
101
102| Topic | File |
103|--------|------|
104| Plan names, CPU/RAM, flexible vs non-flexible, free tier | `references/instance-types.md` |
105| Enabling autoscaling, targets, min/max, mistakes, previews | `references/autoscaling-guide.md` |
106
107## Related Skills
108
109- **render-web-services** — Web Service settings, disks, deploy lifecycle
110- **render-background-workers** — Worker-specific configuration and scaling context
111- **render-blueprints** — Full Blueprint schema and field reference
112- **render-monitor** — Metrics, logs, and utilization for right-sizing
render-oss