Choosing Between Manual Dyno Scaling and Auto‑Scaling on Scalingo: A Practical Decision Guide

What Decision Are You Facing?

When you deploy an application on Scalingo, you must decide how many dynos (runtime containers) it should run. Two supported approaches exist:

• Manual scaling – you explicitly set a fixed number of dynos.
• Auto‑scaling – you enable Scalingo to adjust dyno counts automatically based on real‑time metrics.

The choice affects cost, operational effort, and the ability to handle traffic spikes. This guide helps you weigh both options and shows a concrete configuration to validate your decision.

Constraints to Consider

• Traffic predictability: If your traffic follows a known schedule (e.g., nightly batch jobs), manual scaling can be efficient.
• Cost sensitivity: Both modes charge per dyno per hour, but auto‑scaling may add a small overhead for metric collection.
• Operational discipline: Manual scaling requires you to monitor traffic and adjust dynos; auto‑scaling removes that need but introduces configuration complexity.
• Metric availability: Auto‑scaling relies on CPU, request count, or custom metrics. Ensure the chosen metric accurately reflects load.
• Maximum dyno limits: Scalingo imposes a hard cap per app. Exceeding it triggers errors, so set the auto‑scaling upper bound accordingly.

Compact Comparison Table

Feature	Manual Scaling	Auto‑Scaling
Control granularity	Exact dyno count	Dynamic, metric‑driven count
Operational effort	High – manual adjustments needed	Low – configuration only
Responsiveness to spikes	Depends on human reaction	Automatic, within cooldown limits
Cost predictability	Fixed – simple budgeting	Variable – depends on traffic patterns
Risk of thrashing	None – stable count	Possible if thresholds are mis‑tuned
Metric lag	Not applicable	Potential delay in scaling decisions
Pricing model	Per‑dyno per hour	Same per‑dyno, plus minimal monitoring fee

Trade‑Offs Explained

Control vs. Automation

Manual scaling gives you absolute control over how many dynos run at any time. This is ideal when you have a predictable workload or a strict budget. However, it demands constant monitoring; a traffic surge can overwhelm your app until you manually add dynos.

Auto‑scaling removes that operational burden. Scalingo’s load balancer and metric engine adjust dyno counts based on thresholds you set. The trade‑off is that you must choose thresholds carefully; too aggressive settings cause thrashing (frequent up/down scaling), while too conservative settings can lead to under‑provisioning.

Cost Predictability vs. Flexibility

With manual scaling, you pay a flat rate for the dynos you specify. Auto‑scaling introduces variability: during low traffic you might save money, but during peaks you pay for additional dynos. The cost difference is usually modest, but if your budget is tight, manual scaling can simplify financial forecasting.

Metric Lag and Overshoot

Auto‑scaling decisions are based on sampled metrics (e.g., CPU usage every 30 seconds). If traffic spikes faster than the sampling interval, the system may scale up only after the spike has already peaked, potentially causing brief latency. Setting a sensible cooldown period (e.g., 5 minutes) helps mitigate overshoot.

Concrete Implementation Example

Below is a minimal scalingo.yml that demonstrates auto‑scaling based on CPU usage while also showing how to manually set a baseline dyno count.

# scalingo.yml – auto‑scaling example
# Baseline: 2 web dynos
# Auto‑scaling: add up to 4 extra dynos when CPU > 70%

auto_scaling:
  web:
    min: 2
    max: 6
    threshold:
      cpu: 70
    cooldown: 300  # seconds

Deploy the configuration with:

# Run in the root of your project directory
scalingo deploy --config scalingo.yml

After deployment, Scalingo will maintain at least 2 web dynos. If the average CPU usage across the existing dynos exceeds 70% for a continuous 300‑second window, Scalingo will spawn additional dynos up to a total of 6. When the CPU falls below the threshold, it will scale down, respecting the cooldown to avoid rapid churn.

Validating the Setup

1. Check the current dyno count:

   # Requires the Scalingo CLI and app context
   scalingo dyno
   # Output will list 'web' dynos and their count
   

2. Simulate a traffic burst:

   Send a burst of requests (e.g., using ab or wrk) to your app’s URL. Observe the dashboard or run scalingo logs --tail to see scaling events like "Scaling up web to 4".

3. Verify cost impact:

   Export your billing data for a week after enabling auto‑scaling and compare it to a week with manual scaling. The per‑dyno charges should match; any difference will be due to the extra monitoring overhead.

When to Choose Manual Scaling

• Your traffic follows a strict schedule (e.g., nightly data imports) and you can pre‑allocate dynos for each period.
• Budget constraints require a fixed monthly cost with no surprises.
• You have the operational capacity to monitor and adjust dynos proactively.

When to Choose Auto‑Scaling

• Traffic is unpredictable or subject to sudden spikes (e.g., e‑commerce during sales).
• You prefer to reduce operational overhead and trust Scalingo’s metric engine.
• You can tolerate a small cost variance and want to pay only for the resources you actually use.

Practical Checklist Before Switching

• Confirm the current dyno rates on Scalingo’s pricing page.
• Set max to a value that respects your budget and the platform’s dyno limit.
• Choose a metric that closely correlates with request latency (CPU or request count).
• Start with a conservative threshold (e.g., 70% CPU) and monitor for thrashing.
• Use the scalingo logs command to audit scaling events.

Final Decision Path

1. Identify traffic patterns – predictable or volatile?
2. Budget assessment – fixed or flexible?
3. Operational capacity – can you monitor and adjust dynos manually?
4. Risk tolerance – how much latency or cost variance is acceptable?

Answering these questions will point you toward manual scaling for controlled, predictable workloads, or auto‑scaling for dynamic, traffic‑driven applications. Use the example scalingo.yml above to prototype the chosen strategy and validate it with real traffic before committing to production.