Démarrage rapide

De zéro à une installation fonctionnelle en 15 minutes : déployer le serveur, ouvrir l'administration, connecter votre premier VPS.

Aucun code à écrire — tout se passe dans le navigateur et un terminal SSH.

Avant de commencer

Ce qu'il vous faut

Élément	Remarque
Compte Cloudflare	L'inscription gratuite suffit ; R2 doit être activé (voir la note ci-dessous)
Compte GitHub	Le déploiement en un clic copie le code dans votre dépôt et pilote les mises à jour
Un VPS	Linux (Debian/Ubuntu/CentOS et similaires), avec root ou sudo
15 minutes	Déploiement + build : 5 à 10 minutes ; connexion d'un nœud : 1 à 2 minutes

Ce que vous obtenez

• Votre propre page de statut publique et un panneau d'administration ;
• Métriques en direct, état en ligne, pings TCP et disponibilité des proxys pour un ou plusieurs VPS ;
• Mises à jour automatiques : les nœuds se mettent à jour seuls, le serveur suit la version stable officielle selon un calendrier.

Huit termes que vous rencontrerez (rien à mémoriser)

Terme	Explication en une phrase
Worker	Le programme serveur sur Cloudflare : API, planification des sondes et pages
D1	La base de données Cloudflare : configuration, état courant et agrégats SLA
R2	Le stockage objet Cloudflare : historique haute fréquence et archives (à activer d'abord)
Durable Objects (DO)	Briques à état de Cloudflare pour les tampons temps réel et les flux de statut
Agent	Le programme sonde installé sur votre VPS (un binaire Rust) qui remonte les métriques
Manager	Processus compagnon de l'Agent pour les tâches root et les mises à jour automatiques
Cible	L'objet surveillé : un VPS, un site web ou un point de terminaison proxy
Nœud de latence	Un nœud de mesure dans un autre réseau, pour la latence régionale

1. Déployer le serveur (un clic)

Ouvrez le README du dépôt public, cliquez sur Deploy to Cloudflare, autorisez GitHub et Cloudflare, puis renseignez :

Variable	Contenu
ADMIN_USERNAME	Nom du compte administrateur, au choix
ADMIN_PASSWORD	Au moins 9 caractères avec majuscules/minuscules, chiffres et symboles
ADMIN_PATH	Chemin d'accès à l'administration, par exemple admin
TOTP_ENCRYPTION_KEY	Valeur aléatoire indépendante d'au moins 32 caractères, à conserver telle quelle

L'étape qui bloque le plus souvent : un nouveau compte doit d'abord activer R2 dans la console Cloudflare (offre gratuite : 10 Go de stockage, 1 M d'opérations classe A et 10 M classe B par mois ; même en gratuit, R2 exige un abonnement avec moyen de paiement), sinon le déploiement s'arrête sur « uses R2, which is available with an R2 subscription ». D1 et le bucket R2 sont créés et liés automatiquement.

Une fois le build terminé :

1. Ouvrez l'URL du Worker et allez sur URL-WORKER + chemin admin pour vous connecter (aucun jeton Agent requis).
2. Le jeton de chaque VPS est créé quand l'administration génère pour la première fois une commande d'installation.

*.workers.dev affiche Not Found ? C'est voulu : workers.dev est une entrée parallèle qui contournerait les limites et protections de votre domaine. Sans domaine personnalisé, ajoutez la variable texte ALLOW_WORKERS_DEV = true dans Settings → Variables and Secrets puis redéployez ; retirez-la après avoir lié un domaine. La page publique est sur /, l'entrée d'administration est votre ADMIN_PATH.

Quand cette étape est terminée : l'administration vous connecte, la page publique s'affiche et /api/health renvoie ok: true (commandes à la section suivante).

Variante B : ligne de commande (facultatif)

Pour un domaine personnalisé, la CI ou un aperçu local :

git clone https://github.com/3257085208/NIE-SLA.git nie-sla && cd nie-sla
npm install
npx wrangler d1 create nie-sla-db           # copier le database_id retourné dans wrangler.jsonc
npx wrangler r2 bucket create nie-sla-archive
npx wrangler secret put ADMIN_USERNAME      # puis ADMIN_PASSWORD / ADMIN_PATH / TOTP_ENCRYPTION_KEY / INTERNAL_CRON_SECRET
npm run build                               # télécharge les actifs figés par update-manifest.json dans dist-one-click
npm run deploy

Les déploiements manuels/CLI doivent définir eux-mêmes INTERNAL_CRON_SECRET (32+ caractères aléatoires) : sans lui, les appels internes aux Durable Objects échouent en 401 et la télémétrie des Agents échoue immédiatement. Le déploiement en un clic génère et injecte ce secret pendant le build Cloudflare.

Domaine personnalisé : Cloudflare Dashboard → Workers & Pages → votre Worker → Settings → Domains & Routes → Add custom domain ; puis réglez le domaine de connexion des Agents dans « Settings → Agent ».

2. Vérifications après déploiement (30 secondes)

curl -fsSL https://VOTRE-DOMAINE/api/health      # attendu : {"ok":true,...}
curl -fsSL https://VOTRE-DOMAINE/bin/VERSION     # attendu : version actuelle, ex. v1.1.93
curl -fsSL https://VOTRE-DOMAINE/bin/SHA256SUMS  # attendu : sommes de contrôle par architecture

Puis vérifiez trois choses :

• l'administration se connecte au bon chemin ;
• la page publique s'affiche ;
• la console Cloudflare montre un Cron chaque minute (Workers → votre Worker → Logs / Cron Events).

3. Connecter votre premier VPS

1. Dans l'administration, ouvrez « Probes » et ajoutez une cible TCP/VPS avec un nom, puis enregistrez.
2. Cliquez sur Deploy Agent sur cette cible et copiez la commande générée.
3. Exécutez-la sur le VPS en root.

La commande contient un jeton propre à ce nœud : ne réutilisez jamais la commande d'un VPS sur une autre machine.

L'installateur détecte l'architecture, vérifie le manifeste et le binaire, contrôle la version et installe un service systemd ou OpenRC.

Quand cette étape est terminée : en quelques minutes la cible affiche Agent en ligne avec sa version.

Le service de télémétrie tourne sous un utilisateur non privilégié ; depuis 1.0.44 ICMP n'est plus utilisé, ni l'unité systemd ni le binaire n'ont besoin de CAP_NET_RAW. Les anciennes lignes icmp:// restent visibles pour être supprimées, mais ne sont plus envoyées aux Agents.

Sur le VPS, pour diagnostiquer :

sudo cftz status     # état du service
sudo cftz log 100    # 100 dernières lignes de journal

4. Configurer les sondes et les alertes

• Après ajout d'une cible TCP avec adresse publique, Cloudflare la sonde régulièrement ; pour les nœuds IPv6-only, voir IPv6 et sondage Cloudflare (ou le sujet correspondant dans votre langue).
• Dans le champ Ping, host:port ou tcp://host:port signifie TCP, http:///https:// une sonde HTTP côté Agent. Intervalle par défaut : 20 secondes (plage 5-300) ; les anciennes valeurs de 1 seconde reviennent à 20.
• NodeQuality propose HardwareQuality (y/f/v/n), IPQuality (y/n), NetQuality (y/l/n) et le backroute (y/n) ; les résultats suivent le rapport officiel NodeQuality.
• Configurez Telegram ou l'e-mail dans « Settings → Alerts » et envoyez d'abord une notification de test avant d'activer des règles.
• Pour mesurer la latence depuis d'autres réseaux, ajoutez un nœud External Latency et exécutez sa commande d'installation.

5. Mises à jour en ligne

Le dépôt du déploiement en un clic vérifie la version stable officielle toutes les 6 heures. Les mises à jour conservent votre wrangler.jsonc, passent le scan de sécurité, les tests applicatifs et un dry-run Wrangler avant de committer.

Mettre à jour immédiatement : ouvrez le dépôt → Actions → NIE-SLA Online Update → Run workflow, aucune saisie requise.

« Settings → System update » affiche la version actuelle, la dernière version et le journal des modifications.

Si le manifeste officiel renvoie 429, 5xx ou expire, le workflow utilise un cache de six heures ou le manifeste de confiance embarqué. « Official source limited, using the current deployment/cached result » est une dégradation réussie, pas une panne — inutile de rafraîchir en boucle.

Les nœuds (Agents) ont leur propre canal : même si la version serveur retarde, les nœuds suivent le canal de publication officiel et se mettent à jour sans intervention.

6. Vérifier l'API publique

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

La première réponse contient api_version: "v1", stability: "stable" et la liste des points d'accès ; la seconde renvoie les cibles publiques. Aucun jeton requis ; les appels cross-origin navigateur nécessitent DEVELOPER_API_ORIGINS.

Pièges fréquents

Symptôme	Cause et solution
Le déploiement s'arrête sur « available with an R2 subscription »	R2 non activé : console Cloudflare → R2 → activer (moyen de paiement requis ; l'offre gratuite s'applique quand même)
*.workers.dev renvoie Not Found	Durcissement volontaire ; solution temporaire via ALLOW_WORKERS_DEV (section 1)
L'Agent ne passe jamais en ligne	Sur le VPS : sudo cftz status / sudo cftz log 100 ; vérifiez que la commande appartient bien à cette machine
Aucun passage de Cron	Vérifiez que le Worker est déployé ; redéployez et observez les journaux
Les mises à jour ne partent jamais	Actions du dépôt désactivées ou workflow absent : voir la FAQ « The panel shows a new version but nothing ever updates »
Les images du rapport NodeQuality ne chargent pas	Sujet images NQ / hébergeur d'images / proxy same-origin, entrée FAQ correspondante
Mot de passe oublié	Utilisez l'ADMIN_PASSWORD défini au déploiement ; voir la FAQ pour le changer

Liste de contrôle avant mise en production

• Le compte administrateur se connecte et son mot de passe n'est pas réutilisé ailleurs.
• Si TOTP est activé, les codes de secours sont conservés en lieu sûr.
• La page publique et l'entrée d'administration fonctionnent.
• Le VPS affiche Agent en ligne avec une version.
• La page publique n'expose ni IP privées, ni ports, ni identifiants d'URL.
• Au moins une notification de test Telegram ou e-mail est arrivée.
• Cloudflare Cron, D1, R2 et Durable Objects ne montrent aucune erreur persistante.

Étapes suivantes

• Comprendre l'assemblage et les flux de données : Architecture.
• Remplacer le frontend ou intégrer : API publique et Intégration.
• Créer des thèmes ou modifier le code : Système de thèmes et Développement.
• Bloqué : consultez d'abord la FAQ, puis Gestion des erreurs.
• Combien de machines l'offre gratuite Cloudflare supporte : Modèle d'usage (environ 122 par défaut ; restez à 106 maximum).