Owning your own infrastructure, and when not to

The usual argument for self-hosting is money, and it is the weakest one available. A managed platform costs more per month than a virtual machine, and then you spend the difference on your own evenings. If the saving is the reason, do not do it.

The reason to run your own infrastructure is that you can answer questions about it. That sounds soft until the first time it matters, so this is what we mean concretely, and what it has cost us.

What you get#

You can answer "where is my data?" in one sentence. Ours is on a machine in Lauterbourg, France, and the backups are in one object storage bucket. That is the complete answer. It appears in our privacy documents without hedging, because there is nothing to hedge: there is no list of sub-processors we inherited from a platform, no region that quietly failed over somewhere else, no analytics vendor nobody remembers adding. Three third parties appear in our entire data path and we can name all three.

If you sell to anyone with a procurement process, you will be asked this question in writing. Being able to answer it in a sentence rather than a diagram is worth real money.

Nothing changes underneath you. No pricing page gets rewritten, no free tier gets withdrawn, no feature gets deprecated with twelve months' notice that lands in the middle of something else. The machine does in a year what it does today. For a company making commitments about its own pricing, depending on a vendor who can reprice us into our customers' invoices is an awkward position to be in.

You find out what you actually built. When we wrote Kubernetes manifests for an application that had been running under Docker Compose, the manifests disagreed with reality in several small ways nobody had noticed — including a debug logging flag left on in production and an application connecting to its database as the administrative user. None of that was discovered by thinking hard. It was discovered because you cannot write down a description of something you do not understand, and a platform that abstracts the description away lets you not understand it indefinitely.

The feedback loop is short. There is no support ticket between a symptom and a fix. That cuts both ways, and we will come back to it.

What it costs#

You are on call, and there is nobody else. This is the real price and it is not negotiable. A single node has no other node to move to. Kernel updates need a reboot, and a reboot is a visible outage. We accept that; a business with a 24-hour obligation to its customers should not, or should not accept it on one node.

Backups become your problem, and backups are harder than they look. Ours run nightly to object storage with retention implemented in the script rather than as a provider lifecycle rule, so that the policy lives in the repository instead of in a dashboard nobody reads. Writing that uncovered two defects: an upload verification step that was silently not verifying anything, and a cleanup path that had been leaving database password files inside a running container. Both were found by testing a restore rather than by reading the code.

A backup you have not restored is a hypothesis. Restore it against a database with real data in it, too — a restore into an empty database compares zero against zero and proves nothing.

You have to write things down, or the knowledge evaporates. Every decision about our platform goes in a numbered file with the context, the decision, the alternatives that lost, the consequences, and the condition that should reopen it. That is a discipline, not a document: it costs twenty minutes each time and it is the only reason a choice made in October is still defensible in March. A platform gives you a default and a changelog. Owning the stack means you are the changelog.

The security surface is yours. A firewall that denies by default, a Kubernetes API that is closed to the internet and verified closed from outside, an image registry on loopback and verified unreachable, automated security updates, and a login jail. None of that is difficult. All of it is now something you have to have actually done, and "verified from outside" is doing a lot of work in that sentence — assuming a port is closed because the config says so is how most of these go wrong.

When you should not#

We would tell someone not to do this if any of these are true.

• Your obligation is bigger than your team. If customers are entitled to an answer within an hour at three in the morning, you need either more people or a platform. One person and a pager is not a plan, it is a hope.
• The infrastructure is not the interesting part of your business. We run our own because understanding the whole stack is genuinely useful to what we sell. If yours is a product where the server is an inconvenience, pay somebody to make it invisible. That is a good trade.
• You have to grow unpredictably. Elasticity is the thing a platform is genuinely better at, and a single node is the opposite of elastic. Our load is predictable, so we are not buying something we do not need.
• You cannot say no to a shortcut. Owning the stack means every temptation is available to you: the quick manual fix, the undocumented change, the one-off script on the box. A platform's constraints protect you from yourself. Without them, the only constraint is the discipline of writing down what you did, and if you will not do that reliably, the machine will become a mystery within a year.

What this looks like in practice#

One virtual machine. A firewall that denies by default. nginx terminating TLS for every hostname, with certificates from certbot. A single-node Kubernetes cluster for the applications, with an image registry on loopback and every image tagged with the commit that built it. A mail server for the company's own correspondence, and a third party for application mail so one bad week for automated e-mail cannot stop replies to customers arriving. Nightly off-box backups with a tested restore. And a directory of numbered decisions explaining why each of those is the way it is.

None of it is clever. That is deliberate: clever infrastructure is infrastructure you cannot debug when you are tired. The point is not that this arrangement is optimal. It is that we can explain every part of it, and when something breaks at two in the morning, that is the only property that helps.

Our word for what we are trying to build here is barakah — growth that benefits everyone it touches rather than extracting from one side. Running our own infrastructure is part of that in a very ordinary way: our costs are predictable, so we are not under pressure to find revenue in our customers' data or in a price rise they did not see coming. Owning the stack is not a virtue. It is just the arrangement that makes the commitments easiest to keep.