Twake Drive – la alternativa de código abierto a Google Drive

 (github.com/linagora)
19 puntos por GN⁺ 2025-10-25 | 1 comentarios | Compartir por WhatsApp
  • Twake Drive es una plataforma de almacenamiento en la nube de código abierto que ofrece funciones de almacenamiento y compartición de archivos similares a Google Drive
  • Soporta despliegue basado en Docker, por lo que puede ejecutarse fácilmente en un entorno local, y usa Node.js y MongoDB como stack tecnológico principal
  • Tiene una arquitectura con frontend y backend separados, y ofrece un entorno de desarrollo basado en Yarn junto con la configuración de rutas de almacenamiento local de archivos
  • Se publica bajo la licencia Affero GPL v3, por lo que empresas u organizaciones pueden personalizarlo libremente en un esquema de autoalojamiento

Resumen del proyecto

  • Twake Drive es una solución de código abierto alternativa a Google Drive desarrollada por Linagora, ofrecida para operar funciones de almacenamiento, compartición y colaboración de archivos en servidores propios
    • Está orientada principalmente a organizaciones que buscan evitar la dependencia de servicios en la nube y mantener la propiedad de los datos y el control de la seguridad
  • El repositorio publicado en GitHub registra más de 1,000 estrellas y alrededor de 70 forks, y se mantiene activamente
  • El proyecto adopta la licencia AGPL-3.0, por lo que al modificar y redistribuir el código fuente se deben conservar las mismas condiciones de licencia

Funciones principales y stack tecnológico

  • Twake Drive funciona sobre Node.js (18.x o superior), MongoDB y Yarn, y está diseñado con una arquitectura de frontend y backend separados
    • El frontend se ejecuta desde el directorio tdrive/frontend/ con yarn dev:start
    • El backend se inicia en tdrive/backend/node/ tras configurar las variables de entorno, usando yarn dev
  • Ofrece una opción simple de despliegue con Docker Compose (docker-compose.minimal.yml), lo que facilita las pruebas locales y los despliegues internos
  • La base de datos puede iniciarse fácilmente con el comando para ejecutar el contenedor de MongoDB (docker run -p 27017:27017 -d mongo)
  • La configuración del entorno puede ajustarse en detalle mediante el archivo tdrive/backend/node/config/development.json

Estructura de desarrollo y despliegue

  • Twake Drive separa el frontend (basado en React) y el backend (basado en Node.js), y permite especificar directamente la ruta del almacenamiento local de archivos
    • La ubicación de almacenamiento de documentos se configura mediante la variable de entorno STORAGE_LOCAL_PATH
  • Con la configuración PUBSUB_TYPE=local se habilita la función de publicación y suscripción en entornos locales
  • La aplicación se ejecuta por defecto en el puerto 3000 y tiene una estructura optimizada para entornos de desarrollo y pruebas
  • Incluye el archivo de configuración de Docker Bake (docker-bake.hcl) y una configuración de GitHub Actions para CI/CD, lo que permite compilación y pruebas automatizadas

Código y estado del repositorio

  • El repositorio está compuesto por 882 commits, 61 ramas y 46 tags, manteniendo un historial de desarrollo activo
  • La distribución principal de lenguajes es TypeScript 58.9%, JavaScript 32.6%, SCSS 3.7%, CSS 2.2%, HTML 1.3% y Less 1.0%

