# Drivebase puts several cloud storage providers behind one desktop-style interface

> Drivebase is a self-hosted file management platform that connects Google Drive, S3 and the local filesystem, with any further providers added behind an IStorageProvider interface, and an interface that borrows from a desktop operating system rather than from a web dashboard. The parts that make it more than a file browser are preflight conflict analysis across providers, direct presigned uploads to S3, and a typed GraphQL API.

**drivebase/drivebase** — Drivebase is a cloud-agnostic file management platform for people and teams using multiple storage providers. 🚀 

- Repository: https://github.com/drivebase/drivebase
- Website: https://drivebase.io
- Stars: 595 · Forks: 54
- Language: TypeScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/drivebase-drivebase

## The interface is a desktop shell, and that is the design thesis

Drivebase is an open-source, self-hosted platform that connects your cloud storage providers, which the description lists as Google Drive, S3, local filesystem and more, under a single interface. You can browse, upload, transfer and manage files across providers without touching each service separately.

The interface decision comes next and it is what makes this project different from a file browser. The UI is designed as a desktop OS shell running in the browser. Apps, which are Files, Providers and Settings, open as windows you can move, resize and switch between, and the intent is that it feels like a native file manager rather than a typical web dashboard.

That is a real choice with real trade-offs. A web dashboard is denser, shows more rows at once and is better on a small screen. A windowed shell is more forgiving on a large screen, gives you room to have a file list and a properties panel open at once, and makes multi-provider work feel less like a form.

The tagline is your cloud storage, one desktop, runs anywhere, and the homepage carries a hosted cloud offering alongside the self-hosted path.

The project is TypeScript, MIT licensed, with the last push on 2026-06-03 and a release v4.0.0 on the same day, preceded by two v4.0.0 alpha builds in April. The package version in the repository is 4.0.0-beta.1, which is worth noticing against the v4.0.0 tag, since the repository and the published tag are not quite at the same point.

## Installing with Docker is the short path

The quick install is a single command in a terminal:

```bash
curl -fsSL https://drivebase.io/install | bash
```

That creates a drivebase/ directory containing Docker Compose and a pre-configured config.toml with the secrets auto-generated. After it finishes:

```bash
cd drivebase
docker compose up -d
```

And then you open http://localhost:4000.

The auto-generated secrets are the part worth pausing on. A configuration file with a master key and an authentication secret already filled in means the installer is generating them for you, which removes the most common way a self-hosted deployment ends up insecure.

This is a different route from the development setup, and the documentation is clear that both exist. The quick install gives you a running deployment with generated secrets. The getting started section is the developer path, which starts from the repository.

The repository itself is a monorepo, and the layout shows the structure. There are apps/ for the applications, packages/ for the shared code, and within packages there are providers/, apps/ and config/. The root carries a compose.yml and a compose.prod.yml for the two deployment shapes, a Dockerfile, a turbo.json for the task runner, a bun.lock, a var/ directory, scripts/ and a config.example.toml.

So the same repository produces the Docker image you run, and the difference between compose.yml and compose.prod.yml is presumably the development and production configurations of the same stack.

## Cross-provider batch operations, and the preflight that makes them safe

The feature list has eleven entries and the interesting ones are the ones about moving data between providers.

Batch operations cover copy, move, transfer and delete across providers, with preflight conflict analysis. That phrase is the interesting one. When a copy or a move spans two providers, the failure modes are much wider than on a single filesystem: the destination may not exist, the path may not be writable, the object may already be there with different content, the source and destination may be the same provider where the operation is not atomic, and a partial transfer may leave both sides in a state you have to reason about.

A preflight analysis is the step that works out those conflicts before anything moves, and the companion feature is smart conflict resolution, which detects conflicts before they happen and resolves them with overwrite, skip, rename or manual review.

Those four resolution choices are a sensible set. Skip is the safe default. Rename is what you want when the destination is a versioned archive. Overwrite is what you want when you know the source is newer. And manual review is the escape hatch when the tool cannot tell, which is exactly the case where an automatic decision would be wrong.

Real-time progress is delivered via server-sent events with no polling required, so a transfer of a large file between two providers shows movement rather than a spinner. The GraphQL API exposure means the same capability set is available to anything else you build, and the typed GraphQL API is a deliberate choice over a REST surface, which suits a client with several apps talking to it.

Storage usage tracking with per-provider quota and on-demand refresh is the piece that answers the question people actually ask, which is how much room is left in each provider.

## The provider list tells you what it is built around

The supported providers list uses checkboxes, and reading which are ticked and which are not is informative.

Done are Google Drive, AWS S3 and S3-compatible services, with the examples named being Cloudflare R2, Wasabi, Backblaze B2 and MinIO, the Local Filesystem, Dropbox and OneDrive. Not done are Box, Azure Blob Storage and SFTP.

The S3-compatible list is the interesting part, because it covers the object storage services that behave like S3 without being S3. R2 for Cloudflare, Wasabi and Backblaze B2 as alternative S3 providers, and MinIO as the self-hosted one. For anyone with files spread across those, Drivebase is a single interface over what is effectively one API.

The unchecked entries show the direction of travel. Box and Azure Blob Storage are the two large providers missing, and Azure Blob in particular is the one a lot of enterprises have data in. SFTP is the odd one out, because it is a protocol rather than a storage service, and supporting it means a different kind of provider implementation, the kind that has sessions and file handles rather than object keys.

The pluggable provider system is what makes those additions plausible. The clean IStorageProvider interface makes adding new backends straightforward, so the unchecked boxes are a queue of work rather than a design limitation.

