Load balancing and failover
Run an app in EU Central and EU West at once, move visitors when health checks fail, or split traffic between both.
How it works
Load balancing runs a second copy of your app in the other region, so an application in EU Central (Frankfurt) also runs in EU West, and the other way round. Visitors still arrive through the Rimbra edge in Frankfurt, which health-checks both copies and decides where each request goes.
It is part of the Pro and Scale plans and works for apps with a server (Next.js, Node, Python, PHP, Go, Rust, Ruby, Java, .NET, Deno and containers). Static sites are already served from the edge.
Turn it on
- Open your application and go to the Load balancing tab.
- In Load balancing, turn on Run in both regions.
- Choose Failover or Spread, and which region is primary.
- Adjust the health check if your app has a health route, for example /health.
Failover and Spread
- Failover: every visitor goes to the primary region. When its copy fails the health check the set number of times in a row, traffic moves to the other region. It moves back once the primary passes the healthy threshold again.
- Spread: new visitors are split between both copies, 50/50, 70/30 or 90/10. If a copy fails its checks, everyone goes to the healthy one until it recovers.
- Keep visitors on one copy (Spread): a cookie remembers the region a visitor started on, so sessions kept in memory survive. A visitor only moves when their copy fails.
- Each response carries an X-Rimbra-Region header (eu-central or eu-west) so you can see which copy answered.
Health checks
Thresholds count checks in a row, so a single slow answer never moves traffic. A copy that has never been checked never gets traffic in its place, and the primary keeps its traffic until checks say it is down, so turning load balancing on never takes a working site offline.
The Load balancing tab shows each copy's health, response time and when it was last checked, plus a history of every switch.
| Setting | Default | Range |
|---|---|---|
| Path | / | Any path on your app |
| Every | 10 seconds | 5 to 300 seconds |
| Timeout | 3 seconds | 1 to 30 seconds, shorter than the interval |
| Healthy after | 2 checks in a row | 1 to 10 |
| Down after | 3 checks in a row | 1 to 10 |
| Expected status | Any 2xx or 3xx | One exact status, like 200 |
Alerts
When traffic moves, and when it moves back, the application owner gets an email. If the application has Slack or Discord alerts connected, the same message is posted there.
Data, sessions and limits
- Databases stay in EU Central. The copy in EU West reaches them over Rimbra's private link, which adds a few milliseconds to each query.
- Environment variables and secrets are the same for both copies.
- The second copy is built from the same commit after every production deploy. Until it is ready it takes no traffic, and the card shows it as not running yet.
- Second copies need an application connected to GitHub, GitLab or Bitbucket. Docker apps and uploaded folders can't have one yet.
- If a page request can't reach the copy it was sent to, it is tried once on the other healthy copy. Only GET and HEAD requests are retried.
- Files your app writes to its own disk (uploads, SQLite, caches) are not shared between copies. Keep them in a database or object storage.
- Sessions kept in memory are not shared either. Store sessions in a database or Redis, or turn on Keep visitors on one copy.
- Background work that must run once (cron jobs, queue workers started by the app itself) runs in both copies. Use Rimbra cron jobs for anything that must run exactly once.