Why We Rely on Self-Hosted Open Source

The Question of Control

As a European company that develops and operates software, there's one question you can no longer avoid: where does our data reside, and who has access to it? Since the GDPR came into effect in 2018, awareness of data sovereignty has noticeably shifted. But for us, it wasn't regulation alone that tipped the scales. It was the realization that as a consultancy advising clients on architectural decisions, we need a clear stance on our own infrastructure.

Some time ago, we decided to build our internal infrastructure on self-hosted open-source solutions. Not for ideological reasons, but for pragmatic ones. In this post, we explain why we chose this path, what our stack encompasses, and where the honest trade-offs lie.

Why Self-Hosted?

Three factors determined our decision.

Data sovereignty. Our client data, internal documents, source code, and communications reside on servers that we control. No US hyperscalers, no Cloud Act, no question about whether a third party is analyzing our data for their own purposes. When a client asks where their project data is stored, we can give a clear answer.

Independence from vendors. Vendor lock-in is a creeping problem. You start with a free tier, integrate ever deeper, and at some point switching becomes prohibitively expensive. Or the vendor changes their pricing structure, their terms of service, or gets acquired. Running your own infrastructure means retaining the freedom to choose. When a piece of software no longer fits, you migrate -- on your own schedule and on your own terms.

Cost control. SaaS prices scale per user and per month. For a small team, that may be manageable. But the costs add up quickly when you book Git hosting, file storage, identity management, CMS, project management, and monitoring separately from different providers. Our servers run on predictable fixed costs. The hardware is purchased once, the software is free.

Our Stack

Over the past years, we've assembled a stack that covers our daily needs. All services run as containers on our own Kubernetes cluster.

Gitea replaces GitHub or GitLab as our Git hosting platform. Gitea is written in Go, extremely resource-efficient, and offers everything we need: repositories, pull requests, issues, a usable web interface, and a well-documented API. Resource consumption compared to a self-hosted GitLab instance is minimal -- and for a team our size, that's a relevant factor.

Keycloak handles identity and access management. Single sign-on for all internal services, user management, role assignment, integration via OpenID Connect and SAML. What you'd otherwise outsource to Auth0 or Okta runs on our own infrastructure. The initial configuration of Keycloak is more involved than with a hosted IAM service, but in return we have full control over realms, flows, and policies.

Nextcloud serves as our file storage and collaboration platform. Documents, calendars, contacts -- all in one place, without files ending up on third-party servers. Nextcloud apps extend the platform with features like Kanban boards and collaborative text editing. Not all of it reaches the quality of Google or Microsoft equivalents, but it serves its purpose and the data stays with us.

Directus is our headless CMS. Blog posts, website content, and structured data are served via a clean REST and GraphQL API. Directus sits directly on the database and generates the API automatically from the schema. For developers, this is a significantly more pleasant experience than working with traditional CMS systems.

On top of that, we run Prometheus and Grafana for monitoring and alerting, our own mail server, and various smaller services that have accumulated over time.

The Platform Underneath

Our entire stack runs on Kubernetes, which we operate on our own physical servers. As the host operating system, we use NixOS, which provides us with a reproducible and traceable infrastructure through its declarative configuration. The actual applications run exclusively as containers within Kubernetes.

Running Kubernetes on your own hardware is no trivial undertaking. But as a company that advises clients on exactly these topics, it's also an investment in our own expertise. We experience the problems our clients face firsthand -- and can therefore provide better advice.

The Honest Trade-offs

Self-hosting comes at a cost, and it would be dishonest to conceal that.

Operational overhead. Updates, backups, monitoring, troubleshooting -- all of this is our responsibility. When Keycloak won't start after an update, there's no support ticket button. You read the release notes, check the changelogs, and debug it yourself. That costs time you wouldn't need to invest with a SaaS product.

Availability is our responsibility. When a service goes down, we're the only ones who can fix it. There's no vendor SLA to hide behind. Our Kubernetes infrastructure absorbs a lot -- pods are automatically restarted, nodes can fail without affecting the entire stack. But the ultimate responsibility lies with us.

Kubernetes expertise is a prerequisite. Self-hosting at the level we operate requires solid knowledge of container orchestration. Without Kubernetes experience, running these services would be significantly more time-consuming and error-prone. For us as a Kubernetes consultancy, that's not a problem -- for other companies, it can be a serious barrier.

Not everything is worth self-hosting. We don't host everything ourselves. For email delivery to external recipients, we use a specialized provider because the complexity of reputation management doesn't justify the self-hosting effort. For services we use only sporadically and that don't touch sensitive data, we pragmatically fall back to SaaS. Self-hosting is a deliberate decision per service, not a dogma.

Who Should Consider Self-Hosting?

Self-hosting on Kubernetes is not an approach for everyone. Without a team with infrastructure experience, you'll spend more time on operations than on your actual business. The barrier to entry is real.

It makes sense for companies that already have Kubernetes expertise in-house, that value data sovereignty, and that are willing to view the additional operational effort as an investment in independence and competence. For us, that applies.

The tools are there. Open-source projects like Gitea, Keycloak, Nextcloud, and Directus have reached a maturity in recent years that has turned self-hosting from a hobby project into a serious alternative. Kubernetes has drastically reduced deployment and operational complexity. What would have been disproportionately expensive five years ago is achievable today with reasonable effort.

Conclusion

Our decision for self-hosted open source wasn't ideological -- it was strategic. Data sovereignty, vendor independence, and cost control are tangible advantages that justify the additional operational effort. Not for every company, but for us.

Those who have the expertise and don't shy away from the effort gain something no SaaS provider can sell: complete control over their own infrastructure. In a time when data sovereignty is increasingly becoming a competitive factor, that's no small advantage.