Network ceiling
Measure real sustained ingress and egress from the VPS region. The advertised port speed is not a guarantee of international throughput at peak time.
The variables that matter
Count active traffic, not rows in a database
CPU and packet rate
Encryption, userspace proxy protocols, packet size, NAT, firewall rules, and traffic accounting affect CPU differently. Watch per-core saturation, not only total CPU.
Concurrency and behavior
Streaming, downloads, video calls, background messaging, idle mobile tunnels, and speed tests create different peaks even at the same customer count.
A simple first estimate
Convert the customer model into a peak load
Step 1Estimate the number of customers online in the busiest hour, using your own analytics as soon as they exist
Step 2Measure average and upper-percentile throughput per online customer for the market you serve
Step 3Multiply concurrent customers by expected throughput, then compare both directions with measured node capacity
Step 4Reserve headroom for bursts, updates, monitoring, routing changes, and a node failure that shifts customers elsewhere
Example: 250 concurrent customers averaging 2 Mbps require roughly 500 Mbps before burst and failover margin. This arithmetic is only a starting point. Packet rate, CPU, protocol, route quality, and the distribution of heavy users still need load testing.
Test like an operator
Measure the failure boundary before customers find it
Test the actual region
Run sustained tests to destinations representative of the customer base. A benchmark between two servers in the same data center says little about the path customers use.
Test the actual protocol
WireGuard, AmneziaWG, Hysteria2, TUIC, and VLESS-Reality do not have identical CPU, transport, or client behavior. Benchmark the configuration you will sell.
Test normal and degraded states
Observe service during a node restart, a full disk, packet loss, DNS failure, a saturated port, and migration of customers to another location.
Set an operating threshold
Add or split capacity before the theoretical maximum. A service that remains responsive during bursts is more valuable than one that advertises the largest number.
Signals to watch
Capacity problems rarely announce themselves with one metric
- network throughput and packet drops in both directions
- per-core CPU, load, memory pressure, and interface errors
- handshake recency, connected devices, and customer complaints by location
- DNS latency and failure rate for the resolver path offered to customers
- provider transfer quota, fair-use policy, and unexpected throttling
- growth in peak concurrent users rather than total registered accounts
Scale upWhen a larger node is operationally simpler and the location still meets latency goals
Scale outWhen geography, failure isolation, route quality, or customer choice matters more than one larger server
RebalanceWhen one location is overloaded while another is underused
RetireWhen a provider repeatedly fails route, support, abuse, or reliability requirements
Common questions
Capacity decisions in practice
Can Flirexa guarantee a customer count per VPS size?
No responsible platform can guarantee that without the protocol, traffic mix, region, provider, CPU generation, port behavior, and concurrency. Flirexa exposes the operating data; capacity must be measured in the intended environment.
Should the control panel and VPN traffic share a server?
The FREE tier and small deployments can start locally. As the business grows, separating control functions from traffic nodes improves failure isolation and lets locations scale independently.
When should I add a second region?
When measured demand, latency, route quality, resilience, or a market requirement justifies it. A region added only for a larger map becomes another system to patch and monitor.