Scaling on Render: manual instances, autoscaling, and instance types
Cloud Computing's own auto-scaling lesson covered the general principle — add or remove capacity automatically based on real demand. Render's specific implementation is a concrete, concretely-configurable instance of that principle, and understanding its specific knobs matters more than the general concept alone.
Intermediate
2 min read
Vertical scaling first: choosing an instance type
Starter: 512 MB RAM, 0.5 CPU
Standard: 2 GB RAM, 1 CPU
Pro: 4 GB RAM, 2 CPU
...
Render offers a fixed menu of instance sizes per service — moving to a larger instance type (vertical scaling) gives a single running instance more RAM and CPU, the right first move for a service that's genuinely resource-constrained (running out of memory, CPU-bound on a single request) rather than needing more parallel capacity.
Horizontal scaling: more instances, the same service
Horizontal scaling runs multiple instances of the same service simultaneously, with Render's load balancer distributing incoming requests across all of them — the right move for a service that's handling more concurrent requests than one instance can serve, rather than one that's slow because any single request itself needs more resources. Confusing these two (throwing more instances at a problem that's actually about one request needing more memory, or upgrading instance size for a problem that's actually about request volume) is a real, common mis-diagnosis — the fix for each is genuinely different.
Autoscaling: horizontal scaling driven automatically by real load
Autoscaling config:
Min instances: 2
Max instances: 10
Target CPU: 70%
Rather than a team manually adjusting instance count as traffic changes, autoscaling watches a metric (CPU utilization being the most common) and adds or removes instances automatically to keep that metric near a target — directly implementing Cloud Computing's own general auto-scaling principle, with Render's own specific configuration surface (a min/max instance range, and the target metric/threshold).
The real cost of getting the min/max range wrong
Min too low → a sudden traffic spike arrives before autoscaling
can react, and the few running instances get
overwhelmed before new ones finish starting
Max too low → genuine demand exceeds what even the maximum
instance count can serve, with no further
headroom to scale into
Max too high → a runaway scaling event (a bug causing abnormally
high CPU usage, say) scales toward the maximum
and generates a correspondingly large bill
Autoscaling's min/max range is a real, deliberate trade-off between responsiveness to genuine demand and protection against both under-provisioning during a real spike and open-ended cost exposure during a misbehaving deploy — setting these values thoughtfully, rather than leaving them at an untested default, matters for exactly the same reason Railway's own usage-based-pricing lesson named a spending limit as a real, practical safeguard rather than an optional nicety.