Managed hosting, hardened and operated inside the EU.

The distinction is not pedantry; it decides who can read your data. Residency answers where the bytes sit, and hosting them in the EU is enough to bring GDPR to bear. Sovereignty goes further, asking which legal system governs the data and the company holding it. Jurisdictional control is the sharp end: who can lawfully compel access. A US-headquartered provider with a datacentre in Frankfurt satisfies residency and still fails the third test, because the US CLOUD Act lets American authorities demand the data without notifying you, wherever the servers physically stand.

This is why the residency badge on a US hyperscaler's EU region is not the reassurance it looks like. Around 70% of the European cloud market still runs on US-owned platforms, and for any of them the foreign parent is the entity a foreign court can order. Storing European personal data there also draws you into the Schrems II world of transfer impact assessments and standard contractual clauses, a compliance burden you take on because of where you put the data rather than anything you did wrong. The cleanest way out of that burden is to keep the data with a provider the foreign law does not reach.

We are that provider. Argus Root is operated inside the EU with no foreign parent in the ownership chain, so there is no company a US or other foreign court can compel to hand over what we hold. That removes the CLOUD Act and FISA 702 exposure rather than papering over it with contractual clauses, and it answers the supply-chain question NIS2 now asks, which reaches your hosting provider and its subcontractors. Where your data lives, which law governs it, and who can reach it all have the same answer, and the answer is European.

We operate our own AlmaLinux fleet and our own /22 IP block, and we harden every server with the same installers we run on our own brands. The reputation of the IPs your traffic and mail ride on is one we manage and answer for, rather than one you inherit from a shared pool you never chose.

# hardened before a single site goes live
$ ssh-audit host.eu              # no weak ciphers, key-only login
$ nft list ruleset               # default-deny firewall
$ systemctl enable --now fail2ban   # brute-force shield
$ certbot renew --quiet          # TLS auto-renewed
$ dnf-automatic --security       # security patches applied nightly

# uptime is an architecture, not a number on a page
$ keepalived -t                  # VIP fails over between nodes
$ curl -sf https://site.eu/health || page_oncall   # synthetic monitor

Hosting comes in two shapes that are easy to confuse on a price list. Unmanaged hosting hands you a server and a login; everything above the bare metal, the operating system, the patching, the security, the backups, the moment it breaks at 3am, is yours. It is cheaper on the invoice and far more expensive in the hours and the risk it quietly transfers to you. Managed hosting keeps all of that with the provider, so what you rent is a working, maintained, watched system rather than a box you now have to administer.

The line matters because most outages and breaches happen in the layer unmanaged hosting leaves to the customer: an unpatched package, a default left open, a backup that was never tested. Under management those are our job, done on a discipline rather than when someone remembers. You keep your sites, your data and your decisions; we keep the infrastructure beneath them healthy, so the question stops being whether anyone on your team has time to be a part-time sysadmin. The saving on an unmanaged plan is real only until the first incident it leaves you to handle alone.

Most teams that come to us already know cPanel and WHM, and we run them fully managed rather than ask anyone to relearn how they work. You get the familiar interface for the day-to-day, mail, domains, databases, without running the server underneath it, which is the part that genuinely takes expertise and time. The convenience of the panel sits on infrastructure we keep patched, hardened and watched.

A control panel is also a dependency worth being clear-eyed about, since licensing and lock-in are real costs. We are honest about where the panel ends and the server begins, and we manage the licensing rather than surprise you with it. Where a workload is better served without a panel at all, a plain hardened server we administer directly, we will say so rather than insist on a layer you do not need. The panel is there because it helps, rather than because it is the only way we know how to run a server.

Most hosting treats email as an afterthought, and it shows the moment your mail lands in spam. We run our own IP space, a /22 we control, and assign dedicated IPs whose reputation we manage rather than dropping you into a shared pool where one bad neighbour's spam drags down everyone's delivery. For any business whose mail matters, transactional messages, customer communication, outreach, that difference is the gap between reaching the inbox and quietly disappearing.

This is the part of hosting we know better than most, because email infrastructure is our deepest lane. The authentication is set up correctly from the start, SPF, DKIM, DMARC and alignment, the IPs are warmed and monitored, and the reputation is managed actively rather than left to chance. Where deliverability is central to what you do, the full picture lives in our email infrastructure work; in managed hosting it comes built in rather than bolted on, because a server your mail cannot leave cleanly is only half a service.

Moving hosting is where avoidable outages happen, usually because the cutover was a leap rather than a plan. We move the sites, databases and mail across, stand them up on the new servers, and test them there before anything changes for your users, so the new environment is proven before it goes live rather than after. cPanel-to-cPanel moves are the most straightforward, and we handle the messier cases, custom stacks and awkward dependencies, rather than declining the ones that are genuinely hard.

The cutover itself is scheduled with the downtime planned and minimised rather than discovered mid-move. DNS is prepared in advance, the switch happens at a time that suits your traffic, and there is a rehearsed way back if something unexpected surfaces. The aim is a migration your users barely notice, which is the opposite of the all-too-common version where a site disappears for a day because nobody mapped the dependencies before pulling the trigger.

Managed hosting earns its place when the cost of the infrastructure going wrong exceeds the cost of having someone run it properly. A business whose site or application is how it makes money, an organisation under GDPR or NIS2 that needs its hosting to be demonstrably sovereign and secure, a team with no server administrator and no wish to become one, each is a clear fit. So is anyone whose mail deliverability or data jurisdiction has become a problem on commodity hosting.

Where that is not you, we will say so. A hobby site, or a brochure page with no sensitive data and no revenue riding on it, is well served by inexpensive shared hosting, and paying for managed, sovereign infrastructure it does not need would be money wasted. We would rather tell you that than sell a plan you will not use, because the case for managed hosting is strong exactly where it applies and weak where it does not, and pretending otherwise would cost the trust we would rather keep.

For a regulated business the hosting layer is part of the audit, and the questions are specific: where is the data, who can reach it, how is it secured, and can you prove it. EU-resident, sovereign infrastructure answers the first three cleanly, and the fourth is where documentation matters. We provide the data processing agreement, the sub-processor position, and the residency and security details an assessor or a customer's procurement team asks for, rather than leave you to assemble them under deadline.

It also lightens the wider burden. Hosting European personal data with an EU operator outside the reach of the CLOUD Act removes the Schrems II transfer-impact-assessment exercise that a US-owned provider forces on you, and it satisfies the supply-chain due diligence NIS2 expects of the providers in your chain. The hosting stops being a gap you scramble to cover before an assessment and becomes a part of the estate that is already documented, which is the difference between compliance as a fire drill and compliance as a property of how things are run.

The headline price on a commodity plan is rarely the price you pay. The real bill arrives in the extras: bandwidth overage when traffic grows, charges to move your own data out, support that is an add-on rather than a given, backups billed separately, and the staff time spent doing the work the cheap plan left to you. A plan that looks half the price can cost more once the things you genuinely need are added back, which is why total cost of ownership is the only honest comparison.

We would rather be clear about what is included than win on a headline number and recover it in surprises. Management, security, backups in-region and support are part of the service rather than line items that appear later, and where a cost genuinely depends on usage we say so upfront. The aim is a price you can predict and reason about, because a hosting bill that springs surprises is its own kind of unreliability, and the cheapest-looking option is often the one that ends up costing the most.