Repair, don't replace — why self-hosted is the more honest cloud
In a Bus you know what is under the bonnet. In a cloud platform, mostly you don't. On the underrated virtue of running things yourself — and why „managed service" in industry often means the opposite of control.
When I open the engine bay of the T3 on a Saturday, I see exactly what is going on. There is the injection pump. There the lines run to the injectors. There is the primary filter, the main filter, the tank. Four or five components, all accessible, all named, all backed by a workshop manual sitting on the shelf in my garage. If a supplier goes out of business, I buy the part from another. If a manual goes out of print, two other publishers reprint it.
When I open the admin panel of a big cloud platform on a Saturday, I see tabs, dropdowns, and status indicators. What actually runs on which machine in which data center is a black box. Which code makes the decisions about what is allowed to happen — I don't know. If the vendor doubles the price tomorrow, that's my problem. If they retire the feature my workflow depends on, also my problem. If for regulatory reasons they have to shift region, the same.
This isn't cloud bashing. Cloud is great — for many things, it's the right choice. But it tends to be sold as the more responsible option. „Let the pros handle it." „You don't really want to manage servers, do you?" „We take away the complexity." Sometimes that's true. Sometimes it just means: you lose the overview, in exchange for the feeling that you never had one.
What self-hosted actually means
Before I defend self-hosting, a clarification. Self-hosted does not mean: „server under the desk in the maintenance room, looked after by the one person who is currently on holiday." Self-hosted means: you run the software on infrastructure you control, with tools you understand, in a form you can repair. That can be your own data center. It can be a NAS in the server closet. It can be a rented bare-metal box. What matters is not the sockets, it's the control.
I run a whole range of services myself — websites, monitoring, trading bots, data archives, internal tools — on a single Synology with Docker and nginx. Not because I can't afford AWS. But because for each of these services I know exactly: which container, which port, which volume, which log file, which restart mechanism. When something is wrong, it's wrong in one of ten places I hold in my head. That's repairability. That's the T3 diesel of infrastructure.
Three places where self-hosted is the easier choice in industry
1. When the data is a local game.
In industry, we often deal with data that cannot just leave the site. Recipes. Plant parameters. Maintenance histories from which production volumes can be reverse-engineered. Geometry and manufacturing data. In each of these cases, self-hosted is not the complicated answer but the simple one: the data stays where it already is. No data transfer agreement, no Schrems-II drama, no perpetual debate with compliance over the next risk review of the vendor.
2. When the system must live long.
Industrial software does not live two years. A COMOS database, a plant asset management solution, a maintenance planner — they run for 10, 15, 20 years. Cloud contracts change every 24 months. Prices, licence models, feature lists, regional availability. Whoever builds a 15-year plan on a platform that rearranges its foundations every two years has booked a whole stack of future migration projects without noticing. Self-hosted here means: you decide when to migrate — not a vendor's quarterly report.
3. When the load peak is predictable.
Cloud pays off when load is unpredictable. In industry, it rarely is. A shift starts at six and ends at fourteen. A maintenance module is opened at month-end. An engineering platform is used in the design phases. All of that can be served on predictable hardware, without the „on-demand" premium that cloud providers charge for flexibility nobody needs here.
What self-hosted is not
Self-hosted is not „free". A server consumes electricity, hardware ages, backups must be verified, security patches must be applied. Whoever ignores that gets the bill sooner or later — typically on an inconvenient Thursday morning. But: those are known costs. They don't sit in any licence document that's renegotiated every two years. They're as plannable as the next inspection appointment and the brake pads.
Self-hosted is also not „better than cloud". Some workloads are so dynamic, so global, so sporadic that cloud is simply the right answer. But in industry, that's far fewer workloads than vendor presentations suggest. The question I ask clients is never „cloud or self-hosted?" — but: „Who should be allowed to pull the plug in the end?" If the answer must be „we", then there is a default — and it is: run yourself what can be run yourself.
The T3 once more
My Bus has been running for 35 years. Not because it is particularly good, but because three conditions are met: parts exist, knowledge exists, and someone touches it. These three conditions are transferable. Self-hosted means: open standards exist (= parts), documentation exists (= knowledge), someone on the team understands it (= hands). Cloud can deliver all three too — but it can also stop doing so at any time, without asking you.
In my consulting I therefore rarely say „take self-hosted" and never „take cloud". I say: look at the kind of relationship you want with the system. And if that relationship is meant to hold up in five years, it is probably closer to a spanner than a browser tab.