Twake Drive – l’alternative open source à Google Drive

 (github.com/linagora)
19 points par GN⁺ 2025-10-25 | 1 commentaires | Partager sur WhatsApp
  • Twake Drive est une plateforme de stockage cloud open source offrant des fonctions de stockage et de partage de fichiers similaires à Google Drive
  • Il prend en charge un déploiement basé sur Docker, ce qui permet de l’exécuter facilement en local, et utilise principalement Node.js et MongoDB comme stack technique
  • Son architecture sépare le front-end et le back-end, et fournit un environnement de développement basé sur Yarn ainsi qu’une fonction de configuration du chemin de stockage local des fichiers
  • Le projet est publié sous licence Affero GPL v3, ce qui permet aux entreprises et aux organisations de le personnaliser librement en auto-hébergement

Aperçu du projet

  • Twake Drive est une solution open source alternative à Google Drive développée par Linagora, permettant d’exploiter sur ses propres serveurs des fonctions de stockage, de partage et de collaboration autour des fichiers
    • Il vise principalement les organisations qui souhaitent éviter la dépendance à des services cloud et conserver la propriété des données et le contrôle de la sécurité
  • Le dépôt publié sur GitHub affiche plus de 1 000 étoiles et environ 70 forks, et fait l’objet d’une maintenance active
  • Le projet adopte la licence AGPL-3.0, ce qui impose de conserver les mêmes conditions de licence en cas de modification et de redistribution du code source

Principales fonctionnalités et stack technique

  • Twake Drive fonctionne sur la base de Node.js (18.x ou supérieur), MongoDB et Yarn, avec une architecture conçue pour séparer le front-end et le back-end
    • Le front-end se lance depuis le répertoire tdrive/frontend/ avec yarn dev:start
    • Le back-end se lance depuis tdrive/backend/node/ après configuration des variables d’environnement avec yarn dev
  • Une option de déploiement simple avec Docker Compose (docker-compose.minimal.yml) est fournie, facilitant les tests en local et les déploiements internes
  • La base de données peut être démarrée facilement via la commande d’exécution du conteneur MongoDB (docker run -p 27017:27017 -d mongo)
  • La configuration peut être ajustée en détail via le fichier tdrive/backend/node/config/development.json

Structure de développement et de déploiement

  • Twake Drive sépare le front-end (basé sur React) et le back-end (basé sur Node.js), et permet de définir directement le chemin du stockage local des fichiers
    • L’emplacement de stockage des documents se règle via la variable d’environnement STORAGE_LOCAL_PATH
  • Le paramètre PUBSUB_TYPE=local prend en charge les fonctions de publication et d’abonnement dans un environnement local
  • L’application s’exécute par défaut sur le port 3000 et présente une structure optimisée pour les environnements de développement et de test
  • Le projet inclut un fichier de configuration Docker Bake (docker-bake.hcl) ainsi qu’une configuration GitHub Actions pour le CI/CD, permettant des builds et des tests automatisés

État du code et du dépôt

  • Le dépôt comprend 882 commits, 61 branches et 46 tags, avec un historique de développement actif
  • La répartition principale des langages est de TypeScript 58,9 %, JavaScript 32,6 %, SCSS 3,7 %, CSS 2,2 %, HTML 1,3 %, Less 1,0 %

Licence et possibilités d’utilisation

  • Twake Drive est distribué sous licence Affero GPL v3, avec obligation de conserver la même ouverture en cas de modification et de redistribution du code source
  • Les entreprises peuvent s’en servir pour mettre en place un système interne de stockage cloud ou l’étendre sous forme de SaaS
  • Il est considéré comme une alternative permettant de réduire les coûts des services cloud commerciaux tout en renforçant la souveraineté des données

À lire aussi

1 commentaires

 
GN⁺ 2025-10-25
Avis Hacker News

  • Beaucoup de gens parlent ici de fonctionnalités indispensables ou de sauvegardes, mais le vrai enjeu est de savoir si l’on peut créer une communauté et la faire durer dans le temps
    Le stockage cloud open source disparaît vite quand les mainteneurs s’épuisent, donc un modèle économique durable ou une base de contributeurs compte autant qu’une checklist technique
    L’interopérabilité (interoperability) est aussi sous-estimée. Si WebDAV ou S3 sont pris en charge et que l’intégration avec les systèmes d’authentification existants est possible, les équipes essaieront beaucoup plus facilement
    Au fond, les gens veulent un service qui ne disparaît pas une fois la « lune de miel » terminée. C’est bien plus difficile que d’ajouter une barre de progression

    • C’est peut-être une faiblesse du modèle organisationnel de l’outil, mais je n’ai pas envie de participer à une communauté. Je veux simplement que ça fonctionne bien
      J’utilise Syncthing, et on ne m’a jamais demandé de participer à la communauté, pourtant ça marche toujours très bien
      Syncthing semble financer son développement via une entreprise appelée Kastelo, qui fournit du support enterprise
      Je dirige moi aussi une société de conseil open source, et sans communauté, les contrats d’entreprise suffisent largement à faire vivre le projet
      La communauté, c’est bien, mais à long terme, je pense que le modèle économique et la stratégie marketing sont plus importants
    • Personnellement, je pense que la compatibilité S3 est l’élément central du stockage objet
      Si un système prend en charge l’API S3, il devient facile de remplacer n’importe quel stockage. Backblaze, Wasabi, une API S3 locale, tout cela est généralement interchangeable
    • Je ne vois pas pourquoi la communauté serait si importante. Si c’est un outil qui résout un problème, la communauté n’est qu’un moyen d’assurer la maintenance

  • Parmi toutes les solutions de synchronisation de fichiers auto-hébergées que j’ai utilisées, Seafile est celle qui m’a paru la plus convaincante
    Mais les mises à niveau du serveur restent pénibles. NextCloud et les outils similaires ont été, selon mes critères, un véritable désastre

    • Je serais curieux de savoir pourquoi tu considères ça comme un désastre. Dans notre entreprise, nous utilisons NextCloud depuis 3 ans sans aucun problème
      Nous avons tous les plugins nécessaires, les performances sont bonnes et la synchronisation est parfaite. Au point qu’on n’a aucune raison d’essayer autre chose
    • J’exécute Seafile avec la version Docker, et il suffit de changer le tag pour que la mise à niveau soit très simple
      Avant, NextCloud ralentissait avec de gros dépôts et demandait une machine plus puissante
      Seafile fonctionne très bien même sur une carte ARM avec 2 Go de RAM
    • J’ai récemment installé Seafile directement sur mon serveur, et j’ai beaucoup réfléchi à la stratégie de sauvegarde et de sécurité
      J’ai fait des tests approfondis, et la vitesse de synchronisation comme la réactivité m’ont surpris
      J’ai maintenant migré tous mes fichiers depuis Google Drive et je l’utilise comme cloud principal
    • Resilio est aussi pas mal. Syncthing est bien, mais d’après mon expérience, Resilio est plus rapide et traverse mieux le NAT
    • J’utilise Seafile et Seadrive depuis des années moi aussi, et avec un mapping de lecteur subst, cela fonctionne très bien

  • Ça aurait été drôle de l’appeler Twake Dwive

  • Comme d’autres l’ont demandé, je me demande comment cela se compare à NextCloud ou ownCloud. Et j’aimerais aussi savoir s’il existe des clients pour Windows/Mac/mobile

    • ownCloud a bien des clients pour chaque plateforme, mais il y avait trop de petits bugs et de problèmes de fiabilité sur chacune d’elles pour que je puisse l’utiliser
    • J’ai essayé d’installer NextCloud, et l’expérience a été totalement pénible
    • D’après mon expérience, NextCloud ressemble à un monstre PHP obèse. Les performances ne sont pas bonnes, alors que Twake semble bien plus léger et avec un périmètre plus clair

  • La survie d’un outil de drive open source dépend de trois choses

    1. une synchronisation simple qui ne surprend jamais
    2. une gestion des conflits explicable même à des non-techniciens
    3. des mises à niveau sans problème
      Si Twake gère bien cela tout en prenant en charge S3 et LDAP, il a du potentiel
      Mais ce qui est vraiment difficile, c’est la confiance et la documentation. Il faut un modèle de menace clair, un guide de migration depuis Drive ou Dropbox, ainsi qu’un petit CLI capable de fonctionner dans des environnements headless
    • J’aimerais y ajouter un quatrième point : la facilité de vérification des sauvegardes
      Autrefois, dans mon entreprise, les sauvegardes étaient bien activées, mais au moment de restaurer, tout était corrompu. Depuis, la vérification des sauvegardes est ma priorité absolue
    • J’aimerais qu’il y ait un bouton manuel « synchroniser maintenant ». Avec Google Drive, l’état de la synchronisation n’est souvent pas clair, et c’est frustrant

  • Je trouve surprenant qu’une application aussi performante soit faite avec 58,9 % de TypeScript et 32,6 % de JavaScript

    • Donc 91,5 %, c’est du JavaScript, non ? C’est la vieille blague selon laquelle TypeScript n’est pas un vrai langage
    • Cette application est surtout I/O-bound, donc la faire tourner en TS/JS ne pose pas de problème
    • Le backend semble en TS et le frontend en JS. Moi, je sépare les tests en JS et le code applicatif en TS
      Je pense qu’il est plus important d’optimiser les zones qui ne sont pas les goulets d’étranglement du langage
    • Quand on voit les startups d’aujourd’hui construire des architectures orientées événements avec des microservices TS/JS, ce choix n’a rien d’étrange

  • C’est un peu hors sujet, mais y aurait-il un moyen de faire utiliser à Viber ou WhatsApp un autre stockage de sauvegarde que Google Drive ? Je me demande si ce serait possible en rootant l’appareil et en trompant l’interface

    • Sur Android, cela peut simplement être implémenté comme une share-target. C’est aussi facile à faire en PWA

  • Est-ce qu’un tel système a vraiment besoin d’une base de données ?
    Sous Unix, j’ai l’impression qu’entre les utilisateurs, le CRUD sur les fichiers et les permissions, cela pourrait suffire. Existe-t-il un ancien logiciel qui enveloppe cela dans une UI ou une API, éventuellement sur la base du protocole SAMBA ?

    • Pour implémenter des fonctions comme l’historique des versions ou les URL de partage, une DB est nécessaire.
      Et si l’on veut imposer des restrictions par groupes d’utilisateurs, on atteint vite la limite du nombre de groupes (65536)
    • Tu peux jeter un œil à Cockpit. Cockpit Applications propose la plupart des fonctions, comme l’exploration de fichiers, l’édition des permissions, l’upload/download, etc.
    • Pour le cache des opérations disque ou la synchronisation multi-nœuds, il faut un stockage de métadonnées. Au final, il me semble difficile d’éviter une DB
    • J’y ai pensé aussi, et j’aimerais beaucoup une interface de type Google Drive en Python et fsspec pour manipuler aussi bien un système de fichiers local que S3, SSH et d’autres variantes
    • Avec une DB, il est facile de faire des jointures entre users et documents, ou d’exploiter les index et transactions MongoDB
      La gestion des métadonnées de version devient simple, et c’est aussi plus facile à bidouiller sous Windows

  • Je suis probablement en décalage avec l’ambiance de HN, mais pour moi, la fonctionnalité la plus importante, c’est la recherche
    Quand on stocke plusieurs To de données, il devient difficile de retrouver ne serait-ce qu’une photo
    Il faut une fonction d’analyse d’image qui permette de rechercher quelque chose comme « deux personnes sur Nothing Street »
    Aujourd’hui, Google écrase tout le monde sur ce point, mais j’espère que les autres clouds finiront par le rattraper

  • Je recommande d’essayer Syncthing au moins une fois

    • J’utilise moi aussi Syncthing depuis la fin de ma réduction étudiante Dropbox. Depuis des années, ça fonctionne de manière stable et fiable
      En revanche, l’expérience mobile restait encore un peu brute. Cela dit, l’interface web permet de récupérer un fichier en urgence
    • Syncthing est excellent, mais il est mal adapté à la gestion de gros fichiers sur mobile. La synchronisation complète impose certaines limites
    • C’est l’outil FOSS le plus fiable que j’utilise. Il fonctionne, tout simplement, et sur toutes les plateformes