Skip to main content
Low network latency between dev environments and local machines ensures responsive IDE and terminal performance. Region choice affects more than speed. It also influences data residency, user experience, and how well one runner can serve a distributed team.

​
How to choose a region

Start with where your developers actually work, not just where your company is incorporated. For most teams, the best region is the one that minimizes round-trip latency for the majority of users. If your team is spread across multiple continents, consider multiple runners instead of forcing everyone through one distant region.

​
Test latency before deploying

Test from where your users work. VPN affects results. Test with VPN if users connect through VPN.

​
Practical guidance

  • Prefer the closest region that also satisfies your compliance requirements.
  • Test latency from actual developer locations before deployment.
  • Re-test after VPN, proxy, or network policy changes.
  • If one region is good for Europe but poor for North America, add another runner instead of accepting a globally slow default.

​
Supported regions

​
North America

  • us-east-1 (N. Virginia)
  • us-east-2 (Ohio)
  • us-west-1 (N. California)
  • us-west-2 (Oregon)
  • ca-central-1 (Canada Central)

​
Europe

  • eu-west-1 (Ireland)
  • eu-west-2 (London)
  • eu-west-3 (Paris)
  • eu-central-1 (Frankfurt)
  • il-central-1 (Israel Central)

​
Asia Pacific

  • ap-south-1 (Mumbai)
  • ap-southeast-1 (Singapore)
  • ap-southeast-2 (Sydney)
  • ap-northeast-1 (Tokyo)

​
South America

  • sa-east-1 (São Paulo)
Need a different region? Contact support.