Compass: Unser schlankes Hosting-Control-Plane

Vor einigen Monaten haben wir große Teile unserer Websites, Anwendungen und internen Infrastruktur auf einen neuen Dedicated Server umgezogen.

Keine verwaltete Blackbox. Kein vorkonfiguriertes Hosting-Bundle. Sondern ein sauberes Debian-System, bewusst von Grund auf aufgebaut.

Der gesamte Stack wurde intern konzipiert und provisioniert — mit KI-Unterstützung dort, wo sie die Arbeit sinnvoll beschleunigte:

• Caddy als Webserver und TLS-Eingangspunkt
• PHP-FPM für die Ausführung der Anwendungen
• MariaDB für relationale Daten
• Valkey für Caching und Queues
• Postfix, Dovecot und Rspamd für Mail
• unsere eigenen Unternehmensanwendungen
• Monitoring, Backups und operatives Tooling darum herum.

Heute läuft das System exakt so, wie es soll: schnell, flüssig, stabil und vollständig unter unserer Kontrolle.

Die Provisionierung des Basisservers selbst ist dabei nicht der schwierige Teil. Mit Ansible und einem sauber konzipierten Satz von Playbooks lässt sich die darunterliegende Maschine reproduzierbar und verlässlich konfigurieren.

Die interessantere Frage stellte sich danach: Wie provisioniert man klassische Hosting-Ressourcen auf einem modernen, individuell entworfenen Stack?

• Einen Webspace.
• Eine Datenbank.
• Mailboxen.
• Aliase.
• Webstatistiken.
• Domainspezifische Konfiguration.
• Zertifikate.
• Website-Repositories und Deployments.
• Service-Reloads.
• Zugriffsregeln.

Also all das, was man klassischerweise von einem Hosting-Anbieter erwartet — nur ohne architektonische Kontrolle aufzugeben.

Aus dieser Frage entstand Compass.

Warum nicht einfach Plesk oder cPanel?

Das ist die naheliegende Frage.

Und um es klar zu sagen: Werkzeuge wie Plesk oder cPanel existieren aus guten Gründen. Sie lösen eine breite Klasse von Problemen, sind ausgereift und für viele Umgebungen absolut passend.

Aber sie bringen auch Annahmen mit.

Sie strukturieren den Server auf ihre eigene Weise.

Sie erwarten bestimmte Kombinationen von Diensten.

Sie fügen Gewicht, Abstraktionsschichten und operative Gewohnheiten hinzu, die nicht zwingend zu einer modernen, bewusst entworfenen Infrastruktur passen.

Wir wollten etwas anderes:

• volle Kontrolle über den Stack
• Kompatibilität mit unserer konkreten Architektur
• Unterstützung für ein modernes Debian-basiertes Setup
• saubere Provisionierung statt schleichender Konfigurationsdrift
• schnelles Tagesgeschäft
• keine unnötig große Angriffs- und Bedienoberfläche
• und einen Workflow, der sich für uns ebenso natürlich anfühlt wie für unsere Hosting-Kunden.

Also haben wir nicht unsere Infrastruktur an ein historisch gewachsenes Hosting-Panel angepasst, sondern eine Verwaltungsebene um unsere Infrastruktur herum gebaut.

Das eigentliche Problem: Webspace-Provisionierung ist komplexer, als sie aussieht

Einen „Webspace“ anzulegen klingt simpel — bis man genauer beschreibt, was das tatsächlich bedeutet.

Eine neue Domain kann erfordern:

• eine Webserver-Definition
• Document Roots und Verzeichnisstruktur
• PHP-FPM-Pool-Einstellungen
• Laufzeitlimits
• Log-Verarbeitung
• TLS-Verhalten
• Datenbank-Zugangsdaten
• Mail-Domains
• Mail-Routing
• Zugriffsberechtigungen
• Statistik- und Analytics-Integration
• und einen verlässlichen Weg, all das anzuwenden, ohne produktive Konfigurationen von Hand zu editieren

Mail ist dafür ein gutes Beispiel.

Einen Mailserver für mehrere Domains und virtuelle Mailboxen zu betreiben, ist absolut machbar — aber nicht trivial. Eine neue Domain oder Mailbox lebt nicht an nur einer Stelle. Sie betrifft mehrere Dienste und Konfigurationskontexte zugleich. Zertifikate, Routing, Mailbox-Definitionen, Spamfilterung und Service-Reloads müssen sauber zusammenspielen.

