subnub/myDrive: a self-hosted Google Drive alternative on Node.js and MongoDB

What subnub/myDrive is for

myDrive is a self-hosted file storage server that presents a web interface similar to Google Drive. The README describes it as an "Open Source cloud file storage server (Similar To Google Drive)" and tells you to "Host myDrive on your own server or trusted platform and then access myDrive through your web browser." The audience is therefore narrow and specific: someone with a server, a domain or a LAN address, and the willingness to run a database alongside the application. It is not a sync client. There is no desktop agent in the repository listing, so the workflow is upload through the browser, not mirror a local folder. Features listed include upload and download of files and folders, folder downloads that are zipped automatically, a media gallery with generated photo and video thumbnails, file sharing, PWA support, service worker registration, email verification, and JWT access and refresh tokens. The project also lists AES256 encryption, which matters because it changes what a stolen disk or bucket contains. If you only need to hand someone a file over HTTP, myDrive is heavier than the job. If you want a shared drive your household or small team can log into, the feature list matches that shape.

How the storage split works: MongoDB for metadata, fs or S3 for chunks

The architecture separates two kinds of data. MongoDB holds file and folder metadata. The actual bytes go to a storage backend chosen by the DB_TYPE environment variable, which the .env.example documents as "fs" for the filesystem or "s3" for Amazon S3. That split is the central design decision and it has consequences. Backing up myDrive means backing up two systems, and restoring only one of them gives you either a list of files with no content or content with no names. The docker-compose.yml reflects this by declaring separate volumes: mydrive-data for /data/, mydrive-temp for /temp/, and db-data for MongoDB's /data/db. In filesystem mode the FS_DIRECTORY value must be an exact path and, per the .env.example comment, "PATH MUST END IN A SLASH". In S3 mode you supply S3_ID, S3_KEY, and S3_BUCKET. The backend is TypeScript compiled to dist-backend, and the front end is React built by Vite. Encryption is controlled by the KEY variable, and the .env.example warns in capitals: "DO NOT LOSE OR FORGET THIS KEY AS ALL DATA WILL BE LOST IF YOU LOSE IT." If KEY is empty, the README says the app prompts you to type one into the terminal at server start. That prompt is a real operational hazard on a container that restarts unattended.

Installing myDrive with Docker Compose and logging in

The fastest documented path is Docker Compose. The README instructs you to make a folder, copy docker-compose.yml and .env.example into it, rename .env.example to .env, fill in the values, and run the compose command. The compose file maps port 3000 by default through ${HTTP_PORT:-3000}:3000 and includes a mongo:8 service with a healthcheck that runs db.adminCommand('ping').

docker compose up -d

After that, the README says to access the app at http://localhost:3000. The connection string in .env.example is written for the bundled container: mongodb://username:password@mongo:27017/mydrive?authSource=admin. If you point MONGODB_URL at a database outside the compose network, that hostname will not resolve.

The non-Docker route needs Node.js 20 (the engines field requires >=20.14.0), MongoDB, and optionally FFMPEG for video thumbnails. Build essentials are needed on Linux.

npm install
npm run build
npm run start

The README notes that npm run build can exceed Node's default heap and abort with "Aborted (core dumped)". The documented workaround is to raise the limit.

NODE_OPTIONS="--max-old-space-size=4096" npm run build

For a first real use, log in through the browser, create a folder, upload a file into it, then download the folder. The README states folder downloads are converted to zip automatically, so a working zip download exercises the archiver path as well as storage.

Where myDrive breaks or becomes the wrong tool

The KEY variable is the sharpest failure mode. Lose it and the .env.example states all data is lost. Set it to a placeholder like the example value and you have encrypted your files with a key that is published in a public repository. The same file warns that losing PASSWORD_ACCESS, PASSWORD_REFRESH, or PASSWORD_COOKIE logs every user out, and that changing them forces a logout, which is useful for revocation but disruptive if done by accident. The three values must be different strings.

Installation is not frictionless. The README devotes a section to possible installation issues, including a missing make binary that requires build-essential on Linux, and the out-of-memory build failure. Video thumbnails depend on ffmpeg, which the README marks optional, so a deployment without it silently loses a listed feature. The Dockerfile installs ffmpeg in both stages, but a bare npm install on a host does not.

myDrive is the wrong tool if you want a managed service with an SLA, or if you expect a sync client that keeps a laptop folder mirrored. The README lists no such client. It is also wrong if you cannot operate MongoDB, because the application does not embed a database. Finally, the README does not document rollback or downgrade for the migrate-to-mydrive4 script, so upgrading without a tested restore path is a risk you take on yourself.

myDrive compared with Nextcloud and plain object storage

Nextcloud is the obvious alternative, and the difference is in the data model. Nextcloud is a PHP application with its own database abstraction and a long-standing desktop and mobile sync client line. myDrive is a TypeScript and Node.js application whose README describes MongoDB for metadata and either the filesystem or Amazon S3 for chunks, with JWT access and refresh tokens and a React front end. If you already run MongoDB and want a Node stack you can read end to end, myDrive is a smaller surface. If you need desktop sync, calendar, contacts, or a large app ecosystem, Nextcloud covers ground myDrive's feature list does not mention.

The second alternative is skipping the application entirely and putting files in S3 or another object store behind a static front end. That is cheaper to operate and has no MongoDB to back up, but you lose the pieces myDrive implements: user accounts, email verification, share links, a media gallery, generated thumbnails, and a trash view. Choosing myDrive means choosing to run and patch all of that yourself.

Maintenance, licensing, and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-11, so the codebase is being touched. The most recent release listed is v4.0.2 from 2025-03-01. Treat the gap between a commit and a tagged release as something to check yourself rather than assuming a support policy.

Upgrade cost has two visible parts. The package.json defines migrate-to-mydrive4 as a Node script under serverUtils, and the README has an "Updating from a previous version of myDrive" section, but the README as given does not document rollback, so the migration is one-way unless you have snapshots. Separately, the CHANGELOG.md at the repository root is the place to read before bumping the image tag.

Licensing is GPL-3.0, and package.json repeats "GNU General Public License v3.0". That is a copyleft licence. If you modify myDrive and distribute it, or offer it to users over a network, the GPL's source-availability terms are likely to apply to your modified version. Running it privately for yourself or your organisation is a different situation. This is not legal advice; check with counsel before you build a product on it.

Editorial conclusion

Adopt myDrive if you want a browser-based drive on hardware you control and you are comfortable running MongoDB, Node.js 20, and a reverse proxy. Skip it if you need managed uptime, documented rollback, or a support contract, because the README documents neither. Before putting real data in it, verify the KEY behaviour on first start and confirm your backup covers both MongoDB and the FS_DIRECTORY volume.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. subnub/myDrive on GitHub