"Sovereign" has been a marketing word in hosting for years. It is in the process of becoming a defined one, and that is a problem for anyone who has been using it loosely.
The European Commission's proposed Cloud and AI Development Act would put structure behind the term. In the Commission's own words, it "defines cloud and AI sovereignty comprising four assurance levels, to be used by public sector bodies based on their risk assessments", with Member States recognising providers after an audit.
Three of those levels are worth reading carefully, because they are not the same claim:
- Level 1 — "where data is processed and stored in infrastructure located in the Union".
- Level 3 — "where providers must be owned and controlled from the EU and meet additional criteria, such as personnel citizenship".
- Level 4 — "where providers have full transparency and control over their software supply chain and no interference from a third country".
One important caveat, and we want to be the ones to say it: this is a proposal for a regulation, not law. The Commission's page carries it as exactly that. We have seen no primary source giving a date from which it would apply, so we are not going to give you one — if you have read a specific date somewhere, check whose page it was on.
Why a definition changes the conversation
Today, "sovereign hosting" can mean a data centre in the EU, or an EU-owned company, or a supply chain with no third-country dependencies. Those are wildly different promises, and a customer comparing two providers has no reliable way to tell which one they are being offered.
Once there are named levels, the question stops being "are you sovereign?" and becomes "which level, and who audited you?" That is a much harder question to answer with a landing page.
It is also worth being realistic about the market. The large cloud providers are not standing still on this, and if yours offers a sovereign option you should read what it actually covers against the levels above rather than against the word. The interesting differences will be in the detail, not the label.
What we can tell you about DeployBase, precisely
We are going to state a location fact, and then stop — because a location fact is what we can verify, and everything past it would be a guarantee we are not in a position to give.
Your hosted applications, databases, files and backups run in Helsinki, Finland, on bare metal from Hetzner Online GmbH. Not on a US hyperscaler.
We re-checked that this week rather than repeating it from memory. The production origin resolves to 65.21.225.252; reverse DNS returns a your-server.de host, IP geolocation places it in Helsinki on AS24940 Hetzner Online GmbH, and the RIPE registry's own record for the block gives country FI under netname DE-HETZNER-20010926. Three independent signals, all agreeing. You can run every one of those checks yourself in under a minute, and you should — for us and for whoever you use now.
What we are not claiming
This is the part most sovereignty pages leave out, so here it is in full.
- We are not claiming an assurance level. The framework is a proposal, no audit regime is operating under it yet, and we have not been audited. What we describe above resembles the shape of Level 1. That is a description, not a status, and we will not present it as one.
- We are not making a border-crossing guarantee about your data. That kind of promise is about mechanism and enforcement, not about where a server sits, and it would take considerably more than a location to make it honestly. Where the machine runs is what we have verified, so it is what we will say.
- We are not offering a compliance posture — not GDPR certification, not a legal opinion about any third country's reach. If your requirement is regulatory rather than practical, you need advice from someone qualified to give it, and a provider who tells you otherwise on a blog is selling you something.
The US services in our stack, listed
A provider that only tells you about its data centre is telling you about one layer. Here is ours, in full:
- Stripe — card payments.
- Google reCAPTCHA — abuse protection on our forms.
- Google Analytics 4, Meta Pixel and Microsoft Clarity — analytics on our marketing site.
- Namecheap — DNS.
- Cloudflare — DNS only, for one domain. Traffic is not proxied through it; requests go directly to Finland.
- Elastic Email — our outbound email relay.
None of these stores your hosted applications or your databases. They sit around the edges of the business — billing, forms, our own marketing analytics, mail delivery. But they are US services, they are part of the picture, and you should weigh them.
We would rather you saw that list from us than assembled it yourself from our page source.
What to actually ask a hosting provider
Whoever you are evaluating, including us:
- Where does the machine physically run? Ask for something checkable — an IP, a facility, an ASN. Then check it.
- Who owns and controls the company? Level 1 and Level 3 in the proposed framework are different questions, and most marketing collapses them.
- What is in the rest of the stack? Payments, DNS, analytics, mail. A sovereign server behind a stack of third-country services is a partial answer.
- Is any of this audited, by whom, and against what? Today, for nearly everyone, the honest answer is "not yet".
Where this leaves us
We did not build DeployBase as a response to a sovereignty trend. We put the servers in Finland because Hetzner's bare metal is the best price-to-performance we could find for what our customers run — Node.js, Laravel and PHP applications on plans from $5.99/month. The location happened to age well.
What we can offer is a specific, checkable claim about where your application runs, an explicit list of what else is involved, and no vocabulary we have not earned. When the definitions arrive, we would rather already be describing ourselves in terms that survive them.
You can see the plans at deploybase.io/pricing.