ODrive is an Electron Google Drive client that has not shipped a release since 2019

A small Electron app with a Node server inside it

ODrive describes itself as a GUI client for Google Drive on Linux based on Electron, and the promise is to sync your files and folders simply. The repository description calls it a Google Drive GUI for Windows, Mac and Linux.

The architecture is what makes it interesting to read. The dependencies list is not a typical front end list, because there is a server in the application.

"dependencies": {
  "express": "^5.1.0",
  "body-parser": "^1.19.0",
  "morgan": "^1.9.1",
  "chokidar": "^4.0.3",
  "nedb-promise": "^2.0.1",
  "googleapis": "^160.0.0",
  "auto-launch": "^5.0.5",
  "node-notifier": "^10.0.1",
  "fs-extra": "^11.3.2"
}

So the app runs an Express server with body-parser and morgan, watches the filesystem with chokidar, stores its local metadata in nedb-promise, which is a file based embedded datastore with a promise API, talks to Google through the googleapis client, launches itself at login through auto-launch, and sends desktop notifications through node-notifier.

That combination explains the design. A sync client has to watch a directory for local changes, watch the remote for remote changes, keep a local index of what it has already synchronised, and tell the user when something happens. Each of those needs a library, and putting them in an Electron app means the whole thing is one process and one installer rather than a daemon plus a UI plus a packaging story for each.

The Google API access goes through the official googleapis client, which is the right choice, since the Drive API is a large surface and the client library handles the authentication flow and the request plumbing. The remaining question is what credentials it uses.

The three build and run steps, and a Linux dependency from 2016

The To Use section requires Git and Node.js, which comes with npm, and then splits into Setup, Build and Run, with the note that the steps are to be executed in order.

The Setup step is only needed once, and it installs a system package.

# Needed for electron 1.7+ to run, as it's based on chrome
sudo apt install libgconf-2-4

libgconf-2-4 is a configuration database library that was deprecated and removed from Debian years ago, and it is needed here for an Electron 1.7 era requirement. On a current Debian or Ubuntu the package is often not installable from the default repositories, which makes the Setup step a real obstacle rather than a formality. It is a good marker for how old the toolchain in this repository is.

The Build step is npm install, and it is to be executed every new version of the source code. The README notes that if you are working on the code yourself and editing some files in app/assets/, you will need to run npm run webpack, or npm install, for those changes to have an impact on the application. So the assets are compiled by webpack and are not watched by default.

There is a workaround note for Ubuntu users who get an error about a missing node binary, with a symlink of `which nodejs` into /usr/bin/node. And a note about Windows: if you are using Linux Bash for Windows, see a guide or use node from the command prompt, which is a workaround for a case where the Node on PATH in the WSL shell is the Windows one.

The Run step is npm start, which runs electron main, and the README notes that on Windows you can make a .bat file with start cmd /k npm start so you can double click to launch it. It also says the launch-on-startup functionality is only available on bundled releases, which is a limitation of the auto-launch dependency and the way the app is started in development.

The testing story is minimal. npm test runs the lint script, and the lint script is eslint app main.js, so the test command is a lint check and there is no test suite.

Three release formats, and electron-builder for the rest

The Deployment section is the part of the README that has aged best, because electron-builder has kept up with the platform requirements while a lot of the rest of the project has not.

There are currently three release formats supported, nsis as a Windows installer, AppImage for Linux, and DMG for Mac, generated with three scripts.

npm run release-windows
npm run release-linux
npm run release-mac

A different format is a parameter to the same script, and the README gives both examples.

# For DEB
npm run release-linux deb

# For RPM
sudo yum install rpm-build -y
npm run release-linux rpm

The releases are generated in the dist folder. And then the sentence that tells you the actual extent of the tooling, that all formats supported by electron-builder are available, such as 7z, zip, tar.gz, deb, rpm, freebsd, pacman, p5p, apk, dmg, pkg, mas, nsis, appx, msi.

That list is why this project is still worth reading even though it has not shipped a release in seven years. The packaging story is complete and modern, because electron-builder is at ^26.0.12 while the rest of the toolchain is old, and a project that needed a snap, a Flatpak, an AppImage, a deb, an rpm, an AUR package and a Windows installer has the distribution surface of a product rather than a demo.

The Permissionless deployment section is a nice touch for the Windows case. An appimage on Linux already runs permissionless, and for Windows you can run npm run release-windows dir, or zip, 7zip, tar.xz, tar.7z, which creates a folder in dist that you can just copy to a Windows machine.

The top level listing confirms the distribution work. There is a snap/ directory with the snapcraft definition, an aur/ directory for the AUR package, a build/ directory for the build configuration, and a config/ directory that holds the application configuration.

