---
title: "Global Locations"
description: "Custom ERP and B2B software engineering delivered remotely across 40 global tech hubs — one senior team, SOC 2-ready process, full IP ownership wherever you operate."
canonical: https://erpstack.io/locations
markdown_url: https://erpstack.io/locations.md
publisher: ERPStack
---

# Global Locations

> **In short:** ERPStack is remote-first — there is no ERPStack office in any of these 40 locations. What a location page carries is the part that is genuinely local: the AWS or Microsoft Azure region your data has to sit in, the invoice format your tax authority accepts, and the regulator who will ask for evidence. One senior team builds the system, on Next.js, TypeScript and PostgreSQL in AWS or Microsoft Azure, and you own the source code.

## How ERPStack delivers in every location

### Residency decides the region before latency does

Every build starts with a region, not a city. Where a rule pins the data, the region is settled first: RBI's payment-data circular keeps a Mumbai ledger in ap-south-1, ITAR technical data keeps a Seattle aerospace build in us-west-2, Swiss banking secrecy keeps Zurich in eu-central-2. Only when nothing pins it do we optimise for distance, taking the nearest AWS or Microsoft Azure region — or an AWS Local Zone — with a paired recovery region. Both choices live in Terraform, so the region a locations page names is the region the pipeline deploys.

### Latency figures are design targets, not SLAs

Numbers on these pages are engineering targets we load-test toward unless the page says they were measured: under 5 ms in-metro for Mumbai on ap-south-1, about 2 ms across Sydney on ap-southeast-2, about 3 ms across Melbourne on ap-southeast-4, under 2 ms in Frankfurt on eu-central-1, about 4 ms across Dallas on Google Cloud us-south1, about 7 ms in Dublin on eu-west-1, and a measured 49 ms from Tel Aviv on il-central-1 to Milan. An ERP is not a colocated trading system, and we say so on the pages where that distinction matters.

### The stack is identical everywhere

Engineering does not change with the postcode. Every build is Next.js and TypeScript on Vercel or AWS, over a PostgreSQL primary behind Drizzle ORM, with RBAC, SSO, JWT sessions, an Immutable Audit Trail, Sentry instrumentation and Terraform in GitHub Actions, so the whole stack rebuilds from the repository. SOC 2 and ISO 27001 evidence is generated from the schema rather than assembled by hand before an audit. There is no per-seat licence, no vendor lock-in, and you keep the source code. ERPStack holds no certification of its own; it builds systems that pass yours.

### What actually changes between locations

Three things: residency, invoicing and evidence. Invoicing decides the output format — XRechnung in Berlin, Factur-X in Paris from 1 September 2026, Peppol in Singapore, Amsterdam and Stockholm, Brazil NF-e for a Miami parent. Evidence decides the export — an FCA reviewer in London, the RBI in Mumbai, APRA in Sydney and the HKMA in Hong Kong each want a different report out of the same PostgreSQL ledger. Residency decides the region, and 15 of these 40 locations have an AWS Region of their own.

## Locations

