Schnellstart

Von null zur laufenden Installation in 15 Minuten: Server deployen, Admin-Panel öffnen, erste VPS anbinden.

Kein Programmieren nötig — alles passiert im Browser und im SSH-Terminal.

Bevor du beginnst

Was du brauchst

Voraussetzung	Hinweis
Cloudflare-Konto	Kostenlose Registrierung genügt; R2 muss aktiviert sein (siehe Hinweis unten)
GitHub-Konto	Der Ein-Klick-Deploy kopiert den Code in dein Repository und steuert spätere Updates
Eine VPS	Linux (Debian/Ubuntu/CentOS und Verwandte), mit root oder sudo
15 Minuten	Deploy + Build dauern etwa 5–10 Minuten, eine Node anzubinden 1–2 Minuten

Was du bekommst

• Eine eigene öffentliche Statusseite und ein Admin-Panel;
• Live-Metriken, Online-Status, TCP-Pings und Proxy-Verfügbarkeit für eine oder viele VPS;
• Automatische Updates: Nodes aktualisieren sich selbst, der Server folgt dem offiziellen Stable-Release nach Plan.

Acht Begriffe, die dir begegnen (nichts zum Auswendiglernen)

Begriff	Erklärung in einem Satz
Worker	Das Serverprogramm auf Cloudflare: APIs, Probe-Planung und Seiten
D1	Die Cloudflare-Datenbank: Konfiguration, aktueller Zustand und SLA-Aggregate
R2	Cloudflare-Objektspeicher: hochfrequente Historie und Archive (zuerst aktivieren)
Durable Objects (DO)	Zustandsbehaftete Cloudflare-Bausteine für Echtzeit-Puffer und Status-Streams
Agent	Das Probe-Programm auf deiner VPS (eine Rust-Binary), das Metriken meldet
Manager	Begleitprozess des Agents für Root-Aufgaben und automatische Updates
Target	Das überwachte Objekt: eine VPS, eine Website oder ein Proxy-Endpunkt
Latency-Node	Messknoten an einem anderen Netzwerkstandort für regionale Latenzen

1. Server deployen (Ein-Klick)

Öffne die README des öffentlichen Repositories, klicke auf Deploy to Cloudflare, autorisiere GitHub und Cloudflare und fülle aus:

Variable	Inhalt
ADMIN_USERNAME	Admin-Benutzername, frei wählbar
ADMIN_PASSWORD	Mindestens 9 Zeichen mit Groß-/Kleinschreibung, Ziffern und Sonderzeichen
ADMIN_PATH	Pfad zum Admin-Bereich, z. B. admin
TOTP_ENCRYPTION_KEY	Unabhängiger Zufallswert mit mindestens 32 Zeichen, dauerhaft unverändert

Hier bleiben die meisten hängen: Ein neues Konto muss R2 zuerst im Cloudflare-Dashboard aktivieren (kostenlos: 10 GB Speicher, 1 Mio. Klasse-A- und 10 Mio. Klasse-B-Operationen pro Monat; auch im Gratis-Tarif ist ein R2-Abo mit Zahlungsmethode nötig), sonst stoppt der Deploy bei „uses R2, which is available with an R2 subscription". D1 und der R2-Bucket werden automatisch erstellt und gebunden.

Nach dem Build:

1. Öffne die Worker-URL und besuche WORKER-URL + Admin-Pfad zum Anmelden (kein Agent-Token nötig).
2. Jedes VPS-Token entsteht, wenn das Admin-Panel erstmals einen Installationsbefehl erzeugt.

*.workers.dev zeigt Not Found? Das ist Absicht: workers.dev ist ein paralleler Einstieg, der Limits und Schutz deiner eigenen Domain umgehen würde. Ohne eigene Domain setze die Textvariable ALLOW_WORKERS_DEV = true unter Settings → Variables and Secrets und deploye neu; nach dem Binden einer Domain wieder entfernen. Die öffentliche Statusseite liegt unter /, der Admin-Einstieg ist dein ADMIN_PATH.

Wenn dieser Schritt fertig ist: Das Admin-Panel lässt dich einloggen, die öffentliche Seite lädt, und /api/health liefert ok: true (Befehle im nächsten Abschnitt).

Variante B: Kommandozeile (optional)

Für eigene Domain, CI oder lokale Vorschau:

git clone https://github.com/3257085208/NIE-SLA.git nie-sla && cd nie-sla
npm install
npx wrangler d1 create nie-sla-db           # database_id aus der Ausgabe in wrangler.jsonc eintragen
npx wrangler r2 bucket create nie-sla-archive
npx wrangler secret put ADMIN_USERNAME      # dann ADMIN_PASSWORD / ADMIN_PATH / TOTP_ENCRYPTION_KEY / INTERNAL_CRON_SECRET
npm run build                               # lädt die in update-manifest.json fixierten Assets nach dist-one-click
npm run deploy

Manuelle/CLI-Deployments müssen INTERNAL_CRON_SECRET selbst setzen (32+ Zufallszeichen): interne Durable-Object-Aufrufe schlagen ohne es mit 401 fehl und Agent-Telemetrie fällt sofort aus. Der Ein-Klick-Deploy erzeugt und injiziert das Secret während des Cloudflare-Builds.

Eigene Domain: Cloudflare Dashboard → Workers & Pages → dein Worker → Settings → Domains & Routes → Add custom domain; danach im Admin-Panel unter „Settings → Agent" die Agent-Domain setzen.

2. Prüfung nach dem Deploy (30 Sekunden)

curl -fsSL https://DEINE-DOMAIN/api/health      # erwartet: {"ok":true,...}
curl -fsSL https://DEINE-DOMAIN/bin/VERSION     # erwartet: aktuelle Version, z. B. v1.1.93
curl -fsSL https://DEINE-DOMAIN/bin/SHA256SUMS  # erwartet: Prüfsummen je Architektur

Dann drei Dinge prüfen:

• Admin-Panel meldet sich unter dem richtigen Pfad an;
• öffentliche Seite rendert;
• im Cloudflare-Dashboard läuft jede Minute ein Cron (Workers → dein Worker → Logs / Cron Events).

3. Erste VPS anbinden

1. Im Admin-Panel „Probes" öffnen und ein TCP/VPS-Target mit Namen anlegen und speichern.
2. Auf dem Target Deploy Agent klicken und den erzeugten Befehl kopieren.
3. Den Befehl als root auf der VPS ausführen.

Der Befehl enthält ein Token nur für diese Node: niemals den Befehl einer VPS auf einer anderen verwenden.

Der Installer erkennt die Architektur, prüft Manifest und Binary, verifiziert die Version und installiert einen systemd- oder OpenRC-Dienst.

Wenn dieser Schritt fertig ist: Innerhalb weniger Minuten zeigt das Target Agent online samt Version.

Der Telemetrie-Dienst läuft als unprivilegierter Benutzer; seit 1.0.44 wird kein ICMP mehr genutzt, weder Unit noch Binary brauchen CAP_NET_RAW. Alte icmp://-Zeilen bleiben sichtbar, damit du sie löschen kannst, werden aber nicht mehr an Agents gesendet.

Auf der VPS zur Fehlersuche:

sudo cftz status     # Dienststatus
sudo cftz log 100    # letzte 100 Logzeilen

4. Probes und Alarme konfigurieren

• Nach dem Anlegen eines TCP-Targets mit öffentlicher Adresse probt Cloudflare es regelmäßig; für IPv6-only-Nodes siehe IPv6 und Cloudflare-Probing (oder das passende Thema in deiner Sprache).
• Im Ping-Feld bedeutet host:port oder tcp://host:port TCP, http:///https:// eine HTTP-Probe des Agents. Standardintervall 20 Sekunden (Bereich 5-300); alte gespeicherte 1-Sekunden-Werte fallen auf 20 zurück.
• NodeQuality bietet HardwareQuality (y/f/v/n), IPQuality (y/n), NetQuality (y/l/n) und Backroute (y/n); Ergebnisse folgen dem offiziellen NodeQuality-Bericht.
• Unter „Settings → Alerts" Telegram oder E-Mail einrichten und zuerst eine Testnachricht senden, bevor Regeln aktiviert werden.
• Für Latenzen aus anderen Netzwerken eine External-Latency-Node hinzufügen und ihren Installationsbefehl ausführen.