The dependency tree tells the whole story of the project's age

The package.json is worth reading in two passes, because the versions inside it split cleanly into two eras.

The application dependencies are current. bootstrap at 5.3.8, express at ^5.1.0, googleapis at ^160.0.0, chokidar at ^4.0.3, fs-extra at ^11.3.2, node-notifier at ^10.0.1, copy-webpack-plugin at ^13.0.1 and electron-builder at ^26.0.12 are all recent releases. Somebody has been running npm update and the transitive tree has been kept alive.

The toolchain and the UI framework are not. webpack at ^4.41.5 and webpack-cli at ^3.3.10 are two major generations behind, eslint at ^6.8.0 predates the flat config era, node-sass at ^4.13.0 is the native binding version that stopped building on recent Node versions, and font-awesome at ^4.7.0 is the pre-5 icon set. jquery at ^3.4.1 is still there, and popper.js and tether are the old tooltip and dropdown libraries.

The consequence is concrete. The current Electron is at ^8.0.1, which is the version that still works with node-sass 4, and that Electron is from 2020. So the app is a 2020 era Electron application with a 2026 era dependency tree around it, and a webpack 4 build that will need a Node version with the right build tooling for node-sass.

Two other things stand out. The test script is npm run lint, so there is no test suite at all, and the repository has a SECURITY.md, a.travis.yml for CI and an.eslintrc.json for linting. The Travis badge and the Snap status badge are both in the README, which is a reasonable summary of the project's current CI story.

Where ODrive is the wrong choice

The first wrong case is a daily driver. The last tagged release is 0.3.0 from 2019-07-26, and the previous ones are 0.2.1 in February 2019 and 0.2.2 in April 2019. There is no published artefact newer than mid 2019, and while the branch has been pushed to since, the last push was on 2026-06-22. Anyone who wants a Google Drive client today should use the maintained client for their platform.

The second wrong case is a team that needs its Google credentials to be right. The app reaches Google through the googleapis client, so it needs Google API credentials, and anyone deploying it has to supply and protect those credentials themselves. Whether the app uses a desktop flow with a loopback redirect or ships a client secret is exactly the kind of thing a security review should look at, and the SECURITY.md is a reasonable place to start.

The third wrong case is a build environment that has moved on. The Setup step needs libgconf-2-4, which most current distributions no longer package, and the build needs node-sass 4 to compile against Node, which means an old Node. The combination of a modern dependency tree and a 2020 toolchain makes the build harder than the README's three steps suggest.

The fourth wrong case is expecting a maintained sync engine. The design of a sync client is a set of hard problems around conflict resolution, partial sync, and the change detection between a local chokidar watcher and a remote change feed, and a project that has not released since 2019 has not been solving them against a Drive API that has changed since.

How it differs from the official Drive clients

The comparison worth making is with the Google Drive clients that already exist for each platform, and the difference in approach is mostly about the shape of the software rather than about the feature set.

The official clients are a Google product. They are built and supported around the Drive API, and they come with the feature set and the operational shape of a vendor product. They are also large, and they are not something you can read through and rebuild.

ODrive is a self contained Electron application. It is one process with a server, a watcher, a local database and a UI, and the fact that you can read all of it, and build all of it, is the argument for it. It has no telemetry, no account with the vendor beyond Google, and it does not need a separate background service because the sync happens in the same process as the window.

The second difference is the platform story, and it is where the electron-builder configuration pays off. The README lists Linux on most distros, an Arch Linux AUR package, a Snap with an edge channel, a Flatpak, macOS 10.9 and later, and Microsoft Windows 7 and later. Building for all of those is one set of scripts, and a distribution that wants to ship a packaged variant of its own has the release infrastructure already in place.

The third difference is where it is not competitive. The official clients are polished in ways a small client written in 2019 is not. The realistic use of a project like this is as a reference implementation, a starting point for a specialised workflow, or a demonstration of what a Google Drive client looks like when it is small enough to read in an afternoon.

Editorial conclusion

ODrive fits a developer who wants to read the source of a small, self-contained Electron Google Drive client, or who wants to run one on Linux without the official client's overhead, and the packaging scripts cover the formats an AUR, Snap, Flatpak or AppImage distribution needs. It does not fit a daily driver, because the last tagged release is 0.3.0 from 2019-07-26 and there is no published artefact newer than that, and the maintained Google Drive clients for each platform are the sensible alternative. Before building it, note that the electron dependency is at ^8.0.1 and webpack at ^4, so the toolchain is old, and check the SECURITY.md for how the app handles Google API credentials.

Frequently asked questions

Official sources

1. liberodark/ODrive on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases