Where a service runs determines which laws apply to the data it processes, which customers can use it under what terms, and how much latency every request experiences. This page is the current, honest account of where Neuraphic operates.
Current regions
United States. Our primary production region. All application servers, databases, and customer account data are hosted in the United States. This is where every customer is served today.
Global edge. Static content and request routing are handled from edge locations worldwide for low-latency delivery. Customer data is not stored at the edge.
Expansion
European Union. A European production region is in active deployment. We are targeting availability in the second half of 2026. The EU region will be a full production environment: customer data will remain in the EU, and the same operational controls will apply from day one.
Asia-Pacific. In planning. We have not committed to a timeline and will do so only when we can deliver on the same standards we apply to our existing regions.
Data residency
When a customer selects a region, their application data remains in that region. We do not replicate customer content across regions without consent. Backups for disaster recovery are stored within the same jurisdictional region as the primary data.
There are three narrow exceptions, each documented. Aggregated, non-identifying operational telemetry may be processed outside the customer's region to maintain service reliability. Security incidents may require cross-region investigation under the terms of the Data Processing Addendum. Customers who explicitly enable cross-region replication will have data replicated to the region they select.
Compliance by region
European Union. Personal data is processed in alignment with the GDPR. Standard contractual clauses are included in the Data Processing Addendum for any transfers that remain necessary.
California. Californian residents are covered under the CCPA regardless of which region they are served from. We honor access, correction, and deletion requests within the timeframes defined by the law. Requests can be sent to [email protected].
Other jurisdictions. Customers with specific regulatory requirements should contact [email protected].
Service availability
Where a service runs is one half of availability. The other half is the uptime, latency, and error-budget commitment we make for each product. We separate these commitments by product because the failure modes are different: an Apps deployment can tolerate retries, a Praeth decision sits on the request path of every authenticated call, and an account-management interruption blocks operators from recovering from either.
Apps. The Apps control plane and the shared runtime are operated to a monthly uptime target defined in your contract. Scheduled maintenance windows are announced in advance and excluded from the calculation. When the target is missed, service credits are calculated against the affected billing period and applied per the SLA appendix in your agreement. Postmortems for any incident that consumes more than a defined fraction of the monthly error budget are published.
Praeth. Praeth is operated as an inline scoring service with single-digit-millisecond decision budgets at the ninety-ninth percentile and an availability target measured per region. Because Praeth sits on the request path, the system is designed so that the loss of any individual signal degrades the quality of the decision but never blocks legitimate traffic, and so that Praeth can be cleanly removed from the request path without coordination if a regression is discovered. The contractual uptime target, latency objectives, and credit schedule are documented in your SLA appendix.
CLI and Console. The web console and the back-end services that the command-line interface depends on are operated to the same monthly uptime target as the Apps control plane. Outages here block administrative operations but do not, by design, halt running workloads.
Claeth and Prion. While in limited access, Claeth and Prion are operated on a best-efforts basis with no contractual SLA. Customers who require a contractual commitment for these products should engage with [email protected]; we will discuss eligibility for an early-adopter program with defined commitments where appropriate.
Identity and accounts. Sign-in, two-factor authentication, passkey ceremonies, and session management are treated as a tier above the products that depend on them. The identity tier carries the strictest internal availability target we operate against, because a customer who cannot sign in cannot recover from any other incident.
Exclusions. Scheduled maintenance announced in advance through the status page, force majeure events, customer-initiated outages, abuse mitigation that affects only the abusing tenant, and degradations attributable to providers of internet transit between you and us are excluded from the SLA calculation. The full exclusion list and credit schedule are part of your contract.
Changes
When a new region becomes available, when an existing region changes status, or when our data residency or service availability commitments change, we notify customers by email and publish the change here and on the Trust Center.