What Locker Actually Is

The Storage Provider Thing Is the Key Insight

Deploying Locker

What It Looks Like in Practice

Is It Ready for Production?

Further Reading 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. 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: The last one is either delightful or unnecessary depending on your personality. 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: 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. 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: 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: 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. 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. I write about cloud, security, privacy, and self-hosted infrastructure at alphasec.io. If Railway templates are your thing, I maintain a collection covering everything from starter kits to AI apps and security tools. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse