| 27 Jan 2026 |
 ManUtopiK | Tant que j'y suis, avec nixos-anywhere, vous avez un flake par serveur ou vous gérez tous vos serveurs dans un seul flake ? | 18:26:25 |
 raitobezarius | je gère tout dans les memes expressions nix, j'utilise pas les flakes | 18:26:38 |
 Jo.Blade | j'utilise pas nixos-anywhere, qu'est-ce que c'est ? | 18:26:40 |
| ManUtopiK | avec les .#mon-serveur | 18:26:44 |
| raitobezarius | mais je fais pas "un" repo par entité | 18:26:45 |
| raitobezarius | c'est un mécanisme de provisionnement de NixOS sur des distros random | 18:26:54 |
| Jo.Blade | moi j'ai juste un flake et je fais nixos-rebuild --flake --target=\<ip> | 18:27:02 |
| raitobezarius | c'est pour avoir NixOS « à vide » sur une Debian, une Ubuntu, etc. | 18:27:03 |
| raitobezarius | ça fait le partitionnement ici | 18:27:08 |
| Jo.Blade | * moi j'ai juste un flake et je fais nixos-rebuild --flake --target=<ip> | 18:27:10 |
| raitobezarius | * ça fait le partitionnement aussi | 18:27:11 |
 Albert Larsan | J’ai tout dans un seul flake, et je suis actuellement en train de migrer vers flake-parts. Avec comin, il y a les mises à jour automatiques quasiment instantanées. | 18:28:14 |
| ManUtopiK | Tu as un repo pour tous tes serveurs ? C'est ça ? | 18:28:48 |
| raitobezarius | oui | 18:29:22 |
| ManUtopiK | Je viens de regarder https://github.com/nlewo/comin, un truc qui pull régulièrement pour mettre à jour toute une infra, ça me parait un peu risqué comme approche, non ? | 18:37:04 |
 nim65s | quel serait le risque ? | 18:37:35 |
| Albert Larsan | Il y a une protection anti-force-push | 18:37:45 |
| ManUtopiK | Il faut être bien certain de ce que l'on push pour pas tout casser ! | 18:38:27 |
| ManUtopiK | Mais ça dois tourner sur ton ordi ou sur le serveur ? (question débile peut-être...) | 18:39:20 |
| Albert Larsan | J’ai un hook de pre-push qui build toutes les machines avant de push sur le repo (aussi utile pour avoir un binary cache perso) | 18:39:36 |
| Albert Larsan | Ça tourne sur les appareils qui utilise la config, donc les serveurs, et les ordis que tu veux mettre à jour automatiquement | 18:40:17 |
| Albert Larsan | C’est pull-based | 18:40:31 |
| ManUtopiK | Merci pour votre aide 🥰
J'en profite, je galère toujours à trouver une bonne solution en self-host pour faire ça :
j'ai un dépôt github ou autre forge de mon site web. Le site est sur un serveur self-host, et je veux mettre à jour le site quand il y a la branche main à un nouveau commit.
Pour la plupart de mes sites clients, je passe par des vercel, netlify ou cloudflare... pas besoin de serveur mais pas top. Pour des sites persos, je build dans la CI, puis la CI envoi en ssh le build sur le serveur.
Pour une asso qui gère plusieurs sites, un pote plutôt adminsys a monté Drone CI, puis il a changé pour Woodpecker.
Vous faites comment vous ?
| 18:48:06 |
| ManUtopiK | * Merci pour votre aide 🥰
J'en profite, je galère toujours à trouver une bonne solution en self-host pour faire ça :
j'ai un dépôt github ou autre forge de mon site web. Le site est sur un serveur self-host, et je veux mettre à jour le site quand il y a la branche main à un nouveau commit.
Pour la plupart de mes sites clients, je passe par des vercel, netlify ou cloudflare... pas besoin de serveur mais pas top. Pour des sites persos, je build dans la CI, puis la CI envoi en ssh le build sur le serveur.
Pour une asso qui gère plusieurs sites, un pote plutôt adminsys a monté Drone CI, puis il a changé pour Woodpecker.
Vous faites comment vous ?
(galère d'un gars plutôt front à la base) | 18:48:42 |
| Albert Larsan | La solution de push le build sur le serveur depuis la CI est pas mauvaise | 18:50:01 |
| ManUtopiK | Oui, c'est la plus simple. Mais c'est pas le plus rapide. Le build sur un gitlab self-host, ça prend plus de 10 min en général. Tout ça pour un site web ! (Je fais principalement du nuxt.js, mais c'est pareil pour du next.js ou même svelte). | 18:51:54 |
| ManUtopiK | Après, peut-être que la CI du gitlab est mal foutue. (c'est pas moi qui gère ça). | 18:52:54 |
| ManUtopiK | De toute façon, c'est pas beaucoup plus rapide sur vercel ou cloudflare ! | 18:54:01 |
 zbuben | Tu peux mettre un runner gitlab sur ton serveur qui avec une tâche qui s'occupe de faire le déploiement. Ya un systeme d'étiquettes sur les runners pour filtrer les types de taches qu'ils traitent. Comme ça tu push l'ordre sur gitlab, mais ça reste du coté du serveur que ça pull. | 23:03:45 |
 Alex | Le CI traditionnel et son inabilité de préserver le /nix/store.
Tu peux essayer d'ajouter du caching, mais ça va utiliser beaucoup de mémoire.
Y a-t-il autre chose que Hydra ou Hercules qui bénéficie du /nix/store ? | 23:11:10 |
