Need more juice? resources:set. Done.

Scaling your application shouldn’t feel like open-heart surgery. It should feel like flipping a switch. Watch your environment adapt in real time. Horizontal scaling. Vertical scaling. One command. Done.

upsun resources:set

You do not want another war room. You want a clear way to add capacity when traffic increases, without editing and testing complex YAML files for hours or manually rolling out scripts across clusters. Upsun enables you to dial in both vertical and horizontal scaling from a single CLI or Web UI, then verify the impact with built-in observability.

How does it work

1. Start with a normal production clone on a feature branch. Every branch in Upsun can be a production-perfect environment with code, services, and data, so you can test the exact change you plan to ship. See What is Upsun guide.
2. Bump CPU, RAM, or disk for one container to show vertical scaling.
3. Add instances for an app to show horizontal scaling during load.
4. Push a second branch and repeat, proving the workflow is consistent across environments.
5. Open metrics and profiling to confirm that latency drops and error rates remain stable.

Application scaling 101: horizontal scaling and vertical scaling

Horizontal scaling involves running multiple instances of your app as the load increases. Vertical scaling refers to allocating a container more CPU and memory resources. Modern workloads require you to be able to do both easily and quickly.¹² While horizontal scaling is best for stateless applications, vertical scaling is preferred for services that require a data layer. Upsun supports both patterns with a single workflow, allowing your team to scale for bursts and right-size to a steady state.

The Upsun way: one solution for both

You can change resources interactively or run explicit flags. Read resource configuration.

Vertical scaling:

upsun resources:set --size frontend:0.25,api:0.5 --disk api:2048

• --size allows you to select a CPU amount. Each CPU amount is mapped to a RAM pairing via our container profiles based on runtimes.
• --disk allocates storage per container.
• The environment redeploys to apply changes. See the vertical scaling section.

Horizontal scaling:

upsun resources:set --count api:3

# or fan out across apps:

upsun resources:set --count '*:3'

• The router distributes requests across instances.
• The environment redeploys to apply the new count. See the horizontal scaling section.

Prefer to start tiny on previews and grow only when needed? Set a resource initialization strategy at branch or integration time. That way, every new environment begins at the right size automatically. Learn strategies.

Developer workflow, not platform detours

Upsun is Git-driven. You describe your app and services in a single config, push a branch, and Upsun builds and deploys a production-like environment automatically. Learn the workflow. Because environments clone code and data, your branch testing is realistic, and you can sanitize sensitive records right in the pipeline. See database sanitization guide.

When your stack mixes runtimes, container images, and shared mounts, Upsun maintains a consistent state across instances for safe horizontal scaling. For memory and CPU tuning, container profiles expose sensible CPU and RAM pairings by workload type. Review profiles.

Observability and APM built in

Tuning without telemetry is guesswork. Upsun integrates continuous profiling and application metrics, allowing you to validate that your scaling choice actually moves p95 latency, CPU saturation, and throughput in the right direction. See continuous profiling for PHP and other languages. Watch a short demo.

Step by step

1. Baseline: Run a quick load to obtain starting metrics. 

Vertical scaling:

upsun resources:set --size api:1 --disk api:4096

2. Redeploy applies the change. Confirm CPU headroom and memory pressure improve while latency falls.

Horizontal scaling:

upsun resources:set --count api:3

3. Hit the same test. Requests are distributed across instances. Confirm error rates stay low under burst.

4. Branch again: Create a new feature branch. It inherits resources based on your initialization rules. Rinse and repeat. 

5. Autoscaling option: If you prefer a hands-off approach, enable native autoscaling to adjust the instance count based on CPU, RAM, or request latency thresholds. See the autoscaling guide.

Why this helps your team

• Speed: Scale in minutes, not days. Your branch behaves like production, so fixes are accurate.
• Quality: Preview every change and run performance tests on environments that temporarily replicate production resources at a fraction of the cost.
• Consistency: One CLI for both vertical and horizontal scaling across all services.
• Reduced toil: No bespoke scripts or manual cluster surgery.
• Predictable cost: Start with minimal resources on branches, scale only where telemetry proves value. See pricing and cost monitoring in Console.

If you prefer a visual landing page before diving in, explore Upsun features. For more language-specific examples and tutorials, visit the Developer Center.

Try it yourself

Push your own code and see a full-stack environment scale in seconds.

Start a free trial. Connect your Git repo. Run upsun resources:set and let scaling be the least of your problems.

Sources

1. Kubernetes autoscaling concepts: horizontal vs vertical
2. Kubernetes HPA walkthrough, definitions, and behavior
3. Google Cloud framework, autoscaling to avoid overprovisioning 
4. AWS Well-Architected Generative AI Lens, autoscaling improves efficiency and cost
5. Kubernetes Vertical Pod Autoscaler, overview and operations