Einleitung: Vom Flickenteppich zur Schaltzentrale
Wer ein Homelab betreibt, kennt das Problem: Für jede Aufgabe gibt es ein eigenes Tool. Pi-hole oder AdGuard Home für DNS-Filterung, Nginx Proxy Manager für Reverse Proxying und Let’s Encrypt, Cloudflare Tunnel für den Zugriff von außen ohne Portfreigabe, Uptime Kuma für Health Checks, DynDNS-Skripte für die Aktualisierung der IP-Adresse und dann noch irgendeine Honeypot-Lösung für die Sicherheit. Jedes dieser Tools hat seine eigene Weboberfläche, seine eigene Datenbank, seine eigenen Updates und seine eigenen Backup-Routinen. Die Verwaltung wird zum Vollzeitjob – und die Komplexität wächst mit jedem Dienst, der hinzukommt.
Genau hier setzt Node64 an. Es ist ein All-in-One-Container, der diese vielfältigen Funktionen unter einem Dach vereint – entwickelt vom IPv64.net-Team um Dennis Schröder. Statt sechs verschiedene Dienste zu pflegen, startet man einen einzigen Docker-Container und schaltet die Module ein, die man tatsächlich benötigt. Das Versprechen: „One container instead of many“ – eine Oberfläche, ein Login, ein Backup.
Ich nutze ipv64.net schon seit Jahren als DynDNS-Dienst für meinen Heimanschluss. Der Dienst war für mich lange Zeit eine reine Notwendigkeit: Der Router meldet bei jedem IP-Wechsel die aktuelle Adresse an ipv64.net, und von dort aus erreichen meine Dienste den Anschluss unter einem festen Namen. Das funktioniert zuverlässig und kostenlos – aber mehr als ein technisches Hilfsmittel war es für mich nicht. Ich hatte mich damit abgefunden, dass für jede weitere Funktion ein separates Tool herhalten muss.
Dann bin ich durch einen Artikel auf node64.de aufmerksam geworden. Die Seite beschreibt den Container als „Schaltzentrale für dein Heimnetz“ – Healthchecks, Reverse Proxy, CDN-Tunnel, DNS-Filter, DynDNS und Honeypot in einem einzigen Docker-Container, alles lokal betreibbar und optional mit dem ipv64.net-Konto verknüpft. Was mich sofort angesprochen hat: Das war kein weiteres Einzeltool, sondern eine Konsolidierung genau der Funktionen, die ich mir über die Jahre mühsam zusammengestückelt hatte. Und weil ich bereits einen ipv64.net-Account besaß, war die Hürde, es auszuprobieren, denkbar niedrig. Dieser Artikel beschreibt, was Node64 leistet, wie die Installation abläuft, warum ich meine Subdomains umgezogen habe – und welche sicherheitspolitische Dimension diese Entscheidung hat.
Was ist Node64?
Node64 versteht sich als Schaltzentrale für das Heimnetz – als „Homelab-Cockpit“, das Überwachung, Schutz und Erreichbarkeit in einer einzigen Anwendung bündelt. Der Ansatz ist „Local First“ : Alle Daten – Datenbank, Messungen, Logs und Schlüssel – liegen auf der eigenen Node. Selbst ohne Internetverbindung läuft Node64 vollständig weiter. Geheimnisse wie Tokens werden verschlüsselt in der lokalen Datenbank gespeichert.
Optional lässt sich Node64 mit einem kostenlosen ipv64.net-Konto verknüpfen. Dann kommen externe Health Checks, die CDN64-Infrastruktur mit Edge-Servern in Nürnberg und Falkenstein sowie die community-basierte v64-Blocklist hinzu. Doch auch ohne Konto ist der Container voll funktionsfähig.
Technisch läuft Node64 als Docker-Container auf nahezu jeder Plattform: Linux, NAS-Systeme (Synology, UGREEN, TrueNAS), Proxmox, Raspberry Pi und andere ARM-Geräte. Die Images stehen für linux/amd64, arm64 und arm/v7 bereit.
Die Module im Detail
Node64 besteht aus mehreren Modulen, die unabhängig voneinander aktiviert werden können – aber miteinander kommunizieren und sich gegenseitig ergänzen.
PROXY64 – Reverse Proxy mit Let’s Encrypt
PROXY64 ist der Reverse Proxy des Containers und positioniert sich als Alternative zum Nginx Proxy Manager – ohne nginx. Er beherrscht HTTP/3, Zugriffslisten, Länderblockierung und die Integration der ipv64-Blocklisten. Let’s-Encrypt-Zertifikate werden zentral verwaltet und automatisch erneuert, wahlweise per HTTP- oder DNS-Challenge über 26 DNS-Provider. Wildcard-Zertifikate per DNS-01 sind ebenfalls möglich – und funktionieren sogar, ohne dass der Anschluss von außen erreichbar sein muss.
CDN64 – Dienste veröffentlichen ohne Portfreigabe
CDN64 löst ein klassisches Homelab-Problem: die Erreichbarkeit von Diensten von außen, ohne die Heim-IP preiszugeben oder Ports im Router zu öffnen. Der Dienst baut einen ausgehenden, verschlüsselten Tunnel zu den Edge-Servern von ipv64.net auf – das funktioniert selbst hinter DS-Lite und CGNAT. Es gibt mehrere Modi: Modus 1 hält TLS Ende-zu-Ende aufrecht, Modus 2 terminiert TLS an den Edge-Servern. Zusätzlich bietet CDN64 einen Port-Mapper für rohe TCP- und UDP-Ports (SSH, WireGuard, Gameserver) sowie eine Notbremse, die einen Namen sofort pausieren kann.
DNS64 – Netzwerkweiter DNS-Filter
DNS64 blockiert Werbung, Tracker und Malware für jedes Gerät im Netzwerk. Gerätegruppen können eigene Regeln erhalten, eigene DNS-Einträge, Zonen, lokale Namen und Forwarder sind inklusive. Die verschlüsselte Auflösung erfolgt über DoH (DNS over HTTPS), DoT (DNS over TLS) und DoQ (DNS over QUIC) – sowohl von den Endgeräten zur Node64-Instanz als auch von dort zu den Upstreams.
Honeypot64 – Angreifer identifizieren und blocken
Honeypot64 stellt Köder für SSH, Web, Mail, Datenbanken und weitere Dienste bereit. Wer in die Falle tappt, wird – sofern man das möchte – an ipv64.net gemeldet. Der entscheidende Mechanismus: Erst wenn mehrere unabhängige Konten dieselbe IP-Adresse sehen, landet sie auf der v64-Blocklist und wird für alle Nutzer blockiert. Das reduziert Fehlalarme und macht die Blocklist zu einem kollektiven Schutzmechanismus. Das Modul ist extrem ressourcenschonend: 30–50 MB RAM genügen, selbst auf einem Raspberry Pi.
Weitere Module (Auswahl)
- DynDNS64: Hält ipv64.net-Domains automatisch auf dem neuesten Stand (IPv4 und IPv6), inklusive Historie und Alarm bei IP-Wechsel.
- Health Checks & Statusseiten: Überwacht Websites, Server, Ports, Zertifikate, Cronjobs und Docker-Container – lokal und optional über ipv64.net von außen. Öffentliche Statusseiten mit Tagesbalken für 30, 60 oder 90 Tage sind mit wenigen Klicks erstellt.
- Monitor64: Überwacht Proxmox VE, Proxmox Backup Server, Docker, TrueNAS, Unraid und Server-BMCs (Redfish) – read-only, mit Graphen und Regeln.
- Cluster: Mehrere Nodes (z. B. Raspberry Pi, VPS, Elternhaus) synchronisieren sich verschlüsselt über HTTPS.
- Backup & Update: Verschlüsselte Backups mit eigenem Passwort, Export der Konfiguration und Reset der Node.
- Benachrichtigungen: E-Mail, Telegram, Discord, ntfy, Gotify, Pushover und Webhooks – ein Kanal für alles, mit Flap-Erkennung und Ruhezeiten.
Installation: In wenigen Schritten startklar
Die Installation von Node64 ist bewusst einfach gehalten. Die offizielle Dokumentation beschreibt den Weg „vom leeren Debian bzw. der Proxmox-VM bis zur ersten Anmeldung“ – inklusive fertiger Compose-Datei und typischer Stolpersteine.
Schritt 1: Container starten
Node64 wird als Docker-Container betrieben. Das offizielle Image ist unter ghcr.io/ipv64net/node64:latest verfügbar. Ein funktionierendes docker-compose.yml-Beispiel aus der Community zeigt die wesentlichen Parameter:
yaml
services:
node:
image: ghcr.io/ipv64net/node64:latest
container_name: node64
restart: unless-stopped
ports:
- "8081:8080" # Weboberfläche; 8080 oft belegt, daher 8081
volumes:
- node64-data:/data
environment:
NODE64_LOG_LEVEL: info
read_only: true
tmpfs:
- /tmp
sysctls:
- net.ipv4.ping_group_range=0 65535 # ICMP-Checks ohne Root
volumes:
node64-data:
Der Port 8080 ist häufig bereits durch andere Dienste belegt – im Beispiel wurde auf 8081 ausgewichen. Der Container läuft mit read_only: true und einem temporären /tmp-Verzeichnis, was die Angriffsfläche reduziert. Die sysctls-Zeile ermöglicht ICMP-Checks ohne Root-Rechte. Für NAS-Systeme mit eigenem ACL-System kann es notwendig sein, statt chown die Berechtigungsverwaltung der NAS-Oberfläche oder PUID/PGID-Mappings zu verwenden.
Schritt 2: Setup-Assistenten durchlaufen
Nach dem Start des Containers öffnet man die Weboberfläche im Browser. Ein Assistent führt durch die Ersteinrichtung: Sprache wählen, Admin-Konto anlegen. Es gibt kein Standardpasswort – ein wichtiger Sicherheitsaspekt, der Node64 von vielen anderen Homelab-Tools abhebt. Optional lassen sich Zwei-Faktor-Login, Passkeys und Single Sign-On über Authelia, Authentik oder Keycloak aktivieren.
Schritt 3: Module aktivieren
Nach der Anmeldung lassen sich die gewünschten Module unter Einstellungen → Module einschalten. Optional verknüpft man die Node mit dem eigenen ipv64.net-API-Key, um externe Health Checks, CDN64 und die v64-Blocklist freizuschalten. Die offizielle Dokumentation auf node64.de bietet eine detaillierte Schritt-für-Schritt-Anleitung – von den Docker-Grundlagen über die Proxmox-VM bis hin zu LXC-Containern mit nesting/keyctl.
Der Umzug: Warum ich alle Subdomains auf ipv64.net konsolidiert habe
Die vielleicht angenehmste Überraschung war, wie unkompliziert sich meine bestehenden Sub-Domain von olivernitsche.de in das Node64-Setup als Sub-Domain meiner DynDNS Adresse integrieren ließ. Ich betreibe unter dieser Hauptdomain mehrere Subdomains für unterschiedliche Dienste – vom NAS über diverse Weboberflächen bis hin zu Testinstanzen. Zuvor waren diese Subdomains über verschiedene DNS-Einträge und Proxy-Konfigurationen verteilt, und jedes Mal, wenn ein neuer Dienst hinzukam, bedeutete das manuellen Aufwand: DNS-Eintrag anlegen, Zertifikat beantragen, Proxy-Host konfigurieren, hoffen, dass die Erneuerung klappt.
Mit Node64 und der Anbindung an ipv64.net hat sich das grundlegend geändert. Ich konnte alle Subdomains meiner Hauptdomain auf die DynDNS-Adresse bei ipv64.net umziehen. Der entscheidende Punkt: Die Einrichtung von Subdomains inklusive SSL-Zertifikaten und Monitoring war so einfach, dass ich sie in einem Bruchteil der Zeit erledigen konnte, die ich früher für einen einzelnen Dienst gebraucht hätte. Node64 verwaltet die Let’s-Encrypt-Zertifikate zentral – wahlweise per HTTP- oder DNS-Challenge – und stellt sie für PROXY64, Statusseiten und per API auch für andere Systeme bereit. Wildcard-Zertifikate per DNS-01 sind ebenfalls möglich, und das funktioniert sogar, ohne dass der Anschluss von außen erreichbar sein muss. Das Monitoring ist direkt eingebaut: Health Checks überwachen Websites, Server, Ports und Zertifikate – lokal auf der Node und auf Wunsch zusätzlich von außen über ipv64.net. Statt also DNS, Proxy und Überwachung getrennt zu konfigurieren, fallen diese Schritte nun an einer Stelle zusammen.
Der Sicherheitsgewinn: IP verborgen, Portfreigaben geschlossen
Der eigentliche Paradigmenwechsel kam mit CDN64. Zuvor war mein Setup so, dass ich für die Erreichbarkeit von außen auf Portfreigaben im Router angewiesen war. Das ist der klassische Weg im Homelab – und ein Weg, der mir schon länger Unbehagen bereitete. Jede Portfreigabe ist wie eine angelehnte Tür zum eigenen Netz: Der Router leitet jeden Datenverkehr auf dem freigegebenen Port an das Zielgerät weiter, unabhängig davon, wer ihn sendet. Automatisierte Portscanner sind permanent aktiv und suchen im Minutentakt nach genau solchen offenen Türen.
Mit CDN64 konnte ich die beiden letzten Portfreigaben im Router schließen. Der Mechanismus dahinter: Der Node64-Container baut eine ausgehende, verschlüsselte Verbindung zu den Edge-Servern von ipv64.net in Nürnberg und Falkenstein auf – über QUIC/HTTP3 oder TLS 1.3. Es ist keine eingehende Portfreigabe nötig, weil die Verbindung vom Heimnetz aus initiiert wird. Der Datenverkehr von außen erreicht den Dienst also über die Edge-Server, nicht über eine offene Tür im heimischen Router. Gleichzeitig bleibt die IP-Adresse meines Internetanschlusses verborgen – Besucher und potenzielle Angreifer sehen nur die Infrastruktur von ipv64.net, nicht meinen Heimanschluss. Das reduziert nicht nur die direkte Angriffsfläche, sondern erschwert auch DDoS-Angriffe auf die eigene Leitung und verhindert, dass die Wohnadresse über die IP zurückverfolgt werden kann.
Digitale Unabhängigkeit: Warum die Wahl des Anbieters eine politische Dimension hat
Wer Cloudflare Tunnel nutzt, um Dienste aus dem Homelab zu veröffentlichen, trifft damit nicht nur eine technische, sondern auch eine souveränitätspolitische Entscheidung. Cloudflare ist ein US-amerikanisches Unternehmen – und das hat Konsequenzen, die weit über den bloßen Datenstandort hinausgehen. Der US CLOUD Act verpflichtet US-Firmen, Anweisungen von US-Behörden zur Herausgabe von Daten Folge zu leisten – unabhängig davon, wo auf der Welt die Server stehen. Für Cloudflare bedeutet das: Selbst wenn die Edge-Server in Frankfurt oder Nürnberg stehen und die Daten europäische Rechenzentren nie verlassen, bleibt ein Restrisiko des Zugriffs durch US-Behörden bestehen, allein aufgrund der US-Herkunft des Unternehmens.
Dieses Risiko ist kein theoretisches Konstrukt. Cloudflare verarbeitet als CDN- und Tunnel-Anbieter Metadaten in erheblichem Umfang: IP-Adressen, Request-Informationen, Zeitstempel und – je nach Konfiguration – sogar Inhaltsdaten. Wer Cloudflare Tunnel im Modus 2 betreibt, bei dem TLS an den Edge-Servern terminiert wird, vertraut Cloudflare den unverschlüsselten Datenverkehr an. Cloudflare hält dann das Zertifikat für die eigene Domain und kann den Traffic technisch im Klartext einsehen. Das ist kein Geheimnis und auch kein Missbrauch – es ist die Architektur des Dienstes. Aber es bedeutet, dass man einem US-Unternehmen genau die Daten anvertraut, die man mit dem Homelab eigentlich selbst kontrollieren wollte.
Hinzu kommt ein strukturelles Problem: Die Ausfälle der vergangenen Jahre bei AWS und Cloudflare haben immer wieder vor Augen geführt, wie sehr das Funktionieren des Netzes von einer Handvoll US-Anbieter abhängt. Ein Ausfall bei Cloudflare legt nicht nur die eigenen Dienste lahm, sondern zeigt die Verwundbarkeit einer zentralisierten Infrastruktur. Für die meisten privaten Homelab-Szenarien ist die globale Hochverfügbarkeit eines US-Hyperscalers schlicht nicht erforderlich.
Genau hier setzt die Entscheidung für ipv64.net und Node64 an. ipv64.net ist ein europäischer Anbieter mit Infrastruktur in Nürnberg und Falkenstein – und positioniert sich in seiner eigenen Kommunikation explizit als Cloudflare-Alternative, gerade weil Cloudflare ein US-Dienst ist. Wer CDN64 statt Cloudflare Tunnel nutzt, verlagert den Traffic nicht in die Hände eines US-Konzerns, sondern in die eines europäischen Anbieters, der dem europäischen Datenschutzrecht unterliegt und nicht dem CLOUD Act. Das ist kein akademischer Unterschied: Es geht darum, wer im Zweifel rechtlich verpflichtet werden kann, Daten herauszugeben – und wer nicht.
Die kritische Gegenfrage: Abhängigkeit verlagert, nicht aufgehoben
Eine ehrliche Betrachtung muss allerdings auch die neue Abhängigkeit benennen, die mit Node64 einhergeht. In der Community wird zu Recht diskutiert, dass man mit der Nutzung von Node64 und den ipv64.net-Diensten seine Abhängigkeit von US-Konzernen gegen eine Abhängigkeit von einem einzelnen europäischen Anbieter – und letztlich von einer Einzelperson, Dennis Schröder – eintauscht. Das ist ein valider Punkt. Die entscheidende Frage ist jedoch, wie diese Abhängigkeit strukturell ausgestaltet ist.
Hier zeigt sich ein wesentlicher Unterschied: Node64 ist Local First konzipiert. Alle Daten – Datenbank, Messungen, Logs, Schlüssel – liegen auf der eigenen Node. Selbst wenn ipv64.net als externer Dienst ausfiele, liefe der Container mit den lokalen Modulen weiter. Die externe Erreichbarkeit über CDN64 und die Community-Blocklist wären beeinträchtigt, aber die Kontrolle über die Daten und die Kernfunktionalität bliebe erhalten. Bei Cloudflare Tunnel hingegen ist die Erreichbarkeit der Dienste vollständig an das Funktionieren des US-Anbieters gebunden – fällt Cloudflare aus, sind die Dienste von außen nicht mehr erreichbar, selbst wenn das Heimnetz einwandfrei funktioniert. Die Abhängigkeit ist im einen Fall architektonisch abgefedert, im anderen Fall total.
Zudem ist die Wahl eines europäischen Anbieters reversibler als die Wahl eines US-Hyperscalers: Die DNS-Einträge und Tunnel-Konfigurationen lassen sich vergleichsweise einfach zu einem anderen Anbieter umziehen, während die Bindung an Cloudflares Ökosystem aus Tunnel, Zero Trust, DNS und Zertifikaten deutlich tiefgreifender ist. Digitale Souveränität ist kein binärer Zustand, sondern ein Kontinuum – und der Wechsel zu einem europäischen, lokal-first konzipierten Anbieter ist auf diesem Kontinuum ein Schritt in die richtige Richtung, auch wenn er nicht das Ende des Weges markiert.
Fazit: Konsolidierung, Sicherheit und ein Stück Souveränität
Node64 ist ein beeindruckend durchdachtes Projekt für Homelab-Betreiber, die keine Lust mehr auf den Flickenteppich aus separaten Tools haben. Es vereint DNS-Filterung, Reverse Proxying, CDN-Tunnel, DynDNS, Health Checks, Honeypot und Monitoring in einem einzigen, ressourcenschonenden Container – mit einer einheitlichen Oberfläche, zentralem Backup und durchdachten Sicherheitsfeatures wie dem Verzicht auf Standardpasswörter und der optionalen Zwei-Faktor-Authentifizierung.
Für mich persönlich war der Umstieg die lange überfällige Konsolidierung: Ich nutze ipv64.net seit Jahren für DynDNS, bin durch einen Artikel auf node64.de auf den Container aufmerksam geworden und habe daraufhin alle Subdomains meiner Hauptdomain olivernitsche.de auf die DynDNS-Adresse bei ipv64.net umgezogen. Die Einrichtung von Subdomains inklusive SSL-Zertifikaten und Monitoring war so einfach, dass sie in einem Bruchteil der Zeit erledigt war, die ich früher für einen einzelnen Dienst gebraucht hätte. Mit CDN64 konnte ich zudem die beiden letzten Portfreigaben im Router schließen – die IP meines Internetanschlusses ist nicht mehr sichtbar, und die Angriffsfläche meines Homelabs hat sich messbar reduziert.
Die Entscheidung für Node64 und ipv64.net ist damit mehr als eine technische Konsolidierung. Sie ist eine bewusste Positionierung in der Frage, wem man die Infrastruktur anvertraut, die das eigene digitale Leben trägt. Wer jahrelang ipv64.net für DynDNS genutzt hat, hat bereits eine europäische Alternative gewählt – oft ohne sich der souveränitätspolitischen Dimension bewusst zu sein. Mit dem Umzug der Subdomains, der zentralisierten Zertifikatsverwaltung und dem CDN-Tunnel wird diese Wahl nun explizit und architektonisch fundiert. Das ist keine perfekte Souveränität – die Abhängigkeit von einem einzelnen Anbieter bleibt ein legitimer Kritikpunkt –, aber es ist ein deutlich souveräneres Setup als der bequeme Weg über die US-Hyperscaler. Wer neugierig geworden ist, findet die offizielle Dokumentation und Installationsanleitung auf node64.de sowie den Community-Austausch im offiziellen Forum unter v64.tech.