# omnicloud: seven drives, three auth models, one upload pool

> OmniCloud is a MIT-licensed Vue and Express application that puts Google Drive, OneDrive, Dropbox, Yandex Disk, two password-based providers and any S3-compatible store behind one workspace. Files can be spread across those accounts by a chosen allocation strategy, metadata is mirrored into SQLite, and the root package script for tests is the placeholder that exits with an error.

**dimartarmizi/OmniCloud** — OmniCloud is a full-stack cloud drive aggregation platform that presents multiple storage providers through a single, consistent workspace. 

- Repository: https://github.com/dimartarmizi/OmniCloud
- Stars: 654 · Forks: 153
- Language: JavaScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/dimartarmizi-omnicloud

## Uploads are allocated across accounts by a strategy you choose

The feature that separates this from a multi-account file viewer is on the upload side. There are five storage allocation strategies, and uploads are placed automatically according to whichever one you pick. Round robin cycles through accounts in order. Weighted round robin does the same with per-account weights. Least used sends the next upload to whichever account is holding the least. Most free sends it to whichever has the most space. And manual takes out the decision entirely by letting you set the priority order yourself. The other file operations are ordinary: browse, create folders, rename, delete including in bulk, download, and view details with previews for the file types that have them. One small honesty in that list is worth noting, since most aggregators would omit it: starring is only available on providers that support it, so the star feature is a best-effort capability rather than a uniform one.

## Seven providers across three different authentication models

The provider table is the honest summary of what this connects to, and the integration column splits into three groups that behave differently. Four use OAuth: Google Drive through its own API, OneDrive through Microsoft Graph, Dropbox through its API, and Yandex Disk through its API. Two use an email and password account connection, and those are MEGA and pCloud. The seventh is any S3-compatible store, configured by endpoint, bucket, access key and secret key. Both of the password-based providers and the S3 configuration are described as being done from the user interface rather than through the environment file, which means those credentials are typed into a browser, travel to the backend you are hosting, and are stored by it. For a self-hosted tool that is a meaningful difference from the OAuth path, where the provider sees the redirect and your server only ever holds a token. If the accounts hold anything you care about, that is the line to think about before you connect them.

## SQLite holds the mirror and a cron job holds the schedule

The speed of the interface comes from not calling seven providers on every page. File metadata is mirrored into SQLite, which the documentation says is for fast navigation, and a separate service keeps that mirror aligned with provider state. The schedule runs through a cron library in the backend, and the sync interval is configurable in the environment file, with the example set to five minutes. Two escape hatches are provided, and both matter for an aggregator: the API exposes a manual sync trigger, so you do not have to wait for the interval after a bulk change, and delta sync reports are available through what the documentation calls the health and sync layer. The five-step description of a request is worth reading as the architecture in miniature: the client calls one REST surface, the backend picks the adapter, responses are normalized into a single data model, metadata lands in the mirror, and upload progress is pushed back over a socket rather than polled.

## One binary, two modes, and a fourteen-day session

There is no separate multi-user edition to install. A single environment setting chooses between a local mode for personal or simple self-hosted use and a hosted mode for multi-user deployments with register, login and logout over session cookies. In hosted mode the scoping is per user: account data, the file mirror, allocation configuration and settings are all scoped, which is what makes the allocation strategies usable per person rather than global. In local mode that scoping has nothing to divide, and the login and register views exist but are not used. The session configuration is explicit in the example environment, including the cookie name and a time-to-live given in hours, which works out to fourteen days. That is a long-lived session cookie for an application that holds credentials for third-party storage, so anyone deploying the hosted mode should shorten it deliberately rather than inherit the example.

## The secret is called a half, which tells you how it is assembled

The environment template is worth reading line by line because the variable names carry information. The first fourteen lines are enough to run the thing locally:```env
PORT=8787

# local = single-user, hosted = multi-user with login/register
APP_MODE=local

CORS_ORIGIN=http://localhost:5173
FRONTEND_URL=http://localhost:5173

SYNC_INTERVAL_MINUTES=5
OMNICLOUD_SECRET_HALF=replace-this-with-random-half-key

AUTH_COOKIE_NAME=omnicloud_session
AUTH_SESSION_TTL_HOURS=336
AUTH_SECRET=replace-this-with-a-strong-random-secret

GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI=http://localhost:8787/api/accounts/google/callback

ONEDRIVE_CLIENT_ID=
ONEDRIVE_CLIENT_SECRET=
ONEDRIVE_TENANT_ID=common
ONEDRIVE_REDIRECT_URI=http://localhost:8787/api/accoun
```Two of those deserve comment. The application secret is named for a half rather than for a key, which implies it is only half of the value and is completed elsewhere, so if you are configuring this by hand you need the other piece as well. And the session secret ships as a placeholder string that reads like an instruction rather than a value, so leaving it untouched produces a working application with a publicly known signing secret. The rest of the template is the per-provider OAuth configuration, with client identifiers and secrets and callback addresses, and the OneDrive tenant identifier defaulted to the common tenant so a multi-tenant application works without editing it.

