Atelier auto-hébergement session 3 (Clichy, Visio & Gratuit)

Annonces
, , , ,
1

TLDR :
Pas besoin d’avoir participé à nos autres ateliers. Gratuit, format hybride : visio (atelier principal) + présentiel à La Partagerie, Clichy (pour boire un verre avec nous).
Jeudi 18 juin 2026, 18h-20h. On enchaîne en 2h : Docker, Docker Compose, CasaOS via NSL.SH (100% FOSS), connectivité avec sous-domaine + HTTPS auto, et déploiement d’une vraie app libre au choix (Vaultwarden, Immich, Nextcloud, Stirling-PDF, etc.).
Prérequis : arriver avec une machine avec Ubuntu ou Ubuntu Server accessible en SSH.
Lien visio : BigBlueButton
Inscription non obligatoire : L'Agenda du Libre | Atelier auto-hébergement session 3

Merci à celles et ceux qui sont passés à la session 1 et à la session 2 ! Petit point d’étape : la session 1 Hardware en présentiel a fait carton plein (12 participants), puis la session 2 du 16 mai en 100% visio a permis de couvrir d’un coup les modules 2, 3 et 4 en 2h. Le format a vraiment cliqué (chacun bosse dans son env final, avec ses contraintes réseau réelles), donc on le rejoue à la session 3, en hybride cette fois.

:star: Vous souhaitez héberger vous-mêmes vos données et services, uniquement avec du logiciel libre et open source ?

Quand et où
Jeudi 18 juin 2026, de 18h à 20h, format hybride :
:desktop_computer: En visio (format principal) : BigBlueButton
:beer: En présentiel à La Partagerie, 30 rue Mozart à Clichy, pour celles et ceux qui veulent nous rencontrer et boire un verre

L’atelier technique tourne en visio pour tout le monde. Le présentiel à Clichy est avant tout l’occasion de se rencontrer en vrai.

Programme en 2h (on part d’un Ubuntu opérationnel)

  • Docker et Docker Compose
  • Installation de CasaOS via la stack NSL.SH (100% FOSS)
  • Connectivité : sous-domaine perso + HTTPS automatique via NSL.SH Mesh Router
  • Déploiement d’une vraie app libre au choix : Vaultwarden, Immich, Nextcloud, Stirling-PDF, Duplicati, etc.

Objectif : repartir avec une vraie app auto-hébergée fonctionnelle, accessible depuis l’extérieur.

Prérequis
:penguin: Une machine avec Ubuntu ou Ubuntu Server accessible en SSH (VPS, Mini-PC, Raspberry Pi 4-5, laptop 64 bits…)
:computer: Un laptop pour suivre la visio
:white_check_mark: Pas besoin d’avoir participé à nos autres ateliers

La suite : continuation à la rentrée, dates et formats à venir.

Pour rappel à propos de la gouvernance de NSL.SH (question soulevée à la session 1) : projet aujourd’hui piloté par son équipe fondatrice, roadmap publique, 100% du code en open source, avec la volonté d’aller vers une gouvernance plus ouverte et une structure non lucrative. C’est aussi l’une des raisons des ateliers : rencontrer des contributeurs potentiels.

1 Like
2

Bonjour,

A des fins de transparence pour les personnes qui cherchent à s’auto-héberger avec des solutions compatibles avec la charte CHATONS. Quel est le lien entre la candidature CHATONS de Yundera qui n’a pas été retenue en Décembre dernier et les ateliers que vous proposez ici ?

Je reprends ici le commentaire de @Adrien

Yundera : plusieurs problèmes.

  1. Nous trouvons votre communication sur votre page d’accueil trompeuse, à raconter que vous proposez de l’auto-hébergement (faux, c’est vous qui hébergez) dans le respect intrinsèque de la vie privée (non, les gens vous envoient leur donnée : une relation de confiance existe et vous la démarrez pas terrible en maquillant la réalité).

Dans le cas de nsl.sh je vois un problème similaire, peut-on dire que les personnes s’auto-hébergent en « Complete Privacy with NSL » dans la mesure où les machines sont exposées via votre serveur centralisé, et qu’il ne semble pas y avoir moyen de configurer sa propre gestion DNS ?