| Location | Market served | Cloud region |
| --- | --- | --- |
| [London](https://erpstack.io/locations/london) | UK & Europe | eu-west-2 (London), 3 AZs |
| [New York](https://erpstack.io/locations/new-york) | North America | us-east-1 (N. Virginia), 6 AZs + us-east-1-nyc-2a |
| [San Francisco](https://erpstack.io/locations/san-francisco) | North America | us-west-1 (N. California), 3 AZs |
| [Austin](https://erpstack.io/locations/austin) | Texas & U.S. South | Azure southcentralus (Texas) |
| [Boston](https://erpstack.io/locations/boston) | North America | us-east-1 + AWS Local Zone us-east-1-bos-1a (Boston) |
| [Chicago](https://erpstack.io/locations/chicago) | North America | us-east-2 (Ohio) + Local Zone us-east-1-chi-2a (Chicago) |
| [Seattle](https://erpstack.io/locations/seattle) | Pacific Northwest | us-west-2-sea-1a (Seattle Local Zone) |
| [Toronto](https://erpstack.io/locations/toronto) | North America | ca-central-1 (Montreal) / canadacentral (Toronto) |
| [Berlin](https://erpstack.io/locations/berlin) | UK & Europe | eu-central-1 (Frankfurt), 3 AZs |
| [Singapore](https://erpstack.io/locations/singapore) | Southeast Asia | ap-southeast-1 (Singapore) — 3 AZs, no opt-in |
| [Dubai](https://erpstack.io/locations/dubai) | Middle East | me-central-1 (Dubai, UAE) |
| [Sydney](https://erpstack.io/locations/sydney) | Australia & New Zealand | ap-southeast-2 (Sydney) |
| [Mumbai](https://erpstack.io/locations/mumbai) | India & South Asia | ap-south-1 (Mumbai), 3 AZs |
| [Bangalore](https://erpstack.io/locations/bangalore) | India & South Asia | ap-south-1 (Mumbai), 3 AZs |
| [Amsterdam](https://erpstack.io/locations/amsterdam) | UK & Europe | Microsoft Azure West Europe (Netherlands) |
| [Paris](https://erpstack.io/locations/paris) | UK & Europe | AWS eu-west-3 (Paris), 3 Availability Zones |
| [Tel Aviv](https://erpstack.io/locations/tel-aviv) | Israel & the Middle East | il-central-1 (Tel Aviv) |
| [Tokyo](https://erpstack.io/locations/tokyo) | Asia Pacific | ap-northeast-1 (Tokyo), 4 AZs |
| [Hyderabad](https://erpstack.io/locations/hyderabad) | India & South Asia | ap-south-2 (Hyderabad), 3 AZs — opt-in |
| [Chennai](https://erpstack.io/locations/chennai) | India & South Asia | ap-south-1 (Mumbai) or Azure South India (Chennai) |
| [Pune](https://erpstack.io/locations/pune) | Maharashtra, India | Microsoft Azure Central India (Pune) |
| [Melbourne](https://erpstack.io/locations/melbourne) | Australia & New Zealand | ap-southeast-4 (Melbourne) |
| [Frankfurt](https://erpstack.io/locations/frankfurt) | Europe | eu-central-1 (Frankfurt), 3 AZs |
| [Dublin](https://erpstack.io/locations/dublin) | UK & Europe | AWS eu-west-1 (Ireland), 3 Availability Zones |
| [Zurich](https://erpstack.io/locations/zurich) | Europe | eu-central-2 (Zurich), 3 AZs, opt-in |
| [Hong Kong](https://erpstack.io/locations/hong-kong) | Greater China | ap-east-1 (Hong Kong) — opt-in region, 3 AZs |
| [Seoul](https://erpstack.io/locations/seoul) | Asia Pacific | ap-northeast-2 (Seoul), 4 AZs |
| [Los Angeles](https://erpstack.io/locations/los-angeles) | North America | us-west-2-lax-1a / lax-1b (Los Angeles) |
| [San Jose](https://erpstack.io/locations/san-jose) | North America | us-west-1 (N. California, 3 AZs) |
| [Stockholm](https://erpstack.io/locations/stockholm) | Sweden & the Nordics | eu-north-1 (Stockholm) |
| [Dallas](https://erpstack.io/locations/dallas) | Texas & U.S. South | us-south1 (Dallas, Texas) |
| [Miami](https://erpstack.io/locations/miami) | North America | us-east-1-mia-2a (Miami Local Zone) |
| [Denver](https://erpstack.io/locations/denver) | Front Range & Colorado Plateau | us-west-2-den-1a (Denver Local Zone) |
| [Atlanta](https://erpstack.io/locations/atlanta) | North America | us-east-1-atl-2a (Atlanta Local Zone) |
| [Phoenix](https://erpstack.io/locations/phoenix) | North America | us-west-2-phx-2a (Phoenix Local Zone) |
| [Portland](https://erpstack.io/locations/portland) | Silicon Forest & Willamette Valley | us-west-2 (Oregon, in-state) |
| [Minneapolis](https://erpstack.io/locations/minneapolis) | North America | us-east-2 (Ohio) + Local Zone us-east-1-msp-1a (Minneapolis) |
| [Raleigh](https://erpstack.io/locations/raleigh) | North America | AWS us-east-1 (N. Virginia) — no Local Zone in North Carolina |
| [Charlotte](https://erpstack.io/locations/charlotte) | North America | us-east-1 (N. Virginia) |
| [Houston](https://erpstack.io/locations/houston) | Texas & U.S. South | us-east-1-iah-1a (Houston Local Zone) |

## Frequently asked questions

### Does ERPStack have an office in these locations?

No. ERPStack is remote-first and holds no office, legal entity or staff in any of the 40 locations listed on this page. What is local is the deployment: the system runs in the AWS or Microsoft Azure region your regulator expects — ap-south-1 for Mumbai, eu-west-2 for London, ap-southeast-2 for Sydney — and the contract, the invoicing format and the audit exports are built for that jurisdiction. One senior team delivers across every location, inside your working hours, on the same Next.js and PostgreSQL stack.

### Which of these locations have an AWS Region of their own?

Fifteen of these 40 locations do, and each page names the code: Mumbai (ap-south-1), Hyderabad (ap-south-2), Sydney (ap-southeast-2), Melbourne (ap-southeast-4), Tokyo (ap-northeast-1), Seoul (ap-northeast-2), Hong Kong (ap-east-1), Tel Aviv (il-central-1), Dubai (me-central-1), Zurich (eu-central-2), Stockholm (eu-north-1), Paris (eu-west-3), London (eu-west-2), Frankfurt (eu-central-1) and Singapore (ap-southeast-1). Boston, Chicago, Atlanta, Denver, Houston, Miami, Minneapolis, Phoenix, Portland, Los Angeles and Seattle are instead served by an AWS Local Zone hanging off a parent region.

### How do you choose the cloud region for a build?

Residency rules first, latency second. Where a rule pins the data the region is settled before anything else: RBI's payment-data circular keeps a Mumbai ledger in ap-south-1, ITAR technical data keeps a Seattle aerospace build in us-west-2, Swiss banking secrecy keeps Zurich in eu-central-2. Where nothing pins it we take the nearest AWS or Microsoft Azure region, or an AWS Local Zone, with a paired recovery region. Both choices live in Terraform, so the region a locations page names is the region the pipeline actually deploys.

### How do you price work across 40 locations?

The same way everywhere: fixed-scope milestones against a written specification, with no per-seat licence and no charge for extra users, partner portals or environments. Currency, tax treatment and contracting entity change by jurisdiction; the engineering rate card does not. Because ERPStack keeps no office in these locations, no local overhead is priced into the quote — the cost sits in senior engineering hours plus the AWS or Microsoft Azure bill, which you own directly rather than paying us to resell.

### Do you work in our time zone?

Within reason. ERPStack works remotely across all 40 locations and fixes an overlap window with your team rather than promising 24-hour coverage it cannot staff. European and Middle Eastern locations get a full working-day overlap, Indian and South-East Asian locations most of one, North American locations the morning. Delivery is asynchronous by default — written specifications, pull requests through GitHub Actions, recorded demos — so progress never depends on one call being taken.