In short
Self-hosting refers to running software on your own or rented infrastructure under your own responsibility, instead of obtaining it as a cloud service operated by a provider.
The term sounds like a server room in the basement, but in practice it usually means something else: a rented cloud or root server at a hosting provider, on which the company installs, configures and updates the software itself. What matters is not who owns the hardware but who controls the software: with self-hosting, the company itself decides on the version, configuration, data storage and the timing of every update. A general introduction is provided by the Wikipedia article on self-hosting; this entry concentrates on practice in mid-sized companies.
Distinction: SaaS, managed hosting, on-premises
Self-hosting is quickest to understand in contrast to the three neighbouring models:
| Model | Who runs the software? | Where does it run? | Typical examples |
|---|---|---|---|
| SaaS | The provider | On the provider's infrastructure | HubSpot, Salesforce, ChatGPT in the browser |
| Managed hosting | A service provider on your behalf | On a rented, dedicated environment | Managed WordPress, managed n8n |
| Self-hosting | The company itself | On rented servers or its own hardware | n8n on a Hetzner server, Nextcloud |
| On-premises | The company itself | On its own hardware in its own building | ERP in its own data centre |
On-premises is thus a special case of self-hosting with your own hardware: historically the norm, today the exception. The common form in mid-sized companies is the middle way: rented infrastructure at a European hosting provider, run under your own responsibility. You buy your way out of hardware worries and keep control of the software.
Why self-hosting is making a comeback in 2026
What is remarkable first of all is the reversal of direction. Before the cloud era, running software in-house was simply the normal state of affairs; the term self-hosting only emerged when SaaS became the standard and running it yourself became a deliberate decision. After fifteen years in which "moving to the cloud" was a synonym for modernisation, a growing part of the tool landscape is now moving back onto company-controlled servers. The industry has adopted the term cloud repatriation for this; the most prominent documented example is the software maker 37signals (Basecamp), which publicly recorded its complete departure from AWS, including the cost calculation. Behind the trend are four tangible reasons.
Cost control. SaaS is mostly billed per user and month. Costs grow with team size, regardless of how intensively the tool is used, and price increases arrive by announcement email. A self-run server, on the other hand, costs a fixed monthly amount, usually in double figures, whether ten or two hundred people work with the software. For tools that the whole company uses, the calculation therefore often tips in favour of running it yourself even with small teams.
Data control and the legal position. The debate about the CLOUD Act has made many management teams aware that data held by US providers remains legally accessible, no matter where the server is located. Self-hosting on European infrastructure is the structural answer to this and a central building block of digital sovereignty: the data is where only your own company and its hosting provider have access. With productive AI use, the question becomes more acute, because prompts, knowledge bases and agent memories are process knowledge that you would rather not leave to age in other people's accounts.
The maturity of open source. For almost every SaaS category, there is now a self-hostable alternative at a professional level: n8n for workflow automation, Nextcloud for file storage and collaboration, Keycloak for identity management, Grafana for monitoring, PostgreSQL with pgvector or Qdrant as the database and vector layer. Behind them are not hobby projects but companies with open-source or fair-code business models that live from paying enterprise customers and maintain their software accordingly.
The leap in tooling. Ten years ago, self-hosting meant maintaining Linux packages, configuration files and dependencies by hand. Containers have cleared this hurdle away. Today a single file describes the complete application stack, and platforms such as Coolify turn a rented server into an environment that can be operated like a cloud service. The admin effort has not disappeared, but it has shrunk from "a discipline of its own" to "a learnable side task".
The typical self-hosting stack in mid-sized companies
Docker and Docker Compose as the foundation
The basis of almost all modern self-hosting set-ups is containers. An application is packaged together with all its dependencies into a standardised image and therefore runs the same way on every server. Docker Compose describes the complete stack in a single YAML file, for example the application, its database and a reverse proxy. This makes installations reproducible and moves trivial: the Compose file plus a database backup are the complete description of the system. An update usually consists of entering a new image version and restarting the stack, after a look at the release notes.
Coolify: self-hosting with PaaS convenience
Anyone who does not want to work on the command line puts a self-hosting platform on the server. The best-known example is Coolify, an open-source tool that behaves like a self-run counterpart to Heroku or Vercel: applications, databases and dozens of preconfigured services are installed via a web interface, HTTPS certificates come automatically, deployments run directly from the Git repository if desired, and backups can be scheduled. Coolify itself runs on any server with SSH access. Which tools can be run with it in everyday use is shown in our Coolify guide with concrete open-source alternatives to SaaS subscriptions.
Example: AI automation on a Hetzner server
A typical mid-sized set-up in 2026 looks like this: n8n runs as the workflow engine on a Hetzner cloud server, alongside it PostgreSQL with pgvector as the knowledge and vector database, and in front of them a reverse proxy with TLS and access protection. The whole thing is rolled out and updated via Coolify or a Compose file in the Git repository, so that the complete stack is versioned and can be reproduced on a fresh server within an hour. The AI workflows call a large language model via API, sometimes GPT, sometimes Mistral, depending on the task and the data. The point of this set-up: workflows, prompts and the knowledge base are entirely within your own control, while the models remain interchangeable suppliers. If a provider fails or changes its terms, you change the API endpoint, not the architecture.
The basic security kit
Regardless of the tool, every serious self-hosting set-up includes a minimum level of hardening that can be set up in an afternoon and lasts for years:
- A reverse proxy with automatic TLS in front of all applications; no service talks directly to the internet.
- Admin interfaces not publicly accessible but placed behind a VPN or IP allow-lists.
- Automatic security updates for the operating system, application updates according to the release notes.
- Tested backups following the 3-2-1 principle: three copies, two media, one of them off-site.
- Basic monitoring with alerts for availability, disk space and failed log-ins.
The honest trade-offs
Self-hosting shifts responsibility, and you have to want that. The licence costs nothing, but operation does: security updates must be applied promptly, because a publicly accessible application with a known vulnerability will be found; it is not a question of if. Backups only really exist once a restore has been rehearsed. Monitoring and alerting are needed so that a full disk at the weekend is not only noticed on Monday. And there needs to be an answer to the staffing question: who takes care of things when the person responsible is on holiday?
Then there is availability. A SaaS provider guarantees it contractually with an SLA; with self-hosting, there is only the promise you make to yourself. For internal tools that can cope with an hour of downtime, this is not critical. For systems on which revenue depends directly, it is a deliberate risk decision that should be backed up with redundancy and processes, not optimism. Anyone who realistically estimates these operating tasks at two to four hours a month for a well-maintained standard set-up is calculating more honestly than with zero.
When SaaS remains the better choice
Self-hosting is a tool, not a world view. SaaS remains the better choice when high availability is required without an in-house operations team, when certifications and compliance evidence have to be supplied ready-made, or when the value of the service lies precisely in the network, as with email and collaboration platforms. Rarely used specialist software usually does not justify the operating effort either. The sensible question to ask is not "SaaS or self-hosting?" but: how central is the tool to our processes, how sensitive is the data in it, and how easily could we get out again? A SaaS subscription with a clean export path is unproblematic; it becomes critical when core processes sit in someone else's ecosystem without an exit option and the vendor lock-in grows with every year. Many companies therefore run a two-track approach: standard collaboration from the cloud, process-critical automation and knowledge on their own infrastructure.
Frequently asked questions about self-hosting
Is self-hosting automatically more GDPR-compliant than SaaS?
No, but it simplifies the situation structurally. The US third-country transfer for the self-run application no longer applies, and with a European hosting provider a data processing agreement for the infrastructure is sufficient. In return, the obligation to implement technical and organisational measures moves entirely in-house: nobody else is responsible any more for encryption, access concepts, deletion periods and patch status.
What does self-hosting really cost?
Server costs are the smallest item, a monthly amount in double figures for typical mid-sized set-ups. The calculation only becomes honest once you add the working time for updates, backups and monitoring. In return, the user-based subscription fees that grow linearly with a growing team disappear. The calculation pattern: a SaaS tool at 20 euros per user and month costs a team of 25 people 500 euros a month, i.e. 6,000 euros a year; the server on which a self-run alternative runs costs a fraction of that, and the gap grows with every new hire. As a rule of thumb, the comparison is always worthwhile when a tool is used by many people or processes sensitive data.
Do you need Kubernetes for self-hosting?
In the vast majority of cases, no. Kubernetes pays off for platform teams with many services and high availability requirements. A mid-sized set-up with a handful of applications is better served by Docker Compose or a platform such as Coolify: fewer moving parts, less specialist knowledge, the same control.
Which applications are suitable for getting started?
Internal tools without hard availability requirements: workflow automation such as n8n, monitoring, a knowledge base, an analytics tool. This lets the team gain operating experience with systems whose failure no customer notices. You only migrate the revenue-critical shop system or the ERP once backups, updates and alerting have become routine, or deliberately not at all.