Scalability, load balancing and failover: how your site survives traffic spikes

Failover: the backup plan every project already has

Every project on Devora Cloud, including on the Hobby plan, has a failover replica. It sits stopped on another server, ready to step in. If the primary instance fails, the failover replica starts and takes over. When the primary comes back, the failover replica is stopped again.

Because it is stopped during normal operation, this replica does not share traffic or add capacity. Its job is different: to shorten downtime when a server has a problem.

• Included in every plan at no extra cost.
• Lives on another server, not on the primary’s machine.
• Starts only when the primary fails and stops when it returns.

Load balancing: several copies sharing the traffic

On every plan you can add scaling replicas, billed by the hour. Each replica is a running copy of your application, the same size as your plan, and the load balancer spreads requests across the healthy copies. If one of them has a problem, the others keep serving.

All replicas use the project’s same database and the same S3. In other words, you gain processing capacity, not a new database.

• Hobby: up to 2 copies running at once.
• Pro: up to 3 copies running at once.
• Enterprise: up to 5 copies running at once.
• First extra replica: the plan’s full price, per hour.
• Load balancing: full hourly price for every copy; with autoscaling, 10% off from the next extra copy on.
• Billed per hour, only while the replica is running.

An example on the Pro plan (US$ 20 per month): the first replica costs the equivalent of US$ 17 if it runs the whole month, and each further replica US$ 15. If you run a replica only during a three-day campaign, you pay only for those hours.

Autoscaling: replicas that start when CPU climbs

Autoscaling is available on every plan and billed by the hour while the extra copies run. You set a CPU usage threshold; when the application goes above it, the platform starts another replica, up to the maximum your plan allows. When demand drops, the extra copies are no longer needed and are stopped.

It is the right choice for irregular traffic: you do not keep copies running overnight, and you do not have to rush to add capacity when the spike hits.

Failover, load balancing or autoscaling?

In practice the three add up: failover protects against a server going down, replicas give steady headroom and autoscaling covers the peaks.

What needs to change in your code

Replicas only work well when the application does not keep state on its own machine. Each request may land on a different copy, so:

• Store login sessions in Redis (or the database), not in process memory, so users stay signed in on any replica.
• Send user uploads to S3, never to the container disk. The disk is not shared between replicas.
• Coordinate scheduled jobs (cron, queues) so they do not run once per copy.
• Keep configuration in environment variables, identical for every replica.

PostgreSQL or Redis is included in every plan (Hobby 1 database, Pro 2, Enterprise 4), and each project’s private S3 is ready to receive files.

AMD EPYC servers: the size of each copy matters

Applications run on servers with AMD EPYC processors in the USA. Each replica has the same CPU and memory limits as the plan: adding replicas increases total capacity, but it does not make an individual copy more powerful.

So the usual order is: first make sure the code is efficient, then choose the plan with the right size per copy, and only then multiply the copies. If the app uses a lot of memory per request, moving up a plan helps more than adding small replicas.

For visitors in Brazil, Devora’s own CDN cache speeds up content delivery, but it does not run the application: processing stays on the US servers.

Frequently asked questions