Network & Datacenter
Where your apps actually run
Two US locations, chosen on purpose -- Detroit and Los Angeles -- with the big networks a fraction of a millisecond away on both coasts, and you pick which at checkout. Our own platform, measurements we took ourselves, and addresses you can test before you spend anything.
The network
Plain facts, stated once
Where the machines sit, what we run on them, and the numbers we measured ourselves. Nothing on this page is copied from a datacenter brochure.
Two US locations: Detroit and Los Angeles
Every Cloud App runs in one of two US facilities -- Detroit, Michigan or Los Angeles, California -- and you choose which at checkout. Two coasts, stated plainly, rather than a map of cities we keep no equipment in. Central for the middle and the east, coastal for the west.
The big networks are in the building
From Detroit, Cloudflare answers our pings in about a fifth of a millisecond; from Los Angeles, Google answers in about a third of one. On both coasts the networks your visitors ride are, for practical purposes, in the same room as the machines.
Our platform, not a reseller login
The panel, the API, the deployment recipes and the app catalog are ours, built and run by us. We lease server capacity the way nearly everyone in this industry does -- what you pay us for is everything that runs on it.
Your app and its database share a machine
A deployed stack keeps its app and its database on the same host, talking over a private network that never leaves the box. Queries take microseconds, not a round trip between buildings -- and that is measured, not estimated, on either coast.
IPv6 on every app, from day one
Every app gets a real public IPv6 address alongside IPv4, without asking and without an add-on -- in both locations. A surprising share of hosts still treat this as a paid feature; we treat it as table stakes.
Your address never moves
Apps are reached by hostname -- yours under our domain, or a domain you point at us. If we change hardware or providers underneath, your hostname and your custom domain keep working; DNS follows us, not the other way round. Hardware moves should be our problem, not yours.
Measured, not claimed
Latency from the machines your apps run on
Taken with ping from each app host itself, August 2026. Your own result will differ -- that is the point of publishing addresses you can test.
Detroit -> Cloudflare (1.1.1.1)
0.22 ms
they answer from inside the building, effectively
Detroit -> Google (8.8.8.8)
6.5 ms
public resolver, Chicago region
Los Angeles -> Google (8.8.8.8)
0.35 ms
they answer from inside the building, effectively
Los Angeles -> Cloudflare (1.1.1.1)
1.0 ms
public resolver, about a hop away
App -> its database
< 0.1 ms
same machine, private bridge -- either coast
Test it yourself
Addresses you can ping
Run ping, mtr or traceroute against these from wherever your users are. We would rather you measured than took our word for it.
Detroit app host
IPv4 -- ping, mtr or traceroute
66.163.115.158Detroit app host
IPv6, if you want to test v6 reachability specifically
2604:86c0:b001:2::2Los Angeles app host
IPv4 -- ping, mtr or traceroute
167.17.68.34Los Angeles app host
IPv6, if you want to test v6 reachability specifically
2604:86c0:2001:20::2These answer ICMP so you can measure latency and routing. For a throughput test, ask support and we will set one up rather than leave a permanent download target on a machine serving customers.
Questions
About the locations
Ready to deploy?
Deploy an app from the catalog in minutes. No contracts, no setup fees.