What I would consider before self-hosting a business tool

Simon Høiberg wrote that saving money was not his main reason for self-hosting. He wanted control and independence, and said that asking his AI to deploy a template was faster than clicking around a cloud provider's interface. That is his experience. What interests me is the business decision that becomes possible when getting a tool running takes less effort.

Self-hosting means running software on infrastructure you manage, rather than leaving its operation entirely to a software provider. It can sound like something that requires me to become a different kind of person. In practice, my way into technical work is often much simpler: I ask Claude Code or ChatGPT Codex to investigate what I want to do, explain the options and help carry it out.

That changes what I can consider doing myself. A tool that would once have needed more technical work than I was willing to take on can become a realistic option. I can explore how it works, make changes and ask AI to help implement and operate it. I find that interesting because I get more say in how the tools supporting my business behave.

I would still want to be specific about the control I am looking for. Perhaps I want to change a workflow without waiting for a vendor. Perhaps I want to be able to export my information and move elsewhere. Those are different needs. Owning a server may help with one of them, while a suitable hosted product may already give me enough freedom for the other.

Suppose I wanted a small internal tool for collecting and searching public research. This is a hypothetical example, but it is the kind of recurring work where I can see a reason to explore an alternative. I would first look at what the existing service does for me, what frustrates me and what I would actually gain by running the tool myself. A lower subscription bill would be one part of that comparison.

Then I would look at the work included in the subscription. Who installs updates? Who notices when the tool stops working? Who can recover the information? A provider may handle some of this, with other parts still left to me. I need to understand the arrangement I have before I can decide whether taking more of it on would improve anything.

Coolify's explanation of its hosting options makes this concrete. With its self-hosted version, the user operates the Coolify instance, including updates, monitoring and recovery. With Coolify Cloud, its team operates that instance. In both cases, the user's servers and workloads remain their responsibility. Even within one product, paying for a managed service covers a particular part of the work.

For my hypothetical research tool, I would want to know how much disruption I could accept. If it were unavailable for an afternoon, could I continue working? If the latest notes disappeared, could I reconstruct them? The answers would help me decide how much effort to put into running it and whether it was a sensible place to begin. I would make a different decision for a tool people depend on to complete their work.

I can ask AI to help work through those questions too. I would explain the purpose of the tool, who uses it and what needs to be preserved. Then I would ask it to propose a way to maintain it and recover it, and to show me how we can check that the proposal works. That is a useful extension of the original request to get it running.

A backup is a good example. Coolify's backup documentation points out that creating a backup file does not establish that the application can use a restored copy. I would want to try recovering the research tool somewhere separate and check that I could find and use the notes again. That would tell me much more about the setup than a reassuring message saying the backup completed.

The same applies to ongoing maintenance. If I ask AI to help operate the tool, I want to define what it can do on its own and which changes I need to review. I also need a way to see when something needs attention. Automating that work can make self-hosting much more practical for me, provided the arrangement is clear enough that I know what I am relying on.

There will be tools where I would happily pay someone else to do more of the operating work. There may be others where the ability to change the tool makes it worth taking on more responsibility myself. I do not see a reason to make the same choice for everything in my business. I want the choice to follow the work, the benefit and the consequences of an interruption.

Simon's post opens a possibility I like: more of the technology I use can become something I am able to understand and shape. His claim about deployment speed is not a promise about my own setup, but I do not need it to be. The useful question for me is whether the control I would gain is worth the work I would agree to operate.

Before moving that research tool, I would want a clear answer to what gets better, who keeps it working and how we recover it. I can use AI to investigate those answers and help put the arrangement in place. That gives me a practical way to explore self-hosting, with enough understanding to decide whether I want to keep running it.