Skip to main content

Documentation Index

Fetch the complete documentation index at: https://ona.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

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.
LatencyExperienceRecommendation
< 70msExcellent!Ideal for all development tasks
< 120msGoodSuitable for most development work
< 200msOkUsers may notice some latency in IDE and terminal
> 200msPoorNot recommended

​
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.