Der NameOcean-Stack: Python, Django, Redis und Proxmox

Kurz gesagt: NameOcean ist eine Python- und Django-Anwendung. PostgreSQL speichert die Daten, Redis dient als Cache, Hintergrundaufgaben laufen über zwei Queue-Systeme (RQ auf Redis für kurze Jobs, Dramatiq auf RabbitMQ für aufwendigere Pipelines), das Kunden-Hosting läuft in Proxmox-LXC-Containern auf unseren eigenen Servern, und Sie können alles über den Browser, ein in Go geschriebenes Kommandozeilen-Tool oder Ihren KI-Assistenten per MCP verwalten. Dieser Beitrag geht jede Schicht durch und erklärt, warum wir uns dafür entschieden haben.

Der Stack im Überblick

• Sprache und Framework: Python mit Django, ausgeliefert über Gunicorn hinter Nginx.
• Datenbank: PostgreSQL mit Point-in-Time-Recovery-Backups auf einen separaten Backup-Server.
• Cache: Redis, genutzt über django-redis und django-cacheops.
• Queues: RQ (django-rq) auf Redis sowie Dramatiq auf RabbitMQ.
• Hosting: Proxmox-VE-Hosts, die jeden Kundenserver als LXC-Container betreiben.
• DNS: unsere eigenen PowerDNS-Server, ns1 bis ns4.
• Object Storage: ein selbst gehosteter, S3-kompatibler Speicher für Dateien, Backups und Blogbilder.
• Client-Tools: das nameocean-CLI (Go) und unser Remote-MCP-Server für KI-Clients, beide auf Basis derselben öffentlichen API.
• Deployments: git push plus ein einziger Fabric-Befehl. Niemand bearbeitet Code direkt auf einem Server.

Möchten Sie wissen, wie eine andere Website aufgebaut ist? Unser kostenloser Website Technology Checker zeigt Hosting-Anbieter, CMS, Programmiersprache und Framework jeder beliebigen Domain. Probieren Sie es mit nameocean.net aus.

Warum Python und Django

Von außen wirkt ein Domain-Registrar simpel: Namen suchen, bezahlen, DNS verwalten. Darunter steckt jedoch jede Menge Geschäftslogik. Es gibt Registrar-APIs, Transfers mit eigenen Zustandsautomaten, Verlängerungen, Rechnungen in mehreren Währungen, die Ausstellung von SSL-Zertifikaten, DNS-Zonen, Postfächer und Hosting-Server – und das alles in 21 Sprachen. Wir wollten einen Stack, der diese Logik lesbar hält und es einem kleinen Team ermöglicht, sicher auszuliefern. Genau das bietet uns Django.

„Batteries included“ – und zwar wirklich

Django bringt die Bausteine mit, die jeder Registrar vom ersten Tag an braucht:

• ORM und Migrationen. Unsere Modelle (Domains, Zonen, Transfers, Rechnungen, Server) ändern sich jede Woche. Mit Django-Migrationen wird jede Schemaänderung zu einer geprüften Datei in git, die lokal, in Tests und in der Produktion auf dieselbe Weise ausgeführt wird.
• Der Admin. Support und Betrieb arbeiten im Django-Admin. Ein internes Backoffice mussten wir nicht selbst bauen. Wir passen den Admin dort an, wo es darauf ankommt, etwa bei sicheren Löschvorgängen und Abrechnungsaktionen.
• Authentifizierung und Sicherheit. Sessions, CSRF-Schutz, Passwort-Hashing und ein eigenes, auf E-Mail-Adressen basierendes Benutzermodell sind bereits eingebaut. Zusätzlich haben wir Zwei-Faktor-Authentifizierung ergänzt.
• Internationalisierung. Die Website ist mithilfe der gettext-Werkzeuge von Django und sprachspezifischer URL-Präfixe in 21 Sprachen übersetzt. Englisch benötigt kein Präfix, die anderen Sprachen erhalten /tr/, /de/ und so weiter.
• Sitemaps, Caching, Templates. Alles Standard, alles gut dokumentiert.

Eine Sprache von der Website bis zu den Servern

Python steckt nicht nur in der Web-App. Dieselbe Sprache betreibt die Queue-Worker, die Management-Befehle hinter unseren Cronjobs, die Skripte für die Kommunikation mit Proxmox, die DNS-Werkzeuge (dnspython) und unsere Deploy-Skripte (Fabric). Wer die Checkout-View lesen kann, kann auch den Code lesen, der einen Hosting-Container anlegt oder ein Zertifikat erneuert. Für ein kleines Team ist das wichtiger als reine Geschwindigkeit.

Die Ausnahme bilden die Tools, die auf Ihrem Rechner laufen. Jeden Nutzer zu bitten, Python und eine Reihe von Paketen zu installieren, wäre ein schlechter erster Eindruck. Deshalb ist das CLI in Go geschrieben (mehr dazu weiter unten). Es enthält keine eigene Geschäftslogik: Alles läuft über dieselbe Django-API.

Ein ausgereiftes Ökosystem

Für fast alles, was wir integrieren, gibt es eine solide Python-Bibliothek: Stripe für Zahlungen, Django REST framework für unsere öffentliche API, S3-Clients im Stil von boto, die Proxmox-API und Sentry-kompatibles Error-Reporting. Auch unser Remote-MCP-Server, über den KI-Assistenten Domains und DNS für Kunden verwalten können, ist Teil der Django-App.

Was wir in Kauf nehmen – und wie wir damit umgehen

Python ist nicht die schnellste Sprache, und ein synchroner Django-Request sollte nicht auf eine langsame Registrar-API warten. Wir lösen das auf drei Wegen: Aufwendige oder langsame Aufgaben landen in einer Queue, häufige Lesezugriffe kommen aus Redis, und die Datenbank ist für unsere Abfragemuster optimiert und indiziert. In der Praxis ist der Engpass fast immer eine externe API, nicht Python.

PostgreSQL: die zentrale Datenquelle

Jede Domain, jede Zone, jede Rechnung und jeder Server liegt in PostgreSQL. Wir haben uns dafür entschieden wegen der strikten Transaktionen (Geld und Domain-Inhaberschaft dürfen niemals nur halb geschrieben werden), der umfangreichen Datentypen wie JSON-Felder und Netzwerkadressen sowie eines verlässlichen Backup-Konzepts. Die Backups laufen kontinuierlich: Das Write-Ahead-Log wird auf einen separaten Backup-Server übertragen, sodass wir die Datenbank auf jeden beliebigen Zeitpunkt wiederherstellen können – nicht nur auf den Dump der letzten Nacht. Ein Warm-Standby-Webserver nutzt dieselbe Datenbank und kann übernehmen, falls der primäre Webserver ausfällt.

Redis: Cache zuerst

Redis ist unser Cache. Abfragen zu Domain-Verfügbarkeit und Preisen, gerenderte Seitenfragmente und Rate Limits liegen alle in Redis, sodass eine wiederholte Anfrage weder die Registrar-API noch die Datenbank berührt. Jeder Cache-Schlüssel enthält die Sprache, denn dieselbe Seite unterscheidet sich zwischen / und /tr/. Außerdem nutzen wir django-cacheops, um ORM-Querysets zu cachen und automatisch zu invalidieren, sobald sich eine Zeile ändert.

Redis war eine naheliegende Wahl: schnell, einfach zu betreiben und hervorragend in Django unterstützt. Und weil es ohnehin vorhanden ist, dient es auch als Backend für unsere schlanke Job-Queue.

Queues: RQ auf Redis und Dramatiq auf RabbitMQ

Viele Vorgänge, die ein Kunde anstößt, sollten die gerade angezeigte Seite nicht blockieren. Eine Domain bei der Registry registrieren, ein SSL-Zertifikat ausstellen, eine Postfachadresse anlegen oder einen Hosting-Container starten – all das dauert Sekunden oder Minuten. Diese Jobs landen in einer Queue, und Worker arbeiten sie ab. Wir betreiben zwei Queue-Systeme, jedes für die Aufgaben, die es am besten erledigt.

RQ (django-rq) auf Redis

RQ ist die einfachste Queue der Python-Welt: Ein Job besteht aus einer Python-Funktion und ihren Argumenten, gespeichert in Redis. Wir nutzen sie für die alltäglichen Aufgaben der Website:

• Anlegen des Kundenkontos beim Registrar nach der Registrierung,
• Ausstellen und Erneuern von SSL-Zertifikaten,
• Synchronisieren von Domain-Status und DNS-Zonen,
• Hinzufügen von E-Mail-Adressen und Weiterleitungsregeln,
• Starten und Stoppen von Hosting-Containern, Öffnen von Ports und Konfigurieren von Nginx für einen Kundenserver,
• Erstellen von Rechnungen und Versenden von Verlängerungserinnerungen.

Ein Scheduler-Prozess führt wiederkehrende Jobs aus, und das django-rq-Dashboard zeigt wartende, laufende und fehlgeschlagene Jobs direkt im Admin an. In der Entwicklung läuft die Queue synchron, sodass ein Job inline ausgeführt wird und seine Fehler sofort sichtbar werden.

Dramatiq auf RabbitMQ

Für aufwendigere und länger laufende Pipelines verwenden wir Dramatiq mit RabbitMQ als Broker. RabbitMQ ist ein dedizierter Message Broker: Nachrichten werden erst bestätigt, wenn ein Worker sie fertig verarbeitet hat, sodass ein Job nicht verloren geht, wenn ein Worker mittendrin abstürzt. Dramatiq ergänzt automatische Wiederholungsversuche mit exponentiellem Backoff, Zeitlimits, Prioritäten und Middleware. Das passt zu Workloads mit vielen Schritten, hohem Volumen oder externen Diensten, die gelegentlich ausfallen.

Warum zwei Queues?

RQ hält einfache Jobs einfach: kein zusätzlicher Dienst, leichtes Debugging, und Redis läuft ohnehin. RabbitMQ und Dramatiq bieten stärkere Zustellgarantien und mehr Durchsatz, wenn ein Job das wirklich braucht. Indem wir je nach Workload entscheiden, zahlen wir nicht den Betriebsaufwand eines vollwertigen Message Brokers für einen Fünf-Sekunden-Job – und vertrauen eine kritische Pipeline nicht dem einfachsten Werkzeug an.

Hosting: Proxmox und LXC-Container

Unsere Tarife für Hosting und Vibe Hosting laufen auf unseren eigenen Proxmox-VE-Servern. Jeder Kundenserver ist ein LXC-Container, keine vollständige virtuelle Maschine.

• Container teilen sich den Kernel des Hosts, starten daher in Sekunden und benötigen weit weniger Arbeitsspeicher als VMs. So fließt mehr Hardware in die Anwendung des Kunden statt in ein zweites Betriebssystem.
• Jeder Container ist isoliert – mit eigenem Dateisystem, eigenen Prozessen, eigenem Netzwerk und Ressourcenlimits für CPU, Arbeitsspeicher und Festplatte.
• Alles ist über die Proxmox-API automatisiert. Wenn Sie einen Server bestellen, schickt Django einen Job in die Queue, und ein Worker erstellt den Container aus einer Vorlage, setzt seine Limits, bindet das Netzwerk an, öffnet Ports und konfiguriert Reverse Proxy und SSL für Ihre Domain.
• Größenänderungen, Backups und Wiederherstellungen sind Schaltflächen im Dashboard, die dieselbe API aufrufen. Container lassen sich außerdem zwischen Proxmox-Hosts verschieben, wenn wir die Last neu verteilen.

Eigene Hardware bedeutet planbare Preise und volle Kontrolle über das Netzwerk, die Backups und den Speicherort der Daten.

DNS, E-Mail und Speicher

• DNS: Zonen werden von unseren eigenen PowerDNS-Servern (ns1 bis ns4) ausgeliefert. Änderungen, die Sie im DNS-Panel vornehmen, werden auf den Primärserver geschrieben und automatisch an die Sekundärserver weitergegeben. Der Primärserver wird jede Nacht gesichert.
• E-Mail: E-Mail-Hosting und die kostenlose E-Mail-Weiterleitung laufen auf unseren eigenen Mailservern, mit SPF, DKIM und DMARC für Ihre Domain eingerichtet.
• Object Storage: Ein selbst gehosteter, S3-kompatibler Speicher bewahrt hochgeladene Dateien, Backups und Bilder auf.

Das nameocean-CLI und der MCP-Server

Das Web-Dashboard ist nicht der einzige Zugang. Alles, was es tut, läuft über unsere öffentliche REST API und unseren Remote-MCP-Server unter https://nameocean.net/mcp, und das nameocean-CLI baut darauf auf.

Das nameocean-CLI

nameocean ist ein einzelnes statisches Binary, geschrieben in Go und gebaut für macOS, Linux und Windows, jeweils für amd64 und arm64. Wir haben uns hier aus dem umgekehrten Grund für Go entschieden, aus dem wir für den Server Python gewählt haben: Ein CLI muss sich in Sekunden installieren lassen und ohne Runtime überall laufen – und Go kompiliert zu einer einzigen Datei, die genau das leistet.

• Einmal anmelden. nameocean login öffnet den Browser und meldet Sie per OAuth 2.1 mit PKCE an. Tokens werden im Schlüsselbund des Betriebssystems gespeichert (macOS Keychain, Windows Credential Manager oder libsecret unter Linux) und automatisch erneuert. Auf Servern und in CI funktioniert stattdessen ein API-Schlüssel aus dem Dashboard.
• Server und Ports. nameocean servers ls, servers info für SSH- und git-Details sowie ports open / ports close, um einen Port Ihres Containers freizugeben.
• Domains auf Servern. nameocean bind example.com <server> richtet DNS, SSL und Load Balancer mit einem einzigen Befehl ein.
• DNS und SSL. dns ls, dns add und dns rm für A-, CNAME-, MX-, TXT- und weitere Einträge, dazu ssl status und ssl issue --wait.
• Domains. domains ls und domains check für Verfügbarkeit und Preis. Das CLI gibt niemals Geld aus: Registrierungen und Verlängerungen bleiben im Dashboard.
• Gemacht für Skripte und KI-Agenten. Jeder Befehl akzeptiert --json und gibt das JSON der API unverändert aus, sodass es sich direkt an jq, Shell-Skripte oder einen Agenten weiterreichen lässt.
• Ein Befehl für KI-Clients. nameocean mcp install findet Claude Code, Cursor und OpenCode auf Ihrem Rechner und fügt jedem davon den NameOcean-MCP-Server hinzu.

nameocean login
nameocean dns add example.com A @ 203.0.113.10 --ttl 5m
nameocean bind example.com 3f9a1c2e
nameocean servers ls --json | jq '.servers[].default_domain'

Installieren Sie es per Homebrew (brew install nameocean/tap/nameocean) oder laden Sie ein Archiv für Ihre Plattform herunter.

Der Remote-MCP-Server

Beim Vibe Hosting kommuniziert Ihr KI-Assistent direkt mit NameOcean. Ein Befehl verbindet Claude Code: claude mcp add --transport http nameocean https://nameocean.net/mcp. Sie melden sich einmal im Browser an und können ihn von da an bitten, ein Deployment durchzuführen, einen Port zu öffnen oder eine Domain auf Ihren Server zu richten – ohne eine Konfigurationsdatei anzufassen. Cursor, Claude Desktop, claude.ai und andere MCP-Clients verbinden sich mit derselben URL; wie das geht, zeigt die MCP-Dokumentation. Auf Ihrem Rechner läuft nichts, es gibt also nichts zu installieren oder zu aktualisieren.

Früher haben wir dafür eine Desktop-App angeboten. Sie startete einen lokalen MCP-Server und meldete sich mit einem Passwort an, was bei Zwei-Schritt-Anmeldung nicht möglich ist. Da der Remote-Server dieselbe Aufgabe ganz ohne Installation erledigt, haben wir die App im November 2026 eingestellt.

Warum beides?

Verschiedene Menschen arbeiten an verschiedenen Orten. Das CLI richtet sich an Entwickler, die im Terminal zu Hause sind und skriptfähige, reproduzierbare Befehle möchten. Der MCP-Server ist für alle, die lieber beschreiben, was sie wollen, und den Rest ihrem KI-Assistenten überlassen. Da beide nur dünne Schichten über derselben API sind, erreicht eine neue Funktion in der Django-App gleichzeitig das Web-Dashboard, das CLI und jeden MCP-Client.

Monitoring und Deployments

Jeder Fehler in der Produktion wird an einen selbst gehosteten, Sentry-kompatiblen Error-Tracker gemeldet. Uptime-Checks überwachen jeden Webserver, und Metriken fließen in eine Zeitreihendatenbank. Deployments sind bewusst langweilig: Wir pushen nach git, führen einen Fabric-Befehl aus, und dieser aktualisiert jeden Webserver, installiert die Abhängigkeiten, führt Migrationen aus, sammelt statische Dateien, kompiliert die Übersetzungen und startet die App neu. Hat ein Server veralteten Code, ist die Lösung ein weiteres Deployment – niemals eine manuelle Änderung.

Zusammenfassung

• Python und Django für lesbare Geschäftslogik, den Admin, i18n und eine einheitliche Sprache überall.
• PostgreSQL als einzige zentrale Datenquelle, mit Point-in-Time-Recovery.
• Redis als Cache und als Backend der RQ-Job-Queue.
• RQ für einfache Hintergrundjobs, Dramatiq auf RabbitMQ für aufwendige Pipelines, bei denen nichts verloren gehen darf.
• Proxmox-LXC-Container für schnelles, isoliertes und günstiges Hosting.
• Das nameocean-CLI (Go) und der Remote-MCP-Server als dünne Schichten über derselben API.

Neugierig, was hinter einer anderen Website steckt? Prüfen Sie sie mit unserem Website Technology Checker. Bereit, Ihr eigenes Projekt zu starten? Finden Sie eine Domain und bringen Sie sie auf NameOcean Hosting.