5. Online-Updates

Das Ein-Klick-Repository prüft alle 6 Stunden das offizielle Stable-Release. Updates behalten deine wrangler.jsonc, durchlaufen Sicherheitsscan, Anwendungstests und einen Wrangler-Dry-Run, bevor sie committen.

Sofort aktualisieren: Deployment-Repository öffnen → Actions → NIE-SLA Online Update → Run workflow, keine Eingaben nötig.

„Settings → System update" im Admin-Panel zeigt aktuelle Version, neueste Version und Changelog.

Bei 429, 5xx oder Timeout des offiziellen Manifests nutzt der Workflow einen Sechs-Stunden-Cache oder das mitgelieferte vertrauenswürdige Manifest. „Official source limited, using the current deployment/cached result" ist eine erfolgreiche Degradierung, kein Ausfall — kein hektisches Neuladen nötig.

Nodes (Agents) haben einen eigenen Kanal: Selbst wenn die Serverversion zurückliegt, folgen Nodes dem offiziellen Release-Kanal und aktualisieren sich ohne Handarbeit.

6. Öffentliche API prüfen

curl -fsSL https://DEINE-API/api/v1
curl -fsSL 'https://DEINE-API/api/v1/status?days=30&lite=1'

Die erste Antwort enthält api_version: "v1", stability: "stable" und die Endpunktliste; die zweite liefert öffentliche Targets. Kein Token nötig; Browser-Cross-Origin-Aufrufe brauchen DEVELOPER_API_ORIGINS.

Häufige Stolpersteine

Symptom	Ursache und Lösung
Deploy stoppt bei „available with an R2 subscription"	R2 nicht aktiviert: Cloudflare-Dashboard → R2 → aktivieren (Zahlungsmethode nötig; Gratis-Tarif gilt trotzdem)
*.workers.dev liefert Not Found	Absichtliche Härtung; Übergangslösung über ALLOW_WORKERS_DEV in Abschnitt 1
Agent wird nie online	Auf der VPS sudo cftz status / sudo cftz log 100; prüfen, ob der Befehl zu dieser Maschine gehört
Keine Cron-Läufe	Prüfen, ob der Worker deployed wurde; einmal neu deployen und Logs ansehen
Updates laufen nie	Repository-Actions deaktiviert oder Workflow fehlt: siehe FAQ „The panel shows a new version but nothing ever updates"
NodeQuality-Bilder laden nicht	Thema NQ-Bilder / Image-Host / Same-Origin-Proxy, passender FAQ-Eintrag
Passwort vergessen	Das beim Deploy gesetzte ADMIN_PASSWORD verwenden; Änderung siehe FAQ

Checkliste vor dem Livegang

• Admin-Konto meldet sich an, Passwort wird nirgends wiederverwendet.
• Falls TOTP aktiv ist: Wiederherstellungsmaterial sicher verwahrt.
• Öffentliche Seite und Admin-Einstieg funktionieren.
• Die VPS zeigt Agent online mit Version.
• Die öffentliche Seite verrät keine privaten IPs, Ports oder URL-Zugangsdaten.
• Mindestens eine Telegram- oder E-Mail-Testnachricht ist angekommen.
• Cloudflare Cron, D1, R2 und Durable Objects zeigen keine anhaltenden Fehler.

Nächste Schritte

• Zusammenspiel und Datenfluss verstehen: Architektur.
• Frontend ersetzen oder integrieren: Öffentliche API und Integration.
• Themes bauen oder Quellcode ändern: Theme-System und Entwicklung.
• Hängengeblieben: zuerst die FAQ, dann Fehlerbehandlung.
• Wie viele Maschinen der Cloudflare-Gratis-Tarif trägt: Nutzungsmodell (rund 122 mit Standardwerten; höchstens 106 empfohlen).