Open-source and self-hosting: how we run our systems

When you register a domain with INWX, order a TLS certificate, or change a DNS record, those operations run on systems we built ourselves and run ourselves. On our own hardware, in German data centers, with software that is mostly open source.

Renting the infrastructure would have been easier than running it. Managed databases, managed DNS, object storage: the large cloud providers have a product for every building block, ready in minutes. No data center, no hardware procurement, no on-call rota for failed disks.

We chose open source and self-hosting anyway. Here is why.

Why we prefer open-source and what that actually means

“Open source” means the source code of a piece of software is publicly available. In day-to-day operations, that brings a few concrete advantages.

Traceability: When software behaves differently than documented, we can look at the code ourselves and resolve the problem. We stay independent and don't depend on a vendor's support channel.

Adaptability: Over 2,200 domain endings, each with its own rules, registry interfaces at very different levels of sophistication, and special cases among the ccTLDs. No off-the-shelf product covers that complexity in full. This is exactly where open-source matters, because we end up with software we can extend and adapt to our own requirements.

No forced migrations: proprietary products get discontinued or relicensed. Anyone who built on them has to migrate, which means depending on the vendor's decisions. With established open-source projects, the existing code stays available, and as a rule, someone carries the work forward.

Why we prefer to host it ourselves

Using open-source software doesn't automatically mean hosting it independently, because open source products can be bought as a managed service too. There are separate reasons why we also run our infrastructure ourselves.

A shorter data path: registering a domain involves personal data. Some of it has to be passed on to the registries, the organizations that administer each domain ending, but what happens with the data beyond that is our decision. Our databases run on our own hardware, so there is no additional processor involved and no question about server locations in sub-processing arrangements. That makes GDPR compliance simpler: a shorter data path means there is less to check.

We fix problems ourselves: when a rented service fails, all we can do is open a support ticket and wait for the provider to resolve it. When something fails in our own infrastructure, our team can access the affected systems directly and get to work.

Independence from consolidation: a large share of the internet runs through a small number of providers. When something breaks there, a great many services tend to go down at once. Running our own infrastructure doesn't protect us from outages, but it does mean our availability depends on our own decisions.

Why this matters for you as a customer

As an INWX customer, you notice very little of this, which is how it should be. Infrastructure is meant to stay in the background.

You notice it in the exceptions: when an unusual ccTLD needs an adjustment in our systems, when a disk fails overnight, or when a change to your DNS records has to take effect immediately. Those are the moments when it matters whether we open a ticket or go to the systems ourselves.

And there is one thing that holds every day, outages or not: your data stays with us. What has to go to the registries goes to the registries; that is part of the domain business. Beyond that, your data sits with INWX.  Not with a large cloud provider processing it on our behalf, not in a data center outside Germany, and not with one of the big US corporations operating under different data protection principles than ours. It sits on our own servers in Germany and, therefore, within the scope of the GDPR.

That keeps things easy for us to explain and easy for you to follow. There are shorter chains of processors and sub-processors whose locations you would otherwise have to trace, fewer standard contractual clauses for third-country transfers, and fewer open questions about whether a foreign authority could demand access to systems that also hold your data.

A look at part of our infrastructure

Debian is the operating system on our servers. Long support windows, a conservative update policy, and good documentation. For systems meant to run for years without interruption, predictability matters more than having the newest package versions.

PowerDNS runs our DNS infrastructure. It has a modular design, works with a range of database backends, and can be controlled through an API. That is what allows changes to your DNS records in the customer area to take effect quickly. It supports DNSSEC as well.

OpenSSH secures the connections between our systems and the administrative access to them. It is developed within the OpenBSD project, which is known for a very strict approach to code quality and security. Anyone connecting to a server over SSH is most likely using this implementation.

Proxmox VE is our virtualization platform. It combines several physical servers into a cluster running virtual machines, which can be moved between nodes when needed, for instance, ahead of maintenance on a host. Proxmox is developed in Vienna and released under a free license.

IPinfo provides the IP geolocation data we use to show visitors to our website the right language and currency. We keep the database as a local copy on our own servers and update it at regular intervals, so no IP address ever leaves our network