Regions & data residency
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. Pick Europe, the United States or Asia-Pacific, and every deploy lands on fleet capacity tagged for that region, with a global edge in front of it.
Two things sit behind every region: the worker fleet that runs your sites, and the control plane that manages them. Both are region-aware, and both are placed for the same reasons — the best price/performance we can secure in Europe and the US, coverage beyond those two markets, and a certified-underlying-platform option for buyers whose procurement demands one. Which region 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.
Our German capacity is the primary region and the best price/performance we run anywhere. New capacity lands here first, which is why it is the default for European customers and for anyone with no residency requirement of their own.
Finland gives European workloads a second, physically separate EU location. Useful when you want EU residency but do not want an entire portfolio sitting in one country's failure domain.
Our United States capacity spans Virginia in the east and Oregon in the west, covering both coasts. Same engine, same drivers, same panel — the only thing that changes is which region tag the placement engine will accept for your sites.
Asia-Pacific runs in Tokyo, Singapore and Seoul. This is the pattern the whole platform is built on: the capacity underneath a region is swappable infrastructure behind our engine, never the engine itself, and we run more than one supplier in the region so a site is never tied to any single one.
Where a contract demands GDPR-native EU infrastructure, or a buyer's procurement insists the underlying platform holds SOC 2, ISO 27001 or HIPAA attestations, we can place your workload on capacity that carries those certifications. Those are the underlying platform's certifications, not ours — we hold none of our own and will never imply otherwise.
Region is enforced in code, at the moment a site is created — not by an operator remembering which box to use.
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.
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.
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.
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.
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.
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.
Choosing a nearby region helps, but most of the latency your visitors feel is decided before a request ever reaches your origin.
Multi-region is worth very little if everything still shares one fate. The architecture separates the pieces that must not fail together.
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 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.
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.
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.
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.
In practice the decision comes down to four questions, and most customers answer them in under a minute.
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.
Europe in Germany and Finland; the United States in Virginia and Oregon; and Asia-Pacific in Tokyo, Singapore and Seoul. Europe is the primary region and the default where you express no preference. For strict EU residency, or where procurement requires a certified underlying platform, we can place on capacity that meets those requirements. The suppliers behind each region are our own commercial arrangement — you choose the region, not the vendor.
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.
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.
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.
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.
Per-site backups are immutable, offsite and air-gapped, 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.
Yes. The trial is 7 days, card-free, and starts in the default European region. 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.
Spin up a card-free 7-day trial in Europe, or tell us your residency requirement first and we will place you correctly from the first deploy.
Start free