Licencia y posibilidades de uso

  • Twake Drive se distribuye bajo la licencia Affero GPL v3, lo que implica la misma obligación de publicación al modificar y redistribuir el código fuente
  • Las empresas pueden usarlo como base para construir un sistema interno de almacenamiento en la nube o ampliarlo en forma de SaaS
  • Se considera una alternativa capaz de lograr al mismo tiempo reducción de costos frente a servicios comerciales en la nube y soberanía de los datos

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-10-25
Opiniones de Hacker News

  • Aquí muchos hablan de funciones imprescindibles o de copias de seguridad, pero lo realmente importante es si se puede construir y mantener una comunidad durante mucho tiempo
    El almacenamiento en la nube de código abierto puede desaparecer rápido cuando quienes lo mantienen se agotan, así que un modelo de negocio sostenible o una base de contribuyentes es tan importante como la lista de verificación técnica
    También se subestima la interoperabilidad. Si soporta WebDAV o S3 y se integra con los sistemas de autenticación existentes, a los equipos les resulta mucho más fácil probarlo
    Al final, la gente quiere un servicio que no desaparezca cuando termine la “luna de miel”. Eso es mucho más difícil que agregar una barra de progreso

    • Puede que esa sea una debilidad del modelo organizativo de la herramienta, pero yo no quiero participar en la comunidad. Solo quiero que funcione bien
      Uso Syncthing, y nunca me han dicho que participe en la comunidad, pero sigue funcionando muy bien
      Parece que Syncthing financia su desarrollo con una empresa llamada Kastelo, que ofrece soporte empresarial
      Yo también dirijo una empresa de consultoría open source, y se sostiene perfectamente con contratos corporativos sin necesidad de comunidad
      La comunidad está bien, pero a largo plazo creo que son más importantes el modelo de negocio y la estrategia de marketing
    • Personalmente, creo que la compatibilidad con S3 es lo central en el almacenamiento de objetos
      Si un sistema soporta la API de S3, cualquier almacenamiento es fácil de reemplazar. Backblaze, Wasabi, una API local de S3: casi todo puede sustituirse directamente
    • No entiendo por qué la comunidad sería importante. Si es una herramienta que resuelve un problema, la comunidad no es más que un medio para mantenerla

  • De todos los sistemas de sincronización de archivos self-hosted que he usado, Seafile ha sido el más usable
    Pero actualizar el servidor sigue siendo engorroso. NextCloud y herramientas parecidas fueron un desastre total para mis estándares

    • Me da curiosidad por qué lo consideras un desastre. En nuestra empresa llevamos 3 años usando NextCloud sin problemas
      Tiene todos los plugins que necesitamos, buen rendimiento y sincronización perfecta. Tanto así que no vemos motivo para probar otra alternativa
    • Yo corro Seafile en su versión Docker, y actualizarlo es muy fácil: solo cambio la etiqueta
      Antes NextCloud se arrastraba con repositorios grandes y necesitaba una máquina más potente
      Seafile funciona bien incluso en una placa ARM con 2 GB de RAM
    • Hace poco instalé Seafile directamente en un servidor y puse mucha atención en definir una estrategia de respaldo y seguridad
      También lo probé a fondo, y la velocidad de sincronización y la capacidad de respuesta me sorprendieron
      Ahora ya moví todos mis archivos desde Google Drive y lo uso como mi nube principal
    • Resilio también está bien. Syncthing me gusta, pero en mi experiencia Resilio es más rápido y atraviesa mejor el NAT
    • Yo también llevo años usando Seafile y Seadrive, y con mapeo de unidades subst funciona de maravilla

  • Habría sido divertido llamarlo Twake Dwive

  • Como preguntan otros, me interesa saber cómo se compara esto con NextCloud u ownCloud. Y también si hay clientes para Windows/Mac/Mobile

    • ownCloud sí tiene clientes para todas las plataformas, pero había tantos pequeños bugs y problemas de confiabilidad en cada una que no pude usarlo
    • Intenté instalar NextCloud y fue una experiencia completamente dolorosa
    • En mi experiencia, NextCloud parece un monstruo inflado de PHP. Rinde peor, y Twake parece mucho más liviano y con un alcance más claro

  • La vida o muerte de una herramienta de almacenamiento open source depende de tres cosas

    1. sincronización simple que nunca te sorprenda
    2. manejo de conflictos que se le pueda explicar incluso a gente no técnica
    3. actualizaciones sin problemas
      Si Twake hace bien eso y además soporta S3 y LDAP, tiene posibilidades
      Pero lo realmente difícil es la confianza y la documentación. Hace falta un modelo de amenazas claro, una guía de migración desde Drive o Dropbox, y un CLI pequeño que funcione incluso en entornos headless
    • Yo añadiría una cuarta: la facilidad para verificar los respaldos
      Una vez en una empresa teníamos las copias de seguridad activadas, pero cuando intentamos restaurarlas estaban todas corruptas. Desde entonces, verificar los respaldos es mi prioridad número uno
    • Me gustaría que hubiera un botón manual de “sincronizar ahora”. En Google Drive muchas veces es frustrante no tener claro el estado de la sincronización

  • Me parece curioso que una app de tan alto rendimiento esté hecha con 58.9% TypeScript y 32.6% JavaScript

    • Entonces ¿91.5% es JavaScript, no? Es la típica broma de que TypeScript no es un lenguaje real
    • Esta app está limitada por I/O, así que correrla en TS/JS no debería ser problema
    • Parece que el backend está en TS y el frontend en JS. Yo separo las pruebas en JS y el código de la app en TS
      Creo que es más importante enfocarse en las partes donde el cuello de botella no es el lenguaje
    • Viendo que hoy muchas startups construyen arquitecturas orientadas a eventos con microservicios TS/JS, la elección no me parece rara

  • Un poco fuera de tema, pero ¿habrá alguna forma de hacer que Viber o WhatsApp usen otro almacenamiento de respaldo en vez de Google Drive? Me pregunto si se podría haciendo root y engañando la interfaz

    • En Android eso se puede implementar simplemente como un share-target. Incluso sería fácil hacerlo como PWA

  • ¿De verdad hace falta una base de datos para un sistema así?
    En Unix parecería bastar con CRUD de usuarios y archivos, más permisos. ¿Habrá algún software viejo que simplemente envuelva eso con una UI o API? ¿Aunque sea sobre el protocolo SAMBA?

    • Para implementar historial de versiones o URLs compartidas sí necesitas una DB.
      Además, si quieres restringir grupos de usuarios, enseguida llegas al límite de cantidad de grupos (65536)
    • Te convendría mirar Cockpit. En Cockpit Applications ofrece exploración de archivos, edición de permisos, subida/bajada y la mayoría de esas funciones
    • Para caché de operaciones en disco o sincronización multinodo necesitas almacenamiento de metadatos. Al final es difícil evitar una DB
    • Yo también he pensado en algo así: me gustaría una interfaz estilo Google Drive hecha con Python y fsspec para manejar sistemas de archivos locales o remotos como S3/SSH
    • Usar una DB facilita hacer joins entre users y documents, o aprovechar índices y transacciones de MongoDB
      También simplifica la gestión de metadatos de versiones, y en Windows sería más fácil de hackear

  • Puede que yo vaya contra el ambiente típico de HN, pero para mí la función más importante es la búsqueda
    Cuando guardas varios TB de datos, encontrar aunque sea una foto se vuelve difícil
    Necesito una función que haga análisis de imágenes y permita buscar cosas como “dos personas en Nothing Street”
    Ahora mismo Google está muy por encima en esto, pero ojalá otras nubes eventualmente lo alcancen

  • Recomiendo probar Syncthing

    • Yo también uso Syncthing desde que se me acabó el descuento estudiantil de Dropbox. Durante años ha funcionado de forma estable
      Eso sí, la experiencia móvil seguía siendo algo tosca. Aun así, con la interfaz web podía sacar un archivo en una urgencia
    • Syncthing es excelente, pero no sirve bien para manejar archivos grandes en móvil. Su enfoque de sincronización completa tiene esas limitaciones
    • Es la herramienta FOSS más confiable que uso. Simplemente funciona, y corre en todas las plataformas