## The documented copy step is a Windows command

A small friction that every new user on Linux or macOS will hit, and it appears twice in the documentation. Creating the environment file is written as a copy command with no prompt prefix:```bash
copy backend/.env.example backend/.env
```On those two systems the equivalent is a different command with the same two arguments, so the reader has to work out the substitution themselves. The rest of the local setup is unremarkable in the good way: install dependencies from the root, run the development script to start both halves in parallel, and two default endpoints, the client on one port and the API on another. The reason the copy command appears twice is that the Docker instructions repeat the same step, which is reasonable for a reader who jumps straight to the container path. It is the kind of detail that costs nothing to fix and saves a confused first run.

## Docker publishes one port and rewrites four OAuth callbacks

The compose file is more carefully built than the local instructions, and one decision in it deserves credit. The API service publishes no host port at all; only the web service is published, on port 80 of the host, and the frontend is built with its API base and its socket base as relative paths under that origin. So in the container deployment the API is reachable only through the frontend's reverse proxy rather than directly, which is the right default for an application holding third-party credentials. The database lives in a named volume so it survives a rebuild, and the callback addresses for all four OAuth providers are rewritten to the published port rather than the development one. That last part is the trap: if you deploy the OAuth providers and forget those four lines, every login fails at the redirect with an error that points at the provider rather than at your configuration.

## The test script is the placeholder that exits with an error

The root manifest is the place to look for what this project has not done yet.```
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "npm-run-all --parallel dev:api dev:web",
    "build": "npm run build:web",
    "build:web": "npm --prefix frontend run build",
    "dev:web": "npm --prefix frontend run dev -- --host",
    "dev:api": "npm --prefix backend run dev",
    "start": "npm --prefix backend start"
```The test script is the value the package manager generates when you create a project and never replace: it prints that no test is specified and exits non-zero. So there is no test suite, and running the test command is guaranteed to fail. Two more details in the same file. The build script only builds the web client and nothing else, while the start script launches the backend directly, which tells you the backend is meant to run under a runtime that loads its source rather than being compiled as part of a build. And the manifest has no dependencies of its own at all, because the real dependency lists live in the two workspace manifests it points at. The metadata fields are empty too, including the description and the keywords, and the licence field disagrees with the repository metadata. Since the package is marked private it is never published, so the licence mismatch costs nothing in practice.

## Conclusion

omnicloud is worth trying if your real problem is that one cloud account cannot hold everything and you would rather not choose which vendor holds which file, because the allocation strategies are the feature that makes aggregation more than a viewer. Two things to weigh before you point it at real accounts. Two of the providers authenticate with a plain email and password and one with access keys, entered through the browser, so those credentials pass through your own backend rather than through an OAuth redirect, which is a different trust decision from the other four. And there is no test suite behind it, with the test script still set to the placeholder that fails, so treat it as software you will read and change rather than software you will upgrade.

## FAQ

### Which storage providers does omnicloud connect to?

Google Drive, OneDrive, Dropbox and Yandex Disk over OAuth, MEGA and pCloud through an email and password account connection, and any S3-compatible store configured by endpoint, bucket, access key and secret key.

### How does omnicloud decide which account to upload to?

By the allocation strategy you pick: round robin, weighted round robin, least used, most free, or manual, where you set the account priority order yourself and uploads follow it.

### Does omnicloud need a database server?

No. File metadata is mirrored into SQLite for fast navigation, account synchronisation runs on a scheduled cron job with a configurable interval, and there is also a manual sync trigger plus delta sync reports through the health and sync layer.

### Can omnicloud run for multiple users?

Yes, by switching one environment setting to hosted mode, which enables register, login and logout over session cookies and scopes account data, file mirrors, allocation configuration and settings per user. Local mode is the single-user alternative.

### How do the MEGA, pCloud and S3 credentials reach omnicloud?

Through the user interface rather than the environment file. Those two password-based providers and the S3 access keys are entered in the browser and pass through the backend you are hosting, unlike the OAuth providers which use a redirect and a token.

### Does omnicloud have a test suite?

No. The root package script for tests is still the generated placeholder that prints that no test is specified and exits with an error, so treat the project as software you read and modify rather than software you upgrade.

## Sources

- [dimartarmizi/OmniCloud on GitHub](https://github.com/dimartarmizi/OmniCloud)
- [Issues](https://github.com/dimartarmizi/OmniCloud/issues)
- [License: MIT](https://github.com/dimartarmizi/OmniCloud/blob/main/LICENSE)
- [README](https://github.com/dimartarmizi/OmniCloud/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dimartarmizi-omnicloud