Twake Drive – die Open-Source-Alternative zu Google Drive

 (github.com/linagora)
19 Punkte von GN⁺ 2025-10-25 | 1 Kommentare | Auf WhatsApp teilen
  • Twake Drive ist eine Open-Source-Cloud-Storage-Plattform, die Dateispeicherung und -freigabe ähnlich wie Google Drive bietet
  • Unterstützt Docker-basierte Bereitstellung, lässt sich dadurch leicht lokal betreiben und nutzt Node.js und MongoDB als zentralen Technologie-Stack
  • Verfügt über eine getrennte Frontend-/Backend-Architektur und bietet eine Yarn-basierte Entwicklungsumgebung sowie die Konfiguration lokaler Dateispeicherpfade
  • Wird unter der Affero GPL v3-Lizenz veröffentlicht, sodass Unternehmen und Organisationen sie in selbstgehosteten Setups frei anpassen können

Projektüberblick

  • Twake Drive ist eine von Linagora entwickelte Open-Source-Alternative zu Google Drive, die Dateiablage, Freigabe und Zusammenarbeit auf eigenen Servern ermöglicht
    • Zielgruppe sind vor allem Organisationen, die Abhängigkeiten von Cloud-Diensten vermeiden und Datenhoheit sowie Sicherheitskontrolle behalten möchten
  • Das öffentlich auf GitHub verfügbare Repository verzeichnet mehr als 1.000 Stars und rund 70 Forks und wird aktiv gepflegt
  • Das Projekt verwendet die AGPL-3.0-Lizenz, wodurch bei Änderungen am Quellcode und Weiterverbreitung dieselben Lizenzbedingungen beibehalten werden müssen

Hauptfunktionen und Technologie-Stack

  • Twake Drive basiert auf Node.js (18.x oder höher), MongoDB und Yarn und ist als getrennte Frontend-/Backend-Architektur aufgebaut
    • Das Frontend wird im Verzeichnis tdrive/frontend/ mit yarn dev:start gestartet
    • Das Backend läuft unter tdrive/backend/node/ nach dem Setzen der Umgebungsvariablen mit yarn dev
  • Bietet mit Docker Compose eine einfache Bereitstellungsoption (docker-compose.minimal.yml), wodurch lokale Tests und interne Deployments leicht umzusetzen sind
  • Über den MongoDB-Container-Startbefehl (docker run -p 27017:27017 -d mongo) lässt sich die Datenbank schnell starten
  • Die Konfiguration kann über die Datei tdrive/backend/node/config/development.json im Detail angepasst werden

Entwicklungs- und Bereitstellungsstruktur

  • Twake Drive trennt Frontend (React-basiert) und Backend (Node.js-basiert) und erlaubt die direkte Festlegung des lokalen Dateispeicherpfads
    • Über die Umgebungsvariable STORAGE_LOCAL_PATH wird der Speicherort für Dokumente festgelegt
  • Mit der Einstellung PUBSUB_TYPE=local wird Publish-/Subscribe-Funktionalität in lokalen Umgebungen unterstützt
  • Die Anwendung läuft standardmäßig auf Port 3000 und ist für Entwicklungs- und Testumgebungen optimiert
  • Enthält eine Docker Bake-Konfigurationsdatei (docker-bake.hcl) sowie GitHub Actions für CI/CD und unterstützt damit automatisierte Builds und Tests

Code- und Repository-Status

  • Das Repository umfasst 882 Commits, 61 Branches und 46 Tags und weist damit eine aktive Entwicklungshistorie auf
  • Die wichtigsten Sprachenanteile sind TypeScript 58.9%, JavaScript 32.6%, SCSS 3.7%, CSS 2.2%, HTML 1.3% und Less 1.0%

Lizenz und Einsatzmöglichkeiten

  • Twake Drive wird unter der Affero GPL v3 veröffentlicht, wodurch bei Änderungen am Quellcode und Weiterverbreitung dieselbe Offenlegungspflicht gilt
  • Unternehmen können darauf basierend ein internes Cloud-Storage-System aufbauen oder es zu einem SaaS-Angebot erweitern
  • Es wird als Alternative bewertet, mit der sich gleichzeitig Kosten für kommerzielle Cloud-Dienste senken und Datensouveränität sichern lassen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-25
