Scaling
On Zenifra, scaling happens through manual instance adjustment, HTTP autoscaling, and plan changes.
Horizontal Scaling
You can increase the number of project instances to distribute load and improve redundancy.
- the adjustment is done manually in the console
- multiple HTTP instances receive load balancing from the platform
- by default, HTTP projects accept up to 10 instances; for more, contact support
HTTP Autoscaling
For paid HTTP plans with the feature enabled, you can define:
- reserved minimum instances
- maximum instances allowed during spikes
- CPU and memory targets for automatic scaling
While autoscaling is enabled, manual instance changes are blocked to avoid conflicts between the fixed value and automatic scaling.
For hourly billing, Zenifra charges observed instances during the period. For monthly or yearly plans, the reserved minimum is part of the contract and instances above the minimum are billed as elastic instance-hours.
Each scale up or scale down is available in the console autoscaling history and API, including timestamp, previous and new instance counts, CPU/memory thresholds, and reason.
Vertical Scaling
Vertical scaling happens through plan change.
- CPU changes according to the plan
- memory changes according to the plan
- storage follows the supported growth rules of the project mode
Practical Strategies
- use more instances when the application needs more horizontal capacity
- use HTTP autoscaling when traffic has hard-to-predict spikes
- change the plan when the bottleneck is CPU or memory
- monitor logs and metrics per instance to identify real bottlenecks