The stack behind it is worth noting for anyone running it. The runtime is Bun, the frontend is React 19 with Vite, TanStack Router and Tailwind CSS 4, the API is GraphQL Yoga with graphql-sse for subscriptions, workers are BullMQ, the database is PostgreSQL with Drizzle ORM, Redis with ioredis handles cache and queue, and auth is Better Auth with cookie-based sessions.

That combination explains the real-time progress and the resumable uploads. BullMQ is what runs the transfers as background jobs, and graphql-sse is what streams their status back.

## Running it from source for development

The getting started path is for anyone who wants to work on the code rather than deploy the image, and it starts with the prerequisites.

You need Bun 1.3.5 or later, PostgreSQL 15 or newer, and Redis 7 or newer. The clone and install is:

```bash
git clone https://github.com/drivebase/drivebase.git
cd drivebase
bun install
```

Then the configuration, copied from the example:

```bash
cp packages/config/config.example.toml config.toml
```

And the minimum required values are given in full:

```toml
[server]
env = "prod"
port = 4000
host = "0.0.0.0"

[db]
url = "postgres://user:password@localhost:5432/drivebase"

[redis]
url = "redis://localhost:6379/0"

[crypto]
# Generate: openssl rand -base64 32
masterKeyBase64 = "<base64-encoded-32-byte-key>"

[auth]
# Generate: openssl rand -hex 32
betterAuthSecret = "<random-secret>"
baseUrl = "http://localhost:4000"
trustedOrigins = ["http://localhost:3000"]
```

Two secrets have to be generated rather than copied. The master key is a base64-encoded 32-byte key generated with `openssl rand -base64 32`, and the auth secret is a random hex value from `openssl rand -hex 32`.

The trustedOrigins list is the third thing to think about, because it is the list of origins the auth layer will accept requests from. The example lists the web UI's development port, and when you deploy you need that to match the address people will actually use.

After configuration, the migrations run with `bun run db:migrate` and the development servers start with `bun run dev`. That gives an API on http://localhost:4000 and the web UI on http://localhost:3000, which is why the production port and the development port differ between the two sections of the documentation.

The root package scripts show the task structure. Everything is a turbo task, build, dev, lint, format and typecheck, and the dev script filters to the api, web and workers packages. The database scripts are delegated to the db package with bun --cwd, and the release script runs release-it with --no-npm, so the release is cut from the repository rather than published to a registry.

The workspaces list is apps/*, packages/*, packages/providers/* and packages/apps/*, which is where the provider implementations and the individual apps live.

## The two upload paths, and why the direct one matters

Two features decide how much traffic your server sees, and they are worth separating.

Resumable uploads means chunked upload sessions that survive browser reloads. That is the difference between a large file upload failing at the last megabyte and resuming. The sessions are held server side, so the client can ask where it got to.

Direct S3 uploads is the more significant one. Presigned multipart URLs let clients upload straight to S3, bypassing the server. The file goes from the browser to the bucket, and your server only signs the request and records the outcome.

That changes the architecture of a transfer in a way that matters at scale. Without it, every byte uploaded passes through your server, which means your bandwidth, your memory and your request handling are all proportional to the size of what people upload. With it, the server sees metadata about the upload rather than the upload itself.

It also changes the security surface, and this is the part to be deliberate about. A presigned URL is a capability handed to the client, valid for a bounded time and scoped to a particular key and a multipart upload. If your S3 bucket policy is loose, the client can upload more than it should, or to keys you did not intend. The bucket policy and the key naming both need to be right for that path to be safe.

The remaining features are the smaller ones. Storage usage with per-provider quota tracking is there, the GraphQL API exposes every capability, and the provider system is the extension point.

So the practical summary of the design is that Drivebase is a control plane over your storage rather than a data plane. It decides what should be where, records what happened, and streams progress, while the bytes move provider to provider without necessarily passing through it.

## Conclusion

Adopt Drivebase if you have files spread across several providers and want one place to browse them, move things between them and watch the operations run, since that is the workflow it is built around. Skip it if you want a simple sync client, since this is a platform with a database, a queue and a web interface rather than a background daemon, and if you cannot run Bun, Postgres and Redis yourself. Verify first which providers you actually need, because the supported list has both completed and unchecked entries, that you generate the two secrets the configuration requires rather than copying the placeholders, and that you understand the direct S3 upload path means the browser talks to your bucket and not to your server for those transfers.

## FAQ

### How do I install Drivebase?

Run `curl -fsSL https://drivebase.io/install | bash`, which creates a drivebase/ directory with Docker Compose and a pre-configured config.toml whose secrets are auto-generated. Then run `docker compose up -d` inside that directory and open http://localhost:4000. To run it from source instead, clone the repository, run bun install, copy packages/config/config.example.toml to config.toml, run `bun run db:migrate` and then `bun run dev`.

### Which storage providers does Drivebase support?

Google Drive, AWS S3 and S3-compatible services including Cloudflare R2, Wasabi, Backblaze B2 and MinIO, the local filesystem, Dropbox and OneDrive are supported. Box, Azure Blob Storage and SFTP are listed but not yet done. The provider system is built around a clean IStorageProvider interface so new backends can be added.

### What does Drivebase do when a cross-provider transfer conflicts?

Batch operations across providers include preflight conflict analysis, and conflicts are detected before they happen. Resolution options are overwrite, skip, rename or manual review. Transfers run as background jobs through BullMQ and report live status over server-sent events, and uploads are chunked and resumable, or go straight to S3 via presigned multipart URLs.

## Sources

- [drivebase/drivebase on GitHub](https://github.com/drivebase/drivebase)
- [Issues](https://github.com/drivebase/drivebase/issues)
- [Project website](https://drivebase.io)
- [README](https://github.com/drivebase/drivebase/blob/main/README.md)
- [Releases](https://github.com/drivebase/drivebase/releases)

---

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