Regions and latency

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.

Recommended latency thresholds

Latency	Experience	Recommendation
< 70ms	Excellent!	Ideal for all development tasks
< 120ms	Good	Suitable for most development work
< 200ms	Ok	Users may notice some latency in IDE and terminal
> 200ms	Poor	Not recommended

Test latency before deploying

• CloudPing
• AWS Latency Test
• ping or httping from command line

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.