Hacker-News-Kommentare

  • Viele sprechen hier über Pflichtfunktionen oder Backups, aber die eigentlich wichtige Frage ist, ob man eine Community aufbauen und über lange Zeit erhalten kann
    Open-Source-Cloud-Speicher verschwindet schnell, wenn die Maintainer ausbrennen, daher sind ein nachhaltiges Geschäftsmodell oder eine Contributor-Basis genauso wichtig wie technische Checklisten
    Auch Interoperabilität wird unterschätzt. Wenn WebDAV oder S3 unterstützt wird und sich das System an bestehende Authentifizierungssysteme anbinden lässt, probieren Teams es viel eher aus
    Am Ende wollen die Leute einen Dienst, der nicht verschwindet, sobald die „Honeymoon-Phase“ vorbei ist. Das ist deutlich schwieriger, als nur einen Fortschrittsbalken hinzuzufügen

    • Das mag eine Schwäche des organisatorischen Modells solcher Tools sein, aber ich möchte mich nicht an einer Community beteiligen. Ich will einfach nur, dass es gut funktioniert
      Ich nutze Syncthing, und niemand hat mir je gesagt, ich solle mich in der Community engagieren, trotzdem läuft es weiterhin gut
      Bei Syncthing scheint eine Firma namens Kastelo Enterprise-Support anzubieten und damit die Entwicklung zu finanzieren
      Ich betreibe selbst eine Open-Source-Consulting-Firma, und auch ohne Community lässt sich das über Unternehmensverträge gut tragen
      Community ist schön, aber langfristig sind Geschäftsmodell und Marketingstrategie meiner Meinung nach wichtiger
    • Für mich persönlich ist S3-Kompatibilität der Kern von Object Storage
      Wenn ein System die S3-API unterstützt, lässt sich praktisch jeder Speicher leicht austauschen. Backblaze, Wasabi, lokale S3-APIs usw. sind meist als Drop-in-Ersatz nutzbar
    • Ich verstehe nicht, warum die Community so wichtig sein soll. Wenn ein Tool ein Problem löst, ist die Community letztlich nur ein Mittel zur Wartung

  • Von allen self-hosted Dateisynchronisationslösungen, die ich bisher genutzt habe, war Seafile am brauchbarsten
    Aber Server-Upgrades sind immer noch mühsam. NextCloud und ähnliche Tools waren für mich eine absolute Katastrophe

    • Mich würde interessieren, warum du es als Katastrophe bezeichnest. In unserer Firma nutzen wir NextCloud seit drei Jahren problemlos
      Alle nötigen Plugins sind da, die Performance ist gut, und die Synchronisation funktioniert perfekt. Ich sehe kaum einen Grund, etwas anderes auszuprobieren
    • Ich betreibe Seafile in der Docker-Version, und wenn man nur den Tag ändert, sind Upgrades sehr einfach
      Früher kam NextCloud mit großen Repositories ins Stocken und brauchte leistungsfähigere Maschinen
      Seafile läuft dagegen selbst auf einem ARM-Board mit 2 GB RAM gut
    • Ich habe Seafile vor Kurzem direkt auf einem Server installiert und viel Wert auf eine Backup- und Sicherheitsstrategie gelegt
      Ich habe alles gründlich getestet, und die Synchronisationsgeschwindigkeit sowie Reaktionsfreudigkeit waren erstaunlich
      Inzwischen habe ich alle Dateien von Google Drive migriert und nutze es als meine Haupt-Cloud
    • Resilio ist auch gut. Syncthing ist ebenfalls gut, aber meiner Erfahrung nach ist Resilio schneller und kommt besser durch NAT
    • Ich nutze Seafile und Seadrive ebenfalls seit Jahren, und mit subst-Laufwerkszuordnung funktioniert das sehr gut

  • Es wäre lustig gewesen, wenn man es Twake Dwive genannt hätte

  • Wie andere schon gefragt haben, würde mich interessieren, wie sich das im Vergleich zu NextCloud oder ownCloud schlägt. Und ob es Clients für Windows/Mac/Mobile gibt

    • ownCloud hat zwar Clients für alle Plattformen, aber auf jeder Plattform gab es zu viele kleine Bugs und Zuverlässigkeitsprobleme, sodass ich es nicht nutzen konnte
    • Ich habe versucht, NextCloud zu installieren, und das war eine rundum schmerzhafte Erfahrung
    • Meiner Erfahrung nach ist NextCloud ein aufgeblähtes PHP-Monster. Die Performance ist schwach, und Twake wirkt deutlich leichter und klarer im Umfang

  • Ob ein Open-Source-Drive-Tool lebt oder stirbt, hängt von drei Dingen ab

    1. einfache Synchronisation, die einen nie überrascht
    2. Konfliktbehandlung, die sich auch Nicht-Technikern erklären lässt
    3. problemlose Upgrades
      Wenn Twake S3 und LDAP unterstützt und das sauber umsetzt, hat es Potenzial
      Aber wirklich schwierig sind Vertrauen und Dokumentation. Es braucht ein klares Threat Model, Migrationsanleitungen von Drive oder Dropbox und ein kleines CLI, das auch in Headless-Umgebungen funktioniert
    • Ich würde noch einen vierten Punkt ergänzen: einfache Backup-Validierung
      Bei einer früheren Firma hatten wir Backups aktiviert, aber als wir tatsächlich wiederherstellen mussten, war alles beschädigt. Seitdem hat Backup-Validierung für mich höchste Priorität
    • Ich hätte gern einen manuellen „Jetzt synchronisieren“-Button. Bei Google Drive ist oft nicht klar, in welchem Zustand die Synchronisation gerade ist, und das ist frustrierend

  • Ich finde es fragwürdig, mit 58,9 % TypeScript und 32,6 % JavaScript eine so performante App zu bauen

    • Sind das dann nicht 91,5 % JavaScript? Nur ein Witz darüber, dass TypeScript keine echte Sprache sei
    • Die App ist I/O-bound, daher ist TS/JS hier kein Problem
    • Das Backend scheint TS zu sein, das Frontend JS. Ich trenne Tests in JS und App-Code in TS
      Wichtiger als die Geschwindigkeit der Sprache sind meiner Meinung nach die Teile, in denen der Flaschenhals geringer ist
    • Wenn man sieht, wie heutige Startups TS/JS-Microservices in ereignisgetriebenen Architekturen aufbauen, wirkt diese Wahl nicht ungewöhnlich

  • Etwas off-topic, aber gibt es eine Möglichkeit, Viber oder WhatsApp dazu zu bringen, statt Google Drive einen anderen Backup-Speicher zu nutzen? Ich frage mich, ob man das per Root und durch Täuschen der Schnittstelle hinbekommen könnte

    • Unter Android ließe sich das einfach als share-target umsetzen. Das wäre sogar leicht als PWA machbar

  • Braucht so ein System wirklich eine Datenbank?
    Unter Unix wirken Benutzer- und Datei-CRUD sowie Berechtigungen eigentlich ausreichend. Gibt es ältere Software, die genau so etwas mit UI oder API umhüllt? Notfalls auch auf Basis des SAMBA-Protokolls?

    • Für Funktionen wie Versionsverlauf oder Freigabe-URLs braucht man eine DB
      Und wenn man Benutzergruppen einschränken will, stößt man schnell an die Gruppengrenze (65536 Gruppen)
    • Ein Blick auf Cockpit könnte sich lohnen. Unter Cockpit Applications gibt es Dateibrowser, Berechtigungsbearbeitung, Upload/Download und die meisten anderen Funktionen
    • Für Caching von Festplattenoperationen oder Synchronisation über mehrere Nodes hinweg braucht man Metadatenspeicherung. Am Ende kommt man schwer um eine DB herum
    • Ich habe auch schon über so etwas nachgedacht; es wäre schön, eine Google-Drive-artige Oberfläche mit Python und fsspec zu haben, die lokale Dateisysteme oder S3/SSH und andere Dateisysteme handhaben kann
    • Mit einer DB ist es einfacher, users und documents zu joinen oder MongoDB-Indizes und -Transaktionen zu nutzen
      Auch die Verwaltung von Versionsmetadaten wird einfacher, und unter Windows lässt sich damit leichter herumhacken

  • Wahrscheinlich weiche ich damit von der HN-Stimmung ab, aber für mich ist die wichtigste Funktion Suche
    Wenn man mehrere TB an Daten speichert, wird es schwer, auch nur ein einzelnes Foto wiederzufinden
    Ich brauche Funktionen zur Bildanalyse, mit denen man nach Dingen wie „zwei Personen in der Nothing Street“ suchen kann
    Im Moment ist Google in diesem Bereich klar überlegen, aber hoffentlich holen andere Clouds irgendwann auf

  • Ich würde empfehlen, Syncthing einmal auszuprobieren

    • Ich nutze Syncthing auch, seit mein Dropbox-Studentenrabatt ausgelaufen ist. Seit Jahren läuft es stabil und zuverlässig
      Nur die mobile Erfahrung war bisher noch etwas rau. Trotzdem kann man sich im Notfall über das Web-Interface Dateien holen
    • Syncthing ist großartig, aber für große Dateien auf Mobilgeräten ist es ungeeignet. Wegen des Vollsynchronisationsmodells gibt es da Grenzen
    • Es ist das vertrauenswürdigste FOSS-Tool, das ich benutze. Es funktioniert einfach und läuft auf allen Plattformen