https://nsl.sh/fr/more

Pour être transparent de mon côté, j’utilise YunoHost depuis des années et j’aimerais comprendre les problématiques d’auto-hébergement que vous cherchez à résoudre.

2 Likes
3

Bonjour @GautGaut,

Bonne question, et sur plusieurs points vous avez raison. Je vais être précis plutôt que commercial, parce que « auto-hébergement » et « privacy » recouvrent des plans qu’il faut séparer. Et comme votre message parle de « Complete Privacy with NSL », une distinction préalable s’impose : NSL et Yundera ne sont pas la même chose.

NSL.SH vs Yundera. NSL.SH est la couche libre (FOSS) : le mesh-router, le service de domaine et de routage, et la pile applicative (notre fork de CasaOS). Vous pouvez la faire tourner sur votre propre machine. C’est le chemin classique d’auto-hébergement : votre matériel, vos données sur votre métal.

Yundera est l’offre managée : on provisionne et on exploite pour vous un PCS (Personal Cloud Server, c’est un VPS dédiée sur un fourniseur d’hébérgement (dans notre cas Scaleway ou Contabo) et qui fait tourner exactement la même pile. C’est de l’hébergement infogéré, pas de l’auto-hébergement sur votre matériel; la VPS est isolée et dédiée, mais il tourne chez le fourniseur de machine.

Le modèle est open-core : NSL.SH est entièrement libre et gratuit, Yundera est la couche payante qui le finance. La même logique que pas mal des projets open source: un projet ouvert soutenu par un service managé commercial.

Plan de contrôle vs plan de données. Le plan de contrôle (résolution du domaine et vérification) passe toujours par notre backend : DNS → backend mesh-router, qui vérifie une signature libp2p → mesh-router local sur la machine → conteneur de l’app. C’est centralisé et assumé : c’est le prix de l’automatisation domaine et TLS.

Le plan de données (le trafic applicatif lui-même) ne l’est pas forcément. Deux cas : route directe via l’agent quand la machine est joignable, et là le trafic ne transite pas par notre passerelle ; ou tunnel WireGuard quand elle ne l’est pas (CGNAT, pas d’IP publique, port-forwarding impossible), et là il transite. Votre formulation « les machines sont exposées via votre serveur centralisé » est donc exacte en mode tunnel, beaucoup moins en mode direct.

Sur « Complete Privacy », votre scepticisme est justifié et je préfère être franc. Le bout-en-bout strict dépend du mode d’adressage :

Adresse sslip.io directe ({ip-publique-en-tirets}.sslip.io) : une seule session TLS, terminée sur le PCS lui-même. C’est le seul chemin réellement e2e, rien au milieu ne déchiffre.

nsl.sh managé ({sous-domaine}.{utilisateur}.nsl.sh) : un certificat sécurise le saut PCS vers l’edge NSL/Cloudflare, puis un certificat Let’s Encrypt fait face à Internet. Le TLS est re-terminé à l’edge, qui voit donc le trafic en clair en transit. Ce n’est pas strictement e2e.

Domaine perso derrière le proxy Cloudflare : Cloudflare termine le HTTPS à son edge, même limite.

Dit clairement : « Complete Privacy » au sens e2e strict ne tient que sur le chemin sslip.io direct. Sur nsl.sh, c’est chiffré jusqu’à l’edge, où c’est re-chiffré. En revanche, dans tous les modes, vos données au repos restent sur votre PCS (votre machine en auto-hébergement NSL, votre VM dédiée en managé Yundera) ; ce qui est intermédié, c’est le nommage et, selon le mode, le transit.

Sur le DNS perso, c’est possible, contrairement à ce que vous avez vu. Vous pouvez pointer votre propre domaine :

Via Cloudflare : un CNAME de votre domaine vers l’adresse sslip.io du PCS, proxy activé, mode SSL Full ou Full strict.

En DNS direct, sans Cloudflare : un enregistrement A vers l’IP publique du PCS, et vous gérez vos certificats vous-même. Dans ce cas le TLS reste terminé sur le PCS, donc vous retrouvez le e2e strict avec votre propre nom.

Le problème qu’on résout, et la différence avec YunoHost que je respecte beaucoup et que vous connaissez mieux que moi : YunoHost vous donne toute la pile, bord réseau compris, mais suppose que vous savez résoudre la joignabilité (IP publique, redirection 80/443, DNS qui pointe juste). Pour beaucoup, c’est devenu le mur : CGNAT en fibre ou en mobile, box sans port-forwarding, ou simple refus de toucher à du DNS et du Let’s Encrypt. NSL retire exactement ce maillon : joignable depuis Internet avec sous-domaine et HTTPS automatiques, sans IP publique ni configuration réseau, conteneurs en un clic via notre fork de CasaOS.

Selon votre profil, deux portes d’entrée : soit vous installez NSL sur votre propre matériel, gratuitement, en gardant le contrôle total du métal ; soit vous passez par Yundera si vous voulez la même chose sans posséder ni administrer de serveur. Ce n’est donc pas « YunoHost en mieux », c’est un compromis différent : moins de souveraineté sur le bord réseau en mode managé, beaucoup moins de friction pour être en ligne. Pour quelqu’un qui maîtrise déjà YunoHost avec une IP publique, NSL apporte peu. Pour quelqu’un coincé derrière du CGNAT, c’est la différence entre héberger et ne pas héberger du tout. Et si la privacy stricte est la priorité, le chemin sslip.io direct ou votre domaine en enregistrement A sans proxy vous la donnent.

Heureux de creuser n’importe lequel de ces points.

4

Concernant la question entre notre candidature et nos atéliers :

Nous avons candidaté au collectif CHATONS l’an dernier, et la candidature a été refusée. Le collectif nous a transmis des points d’amélioration concrets, sur lesquels on travaille depuis, quelques points sont très longs et difficiles à adapter dans notre cas précis.

Ces ateliers en font partie des points d’amélioration qu’on développe : ils créent un contact réel et local avec les personnes qu’on accompagne, servent de permanence régulière pour qui veut de l’aide sur son installation, et sont notre façon de redonner à la communauté. Ils sont gratuits, ouverts à tous les niveaux, co-organisés avec d’autres associations (notament Electrocycle), et le contenu est pédagogique et agnostique (on apprend à s’auto-héberger, pas à acheter notre produit).

Pour être clair sur la casquette : NSL.SH est entièrement libre (FOSS) et financé par Yundera, notre offre managée payante. On ne s’en cache pas.

Si certains points de la charte vous semblent encore mal couverts, je suis preneur : ça nourrit directement notre prochaine candidature. Nous travaillons encore sur plusieurs points mais des rappels sont toujours les bienvenus

5

Si je résume, nsl.sh propose une alternative (gratuite ? pour toujours ?) aux VPN proposés par les FAI associatifs de la FFDN servant à exposer un serveur YunoHost dans le cadre de la solution d’auto-hébergement https://labriqueinter.net/ ( https://internetcu.be/ ). Le VPN est recommandé dans le cas où le FAI commercial n’est pas auto-hébergement-friendly ou si la personne n’a pas le temps ou les compétences pour configurer sa box .

Ce qui serait intéressant du coup c’est de comparer votre solution à cet « état de l’art français » avec avantages et inconvénients en termes de privacy, coût, complexité. J’ai l’impression qu’elle serait particulièrement pertinente dans des pays où le modèle français n’est pas directement réplicable, par difficulté de créer des FAI associatifs ou simplement de récupérer des adresses IP publiques.

Cela me fait me demander si le projet nsl.sh (candidature de chatons de yundera) ne relève pas plutôt de la FFDN.org .

Connaissez-vous aussi le projet netlib.re (en panne pour qq jours) ?

1 Like
6

pour ce qui est de l’explication technique détaillée, un schéma expliquant votre stack (plan de contrôle et plan de données) et le recours à des fournisseurs (sslip.io , cloudflare) dans les deux cas « route directe » et " mode tunnel" serait d’une grande aide. En permettant ainsi aux utilisateur.ices de connaitre en fonction de leur cas d’usage les CGU de vos fournisseurs qui s’appliquent à vos services.

D’ailleurs ça pose la question légale de votre qualité d’hébergeur ou de FAI éventuel dans le « mode tunnel ».

1 Like
7

Hello, je réponds à la place de Chris sur la partie technique.

Merci, ton résumé est très juste, je complète avec le fonctionnement réel, ça répond directement à ta question privacy / coût / complexité.

D’abord la philosophie, parce qu’elle explique nos choix : notre priorité est de rendre l’open source accessible à tout le monde, y compris à des gens qui ne toucheront jamais à une config DNS ou à un port (même objectif entre Yundera et NSL.SH Yundera va juste plus loin dans l’idée). C’est notre vraie différence avec YunoHost, qui vise l’état de l’art du self-hosting pur. Nous, on assume des compromis au profit de la simplicité et on essaie d’être transparents et cohérent dessus.

Par rapport à YunoHost, concrètement les différences:
• apps en conteneurs
• tunnel par défaut
• domaine par défaut et https (sous-domaine nsl.sh)
• focalisation sur la facilité d’usage des apps

Côté réseau, deux modes :
• Direct — le serveur a une IP publique : un Cloudflare Worker détermine l’IP du serveur et forward vers son port public.
• Tunnel — le serveur n’expose pas d’IP publique (CGNAT, box non coopérative) : la route devient Worker → tunnel → serveur. Le tunnel s’active automatiquement et de manière transparente quand il n’y a pas d’IP. C’est là que ta comparaison avec le VPN FFDN est la plus juste : même fonction (exposer sans IP publique), mais le tiers dans le chemin est Cloudflare, pas un FAI associatif. A savoir qu’un tunnel n’est pas exactement pareil qu’un VPN.

Et donc la privacy:
• Chiffrement : client ↔ Cloudflare Worker (certificat Let’s Encrypt), puis Worker ↔ serveur (certificat simple).
• Le point important : le TLS termine au niveau du Worker Cloudflare. Donc en mode nsl.sh (direct comme tunnel), la privacy n’est pas à 100 %. Cloudflare est dans la boucle. C’est un compromis assumé au service de l’accessibilité : DDoS géré, certificats immédiats, zéro config.
• Pour qui veut la privacy complète : on propose l’accès via sslip.io, qui contourne le domaine nsl.sh et Cloudflare. le serveur gère son propre certificat, et on retrouve un comportement équivalent à YunoHost (TLS de bout en bout client ↔ serveur).

Roadmap (donc pas l’actuel) : faire évoluer nsl.sh vers un mode DNS plus direct, où le serveur gère lui-même son certificat Let’s Encrypt, sans Cloudflare → données 100 % privées, comme le mode sslip.io aujourd’hui.

Sur le coût / « gratuit pour toujours ? » : vue qu’on est pas sur des gros coût, domaine pas cher, le gros de la depense est le serveur gateway pour le tunnel (40 eur par mois), mais vue qu’on est pas sur un VPN complet (juste un tunnel pour les requêtes http entrante) j’ai bon espoir que les cout reste maîtrisé.

Sur FFDN vs CHATONS : vue de loin je dirais, la couche connectivité / tunnel tire vers l’esprit FFDN, tandis que la couche AppStore / facilité d’usage est plutôt CHATONS. On est preneurs d’échanger avec tout le monde.

netlib.re : Merci je vais aller voir :slight_smile:

2 Likes
8

@merci @worph pour la reponse
@GautGaut merci pour tous ces retours et pour l’implication à nous aider à améliorer NSL.SH et Yundera.

9

J’ai écrit deux articles de blog pour détailler un peu plus mon message

https://nsl.sh/blog/blog-2/inside-nsl-sh-how-your-server-gets-a-name-https-and-reachability-without-touching-your-router-2
https://nsl.sh/blog/blog-2/nsl-sh-and-yunohost-same-goal-different-philosophy-1

1 Like