A Developer Built an Open-Source Dropbox on a Dare. Here's How to Self-Host It.

Alphasec — Tue, 21 Apr 2026 16:23:55 +0000

A few weeks ago, @swyx nerd-sniped @zachmeyer into building an open-source Dropbox. Zach took it seriously, and the result is Locker: a self-hostable file storage platform that covers most of what you'd actually use Dropbox or Google Drive for, without the subscription or lock-in.

I came across the thread on X, spent some time getting Locker running on Railway, and figured the deployment notes were worth writing up — especially since the setup has a few non-obvious pieces that trip you up if you're looking to self-host.

What Locker Actually Is

Locker is a Dockerized Next.js application backed by PostgreSQL. The GitHub repo is worth a look — the tech stack is modern and clean: Next.js 16 App Router, tRPC for end-to-end type safety, Drizzle ORM, BetterAuth, and Tailwind CSS, organized as a Turborepo monorepo with pnpm workspaces.

Feature-wise it covers the things you'd actually miss from the commercial alternatives:

File and folder management — upload, rename, move, delete, with a familiar explorer UI
Share links — password protection, expiry dates, and download limits per link
Upload links — let anyone send you files without an account, useful for collecting documents from clients or collaborators
Storage provider agnostic — switch between local disk, AWS S3, Cloudflare R2, or Vercel Blob via a single environment variable, no code changes required
Locker as an S3 bucket — generate Locker API keys and use them in other applications to write data directly to your Locker instance; it speaks S3-compatible protocol
Per-user storage quotas — set limits per user with usage tracking
Workspace teams — invite team members with role-based access and organise files across workspaces
QMD semantic search (optional plugin) — search inside the content of your files, not just filenames
FTS full-text search (optional plugin) — full-text search across your stored documents
Email/password and Google OAuth — authentication handled by BetterAuth, sessions managed server-side
API keys — programmatic access for building integrations and automating workflows
Virtual bash shell — navigate your file tree with ls, cd, find, cat, and grep via a terminal panel; reads your actual stored files lazily from the configured storage provider

The last one is either delightful or unnecessary depending on your personality.

The Storage Provider Thing Is the Key Insight

Most self-hosted file storage tools tie you to a specific backend. Locker doesn't. You set BLOB_STORAGE_PROVIDER in your environment and point it at wherever you want files to live:

Provider	Value	What you need
Local disk	`local`	Just a directory path
AWS S3	`s3`	Access key, secret, region, bucket
Cloudflare R2	`r2`	Account ID, keys, bucket
Vercel Blob	`vercel`	A read/write token

If you already have an S3 bucket, you can point Locker at it and immediately have a UI over your existing data. If you're starting fresh, local disk works out of the box. Switching later is one variable change.

Deploying Locker

Locker is designed to run with Docker Compose — a migrate container runs the database migrations first, then the web container starts once migrations complete. That's the intended flow.

Deploying to Railway takes a bit more work because Railway runs a single container rather than orchestrating multiple services. I spent some time getting this right: the key issue is that migrations need to run before the app starts, and the Dockerfile in the repo builds a Next.js standalone output that doesn't include the migration tooling in the final image by default.

The solution was a custom Dockerfile.railway that copies the migration dependencies into the runner stage and runs them as part of the startup command:

CMD ["sh", "-c", "cd /app/packages/database && pnpm drizzle-kit migrate && cd /app && node apps/web/server.js"]

Drizzle tracks which migrations have already been applied, so this is idempotent — subsequent deploys only apply new migrations and skip the rest.

If you want to skip all of this and just get a running instance, I published a one-click Railway template that handles everything automatically — Postgres, volume for file storage, migrations on startup, and all the required environment variables pre-configured:

What It Looks Like in Practice

After deployment you get a clean file management interface, workspace support for teams, and the ability to generate share links for any file or folder. The virtual bash shell is accessible via a terminal panel and lets you navigate your file tree with standard Unix commands — which turns out to be genuinely useful when you want to script something against your stored files.

Authentication supports email/password out of the box, and you can add Google OAuth by dropping in GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET.

Is It Ready for Production?

For personal use and small teams, maybe yes. For a large organisation relying on it as primary infrastructure, I'd want to see more production mileage first — the project is still relatively young. That said, the tech choices are solid, the codebase is readable, and the maintainer is active.

The hosted version at locker.dev is available if you want to try it before committing to self-hosting.