Regions and availability
Available regions, data residency controls, and high availability architecture
npayload operates across six regions worldwide, giving you control over where your data lives and how it moves.
Available regions
| Region | Identifier | Location | Status |
|---|---|---|---|
| US East | us-east-1 | Virginia, USA | Generally available |
| US West | us-west-1 | Oregon, USA | Generally available |
| EU West | eu-west-1 | Ireland | Generally available |
| EU Central | eu-central-1 | Frankfurt, Germany | Generally available |
| AP Southeast | ap-southeast-1 | Singapore | Generally available |
| AP Northeast | ap-northeast-1 | Tokyo, Japan | Generally available |
Choosing a region
Select a region based on three factors:
- Latency: Choose the region closest to your users or services for the lowest round-trip time.
- Compliance: Regulations like GDPR may require data to remain within specific jurisdictions. EU West and EU Central keep data within the European Union.
- Data residency: Some organisations require data to stay in a specific country or region. npayload guarantees that messages remain in your selected region unless you opt in to cross-region messaging.
Region-specific endpoints
Each region has a dedicated API endpoint:
| Region | Endpoint |
|---|---|
| US East | https://us-east-1.api.npayload.com |
| US West | https://us-west-1.api.npayload.com |
| EU West | https://eu-west-1.api.npayload.com |
| EU Central | https://eu-central-1.api.npayload.com |
| AP Southeast | https://ap-southeast-1.api.npayload.com |
| AP Northeast | https://ap-northeast-1.api.npayload.com |
Configure your SDK to use the appropriate endpoint:
import { NPayload } from '@npayload/node';
const npayload = new NPayload({
clientId: process.env.NPAYLOAD_CLIENT_ID,
clientSecret: process.env.NPAYLOAD_CLIENT_SECRET,
region: 'eu-west-1',
});Data residency
By default, all messages, metadata, and audit logs remain in the region where your instance is deployed. npayload does not move data between regions unless you explicitly enable cross-region messaging.
This guarantee applies to:
- Message payloads and metadata
- Channel configuration
- Subscription state
- DLQ entries
- Audit logs
Cross-region messaging
npayload supports cross-region channels for use cases that require it, such as global event distribution or multi-region architectures. Cross-region messaging is always opt-in.
Cross-region messaging requires explicit data residency consent from your organisation. This consent is recorded in an immutable audit trail and can be revoked at any time.
To enable cross-region messaging:
- An organisation admin grants data residency consent in the dashboard
- Create a channel with cross-region replication enabled
- Select the target regions for replication
Consent is granular. You can allow replication between specific regions (for example, US East to US West) without opening all regions.
High availability
Each region is deployed across multiple availability zones for resilience:
- Automatic failover: If one availability zone becomes unavailable, traffic is routed to healthy zones with no manual intervention
- No single point of failure: Database, compute, and networking are distributed across zones
- Continuous health checks: Automated monitoring detects and responds to failures within seconds
- Target uptime: 99.99% for Enterprise tier, 99.9% for Pro tier
Latency expectations
Typical API response times measured from within the same region:
| Operation | p50 | p99 |
|---|---|---|
| Publish (single message) | 15 ms | 50 ms |
| Publish (batch, 100 messages) | 40 ms | 120 ms |
| Subscribe (webhook registration) | 20 ms | 60 ms |
| Query (channel metadata) | 10 ms | 30 ms |
Cross-region operations add the network round-trip between regions (typically 50 to 200 ms depending on distance).
Next steps
- Security for encryption, authentication, and network isolation
- Compliance for GDPR, SOC 2, and data protection details
- Limits and quotas for per-region resource limits
Was this page helpful?