Man kann das manuell verwalten.

Aber manuelle Infrastrukturverwaltung skaliert nicht elegant. Sie ist repetitiv, fehleranfällig und genau die Art von Arbeit, die zu einem System werden sollte, sobald das zugrunde liegende Muster verstanden ist.

An diesem Punkt greift bei uns meist dieselbe Logik: Wenn etwas wiederkehrend, strukturell klar und wichtig genug ist, um es gut zu machen, bauen wir ein Werkzeug dafür.

Compass: eine einfache Steuerungsebene über einem bewusst konstruierten Stack

Compass ist unsere interne Webanwendung zur Verwaltung dieser Hosting-Ressourcen.

Damit lassen sich — durch uns und, wo sinnvoll, auch durch unsere Kunden — unter anderem folgende Dinge anlegen und verwalten:

• Webspaces
• Domains
• Mail-Domains
• Mailboxen
• Aliase
• Datenbanken
• zugehörige Zugangsdaten
• Website-Deployments / Webhooks
• Webstatistiken
• und weitere operative Einstellungen

Die Anwendung selbst bleibt bewusst schlank. Sie soll kein universelles Hosting-Imperium werden. Ihr Zweck ist es, eine saubere, passgenaue Oberfläche für genau die Infrastruktur bereitzustellen, die wir tatsächlich betreiben.

Im Hintergrund arbeitet ein Provisionierungsmechanismus, der den gewünschten Zielzustand aus Compass übernimmt, daraus die nötigen Konfigurationsdateien erzeugt und diese sicher auf dem Server anwendet.

Diese Trennung ist wichtig.

Compass ist die Verwaltungsoberfläche.

Das Provisioning-Tool ist der systemnahe Ausführer.

Der Server bleibt konsistent und reproduzierbar.

Keine zufälligen Handänderungen.

Kein mysteriöser Zwischenzustand.

Keine Archäologie nach dem Motto: „Wer hat diese Datei vor einem Jahr eigentlich verändert?“

Schneller als klassische Hosting-Panels — weil es nur das tut, was wir brauchen

Im täglichen Einsatz hat sich Compass als erstaunlich angenehm erwiesen.

Eine Mailbox hinzufügen geht schnell.

Einen Alias anlegen geht schnell.

Eine Datenbank provisionieren geht schnell.

Einen Webspace hinzufügen oder seine Einstellungen anpassen geht schnell.

Und weil die Anwendung exakt um unser operatives Modell herum gebaut wurde, fühlt sich die Bedienung häufig sogar einfacher an als bei breiter aufgestellten kommerziellen Hosting-Panels.

Nicht, weil diese Panels schlecht gemacht wären. Sondern weil Compass einen deutlich engeren und bewussteren Fokus hat.

Es muss nicht jeden denkbaren Hosting-Stil der letzten zwanzig Jahre abdecken. Es muss unseren Stack außergewöhnlich gut unterstützen.

Dieser Fokus macht es:

• leichtgewichtig
• schnell
• vorhersehbar
• übersichtlich
• und angenehm im realen Arbeitsalltag

Die Website, die Sie gerade lesen, läuft auf genau dieser Infrastruktur. Ebenso der Großteil unserer weiteren Websites und eine wachsende Zahl von Kundenumgebungen.

Compass ist damit längst vom Experiment zum verlässlichen operativen Rückgrat geworden.

Echtzeit-Webanalyse direkt aus rohen Caddy-Logs

Ein besonders befriedigender Teil dieser Infrastruktur ist die Analytics-Schicht.

Unsere Caddy-JSON-Logs werden in Echtzeit durch Vector verarbeitet und anschließend in ClickHouse für Auswertungen übernommen.

Damit entsteht direkt aus unserer eigenen Infrastruktur eine schlanke, hochperformante Grundlage für Traffic-Insights:

• Requests
• Antwortverhalten
• Referrer
• Geräte und User Agents
• Fehlertrends
• Traffic-Muster
• und mehr

Das Ergebnis ist nicht einfach nur „Webstats“ im alten Shared-Hosting-Sinn. Es ist eine deutlich flexiblere Analytics-Basis, die bei Bedarf erweitert werden kann und sich danach richtet, wie wir unsere Systeme verstehen möchten.

Compass integriert diese Ebene in das Gesamterlebnis, sodass Website-Betrieb und Website-Sichtbarkeit deutlich näher zusammenrücken.

