Regions

Available Regions

Select a Region

On project creation:

rf projects create my-app --region eu-west-1

Or in raidframe.yaml:

project: my-app
region: eu-west-1

Multi-Region Deployment

Deploy to multiple regions for lower latency and higher availability:

rf regions add us-west-1
rf regions add ap-southeast-1

✓ Region added: us-west-1 (Oregon)
✓ Region added: ap-southeast-1 (Singapore)

Your app now runs in 3 regions:
  us-east-1 (primary)
  us-west-1
  ap-southeast-1

Traffic is routed to the nearest healthy region automatically.

Configuration

project: my-app
regions:
  primary: us-east-1
  replicas:
    - us-west-1
    - eu-west-1
    - ap-southeast-1

databases:
  main:
    engine: postgres
    region: us-east-1
    read_replicas:
      - region: us-west-1
      - region: eu-west-1
      - region: ap-southeast-1

Automatic Failover

If a region becomes unhealthy, traffic is automatically rerouted to the next nearest healthy region. No manual intervention needed.

rf regions status

REGIONS
───────
us-east-1 (primary)    ✓ healthy    2 instances    12ms avg
us-west-1              ✓ healthy    2 instances    45ms avg
eu-west-1              ✓ healthy    2 instances    89ms avg
ap-southeast-1         ✓ healthy    1 instance     120ms avg

Data Residency

For compliance, restrict data to specific regions:

databases:
  main:
    region: eu-west-1
    data_residency: EU          # Data never leaves EU regions
    read_replicas:
      - region: eu-central-1    # Only EU replicas allowed
      - region: eu-north-1

rf compliance data-residency --region EU

Region-Specific Scaling

Scale differently per region:

services:
  api:
    scaling:
      us-east-1:
        min: 4
        max: 20
      eu-west-1:
        min: 2
        max: 10
      ap-southeast-1:
        min: 1
        max: 5

Latency-Based Routing

Traffic is routed to the nearest region by default using anycast DNS. Response times: