Node64: Das Rad neu erfunden. Jetzt mit Webinterface.

Manchmal sieht man ein neues Projekt und denkt:

Ah. Dafür gab es wirklich noch keine gute Lösung.

Und dann sieht man Node64.

DNS.

Reverse Proxy.

Monitoring.

DynDNS.

Honeypot.

Statusseiten.

Docker-Monitoring.

Proxmox-Monitoring.

Zertifikate.

Alles in einem Container.

Alles in einem Go-Binary.

Eine SQLite-Datenbank.

Eine Weboberfläche.

Und dazu der große Satz:

„Dein Homelab. Überwacht, geschützt, erreichbar.“

Okay.

Nur eine kleine Frage:

Warum?

Nein, ernsthaft.

Warum sollte ich meinen DNS-Resolver, meinen Reverse Proxy, mein Monitoring, meinen DynDNS-Updater und einen Honeypot unbedingt in denselben Prozess stopfen?

Was ist die technische Grundlage dafür?

Welche gemeinsame Aufgabe haben diese Dinge außer:

„Hat halt irgendwas mit Netzwerk zu tun.“

Mein Kühlschrank und mein Router hängen auch im selben LAN.

Deshalb schraube ich sie trotzdem nicht zusammen und nenne es Infrastrukturplattform.

Node64 beschreibt die eigenen Funktionen sogar ganz offen als Alternativen zu bereits bekannten Werkzeugen.

Healthchecks statt Uptime Kuma.

DNS.

Proxy.

DynDNS.

Honeypot.

Also haben wir hier kein neues Problem.

Keinen neuen Ansatz für eine bisher ungelöste Aufgabe.

Keinen technischen Durchbruch.

Wir haben:

Dinge, die es längst gibt.

Nur jetzt in einer Kiste.

Und genau da fängt es an, mich zu nerven.

Denn „alles in einem“ wird gern automatisch als Vorteil verkauft.

Ist es aber nicht.

Manchmal ist „alles in einem“ einfach nur:

Alles fällt gemeinsam um.

Ein Binary.

Ein Container.

Ein gemeinsamer Update-Zyklus.

Eine gemeinsame Oberfläche.

Eine gemeinsame Datenbank.

Ein gemeinsamer Fehlerbereich.

Herrlich übersichtlich.

Bis irgendwas brennt.

Dann ist die große Schaltzentrale plötzlich auch die große gemeinsame Baustelle.

Das wird dann als Vorteil verkauft:

„Ein Container, ein Binary.“

Ja.

Ich könnte auch Sicherungskasten, Router, NAS und Kaffeemaschine in einen Schrank bauen.

Dann habe ich nur noch einen Schrank.

Fortschritt.

Das eigentliche Problem heißt Blast Radius.

Wenn mein Monitoring spinnt, möchte ich nicht darüber nachdenken, ob dieselbe Software gerade auch mein DNS beantwortet.

Wenn mein Reverse Proxy nach einem Update Probleme macht, hätte ich ganz gern, dass mein Resolver davon ungefähr so viel mitbekommt wie meine Waschmaschine.

Nämlich gar nichts.

Und wenn in einer zentralen Oberfläche eine Sicherheitslücke auftaucht, die Zugriff auf mehrere Infrastrukturrollen verwaltet, dann wird aus:

„Alles schön zentral“

sehr schnell:

„Alles schön gleichzeitig.“

Das heißt nicht, dass Node64 automatisch unsicher ist.

Natürlich nicht.

Aber man koppelt Dinge, die technisch überhaupt nicht gekoppelt sein müssen und sollten.

Und dafür hätte ich gern einen verdammt guten Grund.

„Dann brauche ich weniger Container“ ist keiner.

Wir reden über Homelabs.

Nicht über Menschen, die beim Anblick einer YAML-Datei den Rettungsdienst rufen.

Uptime Kuma starten.

Caddy starten.

Pi-hole oder AdGuard Home starten.

CrowdSec starten.

Fertig.

Ja.

Mehrere Container.

Tragisch.

Vielleicht richtet die Bundesregierung einen Härtefallfonds ein.

Denn genau dafür gibt es Container doch.

Dienste trennen.

Abhängigkeiten kapseln.

Komponenten unabhängig aktualisieren.

Eine Sache austauschen, ohne den Rest mitzunehmen.

Node64 schaut sich dieses ziemlich vernünftige Prinzip an und sagt:

Wisst ihr, was Docker wirklich fehlt?

Ein Monolith.

Natürlich lassen sich Module abschalten.

Das macht aus einem gemeinsamen Binary trotzdem keine saubere Trennung.

Das Deployment bleibt gemeinsam.

Das Update bleibt gemeinsam.

Die Oberfläche bleibt gemeinsam.

Die Fehler landen im selben Produkt.

Wenn DNS64 ein Update braucht, bekommt eben auch PROXY64 denselben neuen Stand.

Wenn beim Proxy etwas schiefgeht, hoffe ich einfach mal, dass der Rest dabei keine neuen Hobbys entwickelt.

Praktisch.

Also für niemanden.

Beim Honeypot wird es ebenfalls nicht revolutionärer.

Honeypots gibt es.

Loganalyse gibt es.

Gemeinschaftliche Blocklisten gibt es.

CrowdSec existiert nicht erst seit gestern.

Und wenn Node64 am Ende parallel zu CrowdSec dieselben Logs liest, dann ist das nicht:

„Endlich weniger Komplexität.“

Das ist:

„Jetzt habe ich zwei Programme, die denselben Kram beobachten.“

Auch DNS wird nicht plötzlich neu erfunden.

Blocklisten.

Lokale Einträge.

DoH.

DoT.

DoQ.

Gruppen.

Upstreams.

Cache.

Alles ordentlich.

Alles nützlich.

Und alles ungefähr die Sorte Funktionsliste, wegen der andere seit Jahren Pi-hole, AdGuard Home, Unbound und Co. einsetzen.

Beim Reverse Proxy dasselbe.

HTTPS.

Zertifikate.

Hosts.

Streams.

Access Lists.

Schön.

Nur:

Reverse Proxies existieren.

Sehr gute sogar.

Und die haben einen ziemlich unfairen Vorteil:

Sie müssen nicht gleichzeitig noch DNS, Monitoring, DynDNS und Honeypot spielen.

Caddy muss ein guter Proxy sein.

Pi-hole muss DNS filtern.

Uptime Kuma muss überwachen.

CrowdSec muss verdächtigen Mist erkennen.

Node64 muss:

ja.

Und irgendwann kommt zwangsläufig die Frage:

Warum?

Warum sollte ich spezialisierte Werkzeuge durch einen jungen Alles-Könner ersetzen?

Damit Portainer fünf Zeilen weniger anzeigt?

Damit mein Dashboard hübscher aussieht?

Damit ich beim nächsten Problem nicht mehr weiß, welches Modul eigentlich Schuld ist?

Aber dann kommt IPv64.

Und da wird es angeblich plötzlich sinnvoll.

Node64 kann lokale Checks mit externen IPv64-Checks verzahnen.

CDN64-Tunnel nutzen.

Dienste hinter DS-Lite oder CGNAT erreichbar machen.

DynDNS und DNS-Verwaltung mit dem IPv64-Konto koppeln.

Honeypot-Daten ins eigene System zurückspielen.

Aha.

Da ist sie also, die große Existenzberechtigung.

Node64 ergibt Sinn, wenn ich möglichst viel IPv64 benutzen möchte.

Na großartig.

Das ist ungefähr so, als würde Apple erklären:

„Unser Zubehör ergibt besonders viel Sinn, wenn Sie bereits iPhone, Mac, Watch und iCloud besitzen.“

Ach was.

Das ist keine universelle technische Grundlage.

Das ist ein Ökosystem.

Und Ökosystem klingt bekanntlich viel netter als:

„Unser Zeug funktioniert am schönsten mit noch mehr von unserem Zeug.“

Dann ist Node64 eben nicht die große neue Schaltzentrale fürs Homelab.

Dann ist es vor allem der lokale Arm des IPv64-Angebots.

Ein Client, der dir das eigene Ökosystem tiefer ins Heimnetz zieht und nebenbei Funktionen mitbringt, für die du vorher eigenständige Werkzeuge hattest.

Das kann man wollen.

Aber dann bitte nennen wir es auch so.

Denn plötzlich wird aus der angeblichen Vereinfachung etwas ganz anderes.

Vorher hatte ich:

Caddy.

Uptime Kuma.

Pi-hole.

CrowdSec.

Vielleicht einen simplen DynDNS-Client.

Alles austauschbar.

Alles unabhängig.

Wenn mir Caddy nicht mehr gefällt:

raus damit.

Wenn ich Pi-hole ersetzen will:

AdGuard Home rein.

Wenn mein Monitoring nervt:

anderes Monitoring.

Das nennt sich Freiheit.

Bei Node64 lautet die Idee dagegen:

Komm rein. Wir haben alles.

Monitoring.

DNS.

Proxy.

DynDNS.

Honeypot.

Und wenn du sowieso schon hier bist:

IPv64.

Cloud Router.

CDN64.

Externe Checks.

Account.

Noch ein Dienst.

Noch eine Verbindung.

Noch ein Teil des Ökosystems.

Wie praktisch.

Man könnte fast denken, die technische Lösung passt erstaunlich gut zum eigenen Produktportfolio.

Zufall.

Bestimmt.

Und genau deshalb überzeugt mich dieses Argument noch weniger.

Wenn die stärkste Begründung für Node64 lautet:

„Es integriert sich toll mit IPv64“

dann beantwortet das nicht die Frage, warum ich Node64 brauche.

Es beantwortet nur die Frage, warum IPv64 möchte, dass ich Node64 benutze.

Das ist ein gewaltiger Unterschied.

Für jemanden, der bereits tief im IPv64-Kosmos steckt, kann das bequem sein.

Natürlich.

Für alle anderen bleibt die Frage aber weiterhin auf dem Tisch:

Warum sollte ich mir diesen Monolithen antun?

Welche technische Notwendigkeit gibt es?

Welche bestehende Lösung scheitert so grundlegend, dass ich DNS, Proxy, Monitoring und Security plötzlich in dieselbe Anwendung kippen muss?

Welche große Lücke wurde hier geschlossen?

Ich sehe keine.

Ich sehe vor allem ein bekanntes Muster:

Man nimmt bestehende Funktionen.

Baut eine Oberfläche drüber.

Verzahnt sie mit dem eigenen Dienst.

Nennt das Ganze Plattform.

Und verkauft die Integration als Innovation.

Das Rad wurde nicht neu erfunden.

Es wurde nicht einmal verbessert.

Man hat mehrere Räder aufeinandergelegt, einen Account daneben gestellt und ein Dashboard draufgeschraubt.

Jetzt heißt es Node64.