Chosen per site
Each hosting line offers its own set of data centres. You pick one when you create a site, and the order form only offers a city where that line has room today.
Regions & data residency
Your sites run where you say they run
Region is not a support ticket on this platform — it is a property of the site, honoured by the placement engine every time something is deployed. You choose the data centre when you create a site, from the cities its hosting line offers today, and every deploy lands on fleet capacity in that location, with a global edge in front of it. Each hosting page lists those cities, read live.
- 700,000+sites hosted worldwide
- You choosethe data centre for each site
- 99.99%uptime assurance
- 58panel languages
Where we run
Two things sit behind every location: the worker fleet that runs your sites, and the control plane that manages them. Both are region-aware. Which location you pick is yours to choose; the capacity underneath it is our own arrangement, and we deliberately run across more than one supplier so no single one is ever the platform.
Listed live
The cities on every hosting page and in the order form are read from the placement engine, so a new location appears the day it has capacity, and a full one is not offered.
How placement actually works
Region is enforced in code, at the moment a site is created — not by an operator remembering which box to use.
Every worker is tagged
Each host in the fleet registers itself with a region key, a product-line affinity list, a web-server type and a capacity figure, then pulls work. The placement service filters candidates on region first, then product line, then free capacity, and picks the least-loaded eligible host.
The site inherits and keeps the region
If you pinned a region, only workers in that region are eligible. If you did not, the site inherits the region of the worker it lands on and that value is stored on the site — so the record of where your data lives is a field you can read, not an assumption.
Capacity is claimed atomically
Placement claims capacity with a conditional update that only succeeds while the worker is still active, still accepting deploys and still under capacity. Two deploys racing for the last slot cannot both win, so a region is never quietly oversubscribed.
No silent fallback to the wrong region
If nothing eligible in your region has room, the deploy raises a placement error and stops. It does not fall back to another continent to make the request succeed. A visible failure and a capacity addition beats a site that silently moved country.
Drain instead of disruption
Every worker carries an accepts-deploys switch. Flipping it to drain stops new sites landing while existing sites keep running untouched, which is how we do maintenance, hardware refreshes and decommissioning inside a region without moving your workloads.
Residency as a product decision
Data residency is one of the few hosting decisions that is genuinely hard to reverse, so the platform treats it as a first-class dimension rather than a deployment detail. The customer's residency choice is an input to placement, the region is recorded against the site, and the fleet is tagged to match. That is what makes a residency answer auditable instead of anecdotal.
The tenancy model runs alongside it. Every record in the engine carries an organisation scope with PostgreSQL row-level security enforced at the database, and tenancy is hierarchical — a reseller organisation above client organisations above sites. Region answers where the data sits; row-level security answers who can reach it. Both matter to a compliance reviewer and neither is optional.
GDPR data export and erasure are part of the same design rather than a bolt-on process, and privileged and administrative actions are audit-logged. If your buyer's questionnaire asks where the data lives, who can query it and what happens when a subject asks for it back, those are answerable questions here.
A local origin is only half the speed story
Choosing a nearby region helps, but most of the latency your visitors feel is decided before a request ever reaches your origin.
- Cloudflare fronts everything — CDN, WAF, DNS and DDoS protection — so cacheable responses are served from the edge close to the visitor rather than from your origin region.
- LSCache runs on the worker itself as a server-level full-page cache with ESI and smart auto-purge, which means most WordPress requests never touch PHP or MySQL at all.
- A per-site Redis object cache takes the repeat database reads out of the requests that do reach the application.
- Purge is coordinated across both layers from one control in the panel, and from inside WordPress via the Zinn® cache plugin, so an edge copy and an origin copy never disagree after you publish.
- Footprint-Free customers layer CDN account pools on top: sites spread across our accounts and your own, with balance recomputed from live account state at deploy time.
- We publish no latency or throughput benchmarks, and we do not claim a given region will be fastest for your audience. Pick the region your visitors and your compliance position point at, and let the cache layers do the rest.
Failure domains, backups and honest boundaries
Multi-region is worth very little if everything still shares one fate. The architecture separates the pieces that must not fail together.
Control plane and fleet are separate
The engine, database, workflow layer and dashboards run on their own Kubernetes control plane, entirely apart from the worker fleet that serves customer sites. A control-plane incident must not take customer sites down, and a fleet incident must not take the platform down.
The public surfaces are independent too
The customer dashboard, the admin console and this marketing site are deployed on Cloudflare independently of the control-plane cluster, so a platform incident does not also remove the place you would go to read about it.
Status lives off-platform
The status page is deliberately hosted with a different provider in a different region. A status page running on the infrastructure it monitors is useless at precisely the moment you need it.
Immutable, offsite, isolated backups
Per-site backups are immutable and offsite, written to object storage, with restores tested rather than assumed. Restores are one-click from the panel alongside the file manager, domains, DNS, SSL and logs.
What we do not claim
We do not assert a service-level agreement, a response time or a latency figure on this page — SLA terms are agreed per contract. The 99.99% figure attached to Footprint-Free plans is an uptime assurance, a target we build to, not a measured historical availability record.
Picking a region
In practice the decision comes down to four questions, and most customers answer them in under a minute.
- Do you have a contractual or regulatory residency requirement? If yes, that decides it — EU customers with GDPR obligations choose a data centre inside the European Union, and we have a GDPR-native EU route when a contract demands one specifically.
- Where is the audience you actually monetise? Choose the data centre closest to it from the cities the order form offers.
- Does your buyer's procurement require a certified underlying platform? If a SOC 2 or ISO 27001 attestation on the infrastructure beneath your sites is a hard gate, tell us before you build and we will place on capacity that holds one.
- Do you want your portfolio split across failure domains? Placing sites in more than one data centre removes single-location concentration.
- Unsure? Start on the card-free trial. Nothing about the panel, the drivers or the feature set changes when you later deploy elsewhere.
FAQ
Can I choose which region my sites are deployed to?
Yes. Region is an input to the placement engine, not a request handled out of band. Pin a region and only fleet workers tagged for that region are eligible to receive the site; the chosen region is then stored on the site record so you can always read back where it runs. Leave it unset and the site inherits the region of the worker it lands on.
Which regions do you run in?
It depends on the hosting line, because each line runs on the capacity built for it. The order form and each hosting page list the cities you can choose today, read live from the placement engine, so this answer never goes out of date. For strict EU residency, choose a data centre inside the European Union; where procurement requires a certified underlying platform, we can place on capacity that meets those requirements. The suppliers behind each location are our own commercial arrangement — you choose the location, not the vendor.
Do you hold SOC 2 or ISO 27001?
No — Zinn Digital® holds no compliance certifications of its own today, and we will not imply otherwise. What we can do is place your workload on an underlying platform that holds them, where a buyer's procurement makes a certified platform beneath your sites a hard requirement. Separately, the platform's own controls are real and inspectable: per-site isolation, row-level security on every tenant-scoped table, secrets held in Vault, TLS throughout, and audit logging of privileged actions.
What happens if the region I want has no capacity?
The deploy fails visibly with a placement error rather than silently landing your site somewhere else. That is deliberate: a site that quietly moved jurisdiction is a far worse outcome than a deploy that stopped and told you why. Capacity is added by bringing more hosts online in that region, where they register themselves and immediately start accepting work.
Will my site be slow for visitors far from its data centre?
We do not publish latency benchmarks and will not promise a specific figure. What we can describe is the architecture: Cloudflare fronts every site so cacheable responses are served from an edge location near the visitor, LSCache serves full pages from the worker without touching PHP or the database, and a per-site Redis object cache absorbs repeat queries. For most content sites that combination means the origin region matters far less than the cache configuration. If your audience is concentrated in one continent, place the origin there anyway.
Can I move an existing site to a different region later?
Region is set when a site is placed and stored on the site record, so a change of region is a migration rather than a toggle. Talk to us before you build if you already know a move is coming — it is much cheaper to place correctly the first time than to relocate a live portfolio.
Where are my backups kept?
Per-site backups are immutable, offsite and isolated from the running fleet, written to object storage with restores tested rather than assumed, and restorable in one click from the panel. If your compliance position requires backup storage to sit in a specific jurisdiction, raise it with us directly — that is a contractual detail we agree per customer rather than a blanket claim we make on a web page.
Can I try it without committing to a region?
Yes. The trial is 14 days and card-free. It covers Footprint-Free Hosting with up to five sites, which is enough to see how deploys, placement and the cache layers behave before you decide where your production portfolio should live.
Related
Start where it makes sense, move when it matters
Spin up a card-free 14-day trial, or tell us your residency requirement first and we will place you correctly from the first deploy.
Start free