Für eine Hosting-Plattform ist das ein starker Zusatz. Für uns intern ist es schlicht sehr nützlich.

Auch für Kunden gebaut

Compass ist nicht nur eine interne Admin-Erleichterung.

Es unterstützt ebenso Self-Service für Kunden — dort, wo das sinnvoll ist.

Kunden können ausgewählte Bereiche ihrer Hosting-Umgebung selbst verwalten, ohne für jede kleine Änderung eine Anfrage stellen zu müssen. Gleichzeitig bleibt das System bewusst begrenzt und aufgeräumt. Niemand wird in ein ausuferndes Server-Panel mit Dutzenden irrelevanten Optionen geworfen. Kunden interagieren exakt mit den Bereichen, die für sie tatsächlich relevant sind.

Diese Balance ist entscheidend:

• genug Autonomie, um Reibung zu reduzieren;
• genug Struktur, um Verlässlichkeit zu bewahren;
• genug Einfachheit, damit das Werkzeug nicht sein eigenes Schulungsprogramm benötigt.

So bauen wir Systeme grundsätzlich am liebsten.

Nicht maximale Feature-Zahl. Maximaler Nutzen.

Ein sehr typisches Neoground-Projekt

Compass ist ein gutes Beispiel dafür, wie wir arbeiten.

Wir sind nicht mit der Idee gestartet, „eine Hosting-Plattform“ zu bauen. Wir sind mit einem realen operativen Bedarf gestartet:

Wir wollten moderne, hochkontrollierte Infrastruktur betreiben, ohne die routinemäßige Hosting-Verwaltung unnötig mühsam zu machen.

Also haben wir das System um genau dieses Bedürfnis herum entworfen.

Dafür kamen zusammen:

• Infrastrukturarchitektur
• Automatisierung
• Mail-Systemdesign
• sichere Provisionierung
• Webanwendungsentwicklung
• Analytics-Pipelines
• User Experience
• und operativer Pragmatismus

Es ist eines jener Projekte, in denen viele unserer Stärken zusammenlaufen: das ganze System sehen, unnötige Kompromisse ablehnen und Komplexität in etwas übersetzen, das sauber genug ist, um es täglich gerne zu benutzen.

Genau dabei unterstützen wir Kunden auch weit über Hosting hinaus.

Manchmal ist die Antwort strategische Beratung.

Manchmal ist es Prozessneugestaltung.

Manchmal sind es KI und Automatisierung.

Manchmal ist es eine individuelle Anwendung, die eine ganze Schicht wiederkehrender Reibung aus dem Alltag entfernt.

Compass ist dafür ein besonders greifbares Beispiel.

Werden wir Compass als Open Source veröffentlichen?

Möglicherweise.

Ein großer Teil von Compass und dem umliegenden Tooling könnte auch für andere technisch versierte Teams sehr nützlich sein, die sich wünschen:

• einen modernen, selbst verwalteten Hosting-Stack
• eine leichtere Alternative zu klassischen Control Panels
• oder schlicht Inspiration dafür, wie man eine eigene Verwaltungsebene um individuelle Infrastruktur herum baut

Wir prüfen derzeit, ob wir wesentliche Teile davon als Open Source veröffentlichen — abhängig von Interesse und Rückmeldungen.

Dieser Beitrag ist gewissermaßen die erste öffentliche Vorstellung dessen, was wir entwickelt haben.

Wenn das Konzept Resonanz findet — besonders bei Entwicklerinnen und Entwicklern, Agenturen, Hosting-nahen Teams oder infrastrukturaffinen Unternehmen — wäre das für uns sehr wertvoll zu wissen.

Die stille Kraft selbst gebauter Hebel

Nicht jedes Unternehmen sollte sein eigenes Hosting-Control-Plane entwickeln. Natürlich nicht.

Aber jedes Unternehmen sollte gelegentlich fragen: Wo tolerieren wir noch immer wiederkehrende Reibung, weil kein Standardwerkzeug ganz passt — und was würde passieren, wenn wir dieses Problem wirklich sauber lösen?

Compass existiert, weil wir diese Frage ernst genommen haben.

Das Ergebnis ist ein System, das unsere Infrastruktur einfacher betreibbar macht, unsere Hosting-Leistungen eleganter organisiert und unsere tägliche Arbeit spürbar glättet.

Es ist nicht flashy im oberflächlichen Sinn.

Es ist besser als das:

Es entfernt jeden einzelnen Tag leise Reibung.