Most hosting companies our size operate nothing. They resell capacity from a larger provider, add a control panel, and put their name on the invoice. It is a reasonable business, and it is much cheaper to start than running the infrastructure yourself.
We went the other way. We take dedicated machines, install the hypervisor, decide how storage is laid out, build the network around them and decide what runs beside what. We rent the metal and the racks; everything above them is ours. It is worth being specific about what that buys a client, because "our own infrastructure" on its own is just a boast.
A virtual machine still runs on a machine
The abstraction is useful, but it is still an abstraction. A virtual machine has cores, memory and disks because somewhere underneath there are physical processors, memory modules and storage devices.
Somebody decided how many customers share those resources, what happens when the host is busy, how the storage is protected and how the network reaches it. On generic rented capacity, most of those decisions belong to somebody else.
That is often convenient. It also means that when a client asks a very simple question — what is my workload actually running on? — the answer can be surprisingly vague.
We can answer where your data is
Not "in the EU, probably". Which machine, in which rack, with which other workloads beside it. When a client has a compliance question, or a customer of theirs has one, the answer is a fact rather than a chain of three suppliers.
Predictable workloads like predictable infrastructure
Elastic pricing is excellent when a workload is genuinely elastic. If an application needs forty servers today, four tomorrow and four hundred for an hour next Tuesday, buying for the peak would be absurd.
A lot of business software is not like that. An ERP system, a document platform, a line-of-business application or a database may run continuously for years, with capacity that changes gradually and traffic that peaks without changing by two orders of magnitude.
For those, renting the same virtual resources every hour of every day becomes an expensive way of avoiding a capacity-planning problem that was not difficult in the first place.
We can move things without asking permission
A workload that has outgrown its machine gets moved, live, to one with more room. On resold capacity that is a support ticket to somebody else and a maintenance window you do not control. On our own cluster it is a Tuesday morning.
The same applies when something goes wrong. When storage latency jumps or one machine behaves differently from its neighbours, we can inspect the hypervisor, the physical disks, the interfaces and the neighbouring workloads, instead of stopping at the edge of somebody else's service. That does not make failures disappear. It leaves fewer black boxes while diagnosing them.
We know what a failure costs us
This one is less obvious. When the machines are ours to run, their failures are ours to absorb rather than somebody else's to absorb quietly, which makes us conservative in useful ways: enterprise disks rather than the cheapest that fit, spare capacity kept free so a node can be evacuated, backups tested because restoring them is our problem.
A reseller's incentives are different. Their failure mode is a credit note.
Dedicated does not mean one customer per server
Operating the infrastructure layer does not mean throwing away virtualisation. Our shared clusters still use hypervisors; the difference is that we run them. A client who needs more isolation moves to a managed dedicated server, and one who needs a cluster of their own moves to private cloud.
The technology underneath stays familiar and the isolation boundary changes, which makes moving between levels a migration we can plan rather than a change of supplier.
When we would choose cloud instead
There are plenty of cases where we would. A workload with violent demand swings is the obvious one. So is a project that leans on a hyperscaler's managed services, global edge network or specialised hardware. A short-lived environment may make no sense to provision physically, and geography can settle the question on its own.
The point is not that physical servers are inherently better. It is that cloud should be an architectural choice rather than the default answer to every question containing the word "server".
What it costs
Honesty requires the other side of this. Running the infrastructure ourselves means paying for dedicated machines whether or not they are full, committing to capacity before the demand for it arrives, and the occasional Saturday. It means we cannot undercut a large provider on a small virtual machine, and we do not try to.
If the cheapest possible instance is what you need, buy it from somebody enormous. If you need to be able to ask a question and get a real answer, that is what the difference in price is for.