Vibe code your own Dropbox — vibecode it yourself

You can vibe code your own Dropbox as folders, uploads, and a signed download link you can revoke. The catalog calls Dropbox that loop, a private library you host.

You pay $9.99–$24 a person a month. The card says that price scales with the team. The verdict is “A folder you host”.

Last time I wrote about vibe coding your own Readwise. That was a regular backlog post. This one is a teardown.

Vibe code your own Dropbox as a folder

The Dropbox page splits the work into three rows.

The first row is 8 hours. Folders, uploads, signed download links. That is a tree, a private object, and a URL that expires. You can vibe-code this.

The second row is 3 days. Share links with expiry, search, replace-or-keep, an audit log. Still your library. A revoke button. A prompt when invoice-oct.pdf already sits in /Clients/bootcamp.

The third row is 1 month and up. Desktop sync, conflict copies, previews for every format. Skip that row.

If you tell an agent to “clone Dropbox”, it aims at the third row. The useful v1 is the first one.

Here is the shape of the data.

const folder = {
  id: 'folder-clients',
  parentId: null,
  name: 'Clients',
}

const file = {
  id: 'file-invoice-oct',
  folderId: 'folder-clients',
  name: 'invoice-oct.pdf',
  objectKey: 'u-ada/folder-clients/invoice-oct.pdf',
  size: 184320,
  contentHash: '485291fa0ee50c016982abbfa943957bcd231aae0492ccbaa22c58e3997b35e0',
}

const share = {
  id: 'share-invoice-oct',
  fileId: 'file-invoice-oct',
  token: 'lk_bootcamp_oct',
  expiresAt: '2026-11-12T09:00:00.000Z',
  revokedAt: null,
}

A folder, a file row, later a share token. The bytes live in object storage. The page never points a browser at a public bucket.

The audience on the page is one person keeping work files in a private library they host.

The same v1 also replaces Google Drive, OneDrive, and Box if what you wanted was “upload this, find it later, send a link”. Dropbox Transfer is the one-shot cousin at $20–$32 a month, 3 hours. DocSend is the gated PDF at $65–$180. I already wrote that post. Cloudinary is images you resize later, $89–$249.

How does Dropbox work

Dropbox publishes the API, a content-hash spec, and a few engineering posts about storage and the desktop client. I am summarizing those pages, not reconstructing today’s cluster.

The public file model is a path plus metadata. The list_folder call is POST /2/files/list_folder. You send a path such as /Homework/math. Set recursive if you want every child. The response is entries, a cursor, and has_more. When has_more is true you call list_folder/continue. A v1 can SELECT the files in one folder.

Each file carries a content_hash, a rev, and server_modified. The content hash is public. Split the file into 4 MB blocks (4,194,304 bytes). SHA-256 each block. Concatenate those 32-byte hashes. SHA-256 that concatenation. Hex-encode it. An empty file has no block. Their example is 9,711,423 bytes, three blocks, hash 485291fa0ee50c016982abbfa943957bcd231aae0492ccbaa22c58e3997b35e0. Store that hash on the row. Before a replace, hash the new upload. Skip the write if it matches.

Uploads split on size. The performance guide says /2/files/upload is for files under 150 MB. Bigger files use an upload session: start, append_v2, then finish. They tell you to send chunks in multiples of 4 MB.

The same guide is honest about writes. A user’s private folder is a namespace. A shared folder is another one. A write locks that namespace, commits, then releases. Too many parallel writes return HTTP 429 with reason too_many_write_operations. /2/files/upload appends, locks, and commits in one call. An upload session appends first, then commits once. A batch can hold 1,000 entries. They do not publish exact rate-limit numbers. A 429 with too_many_requests includes Retry-After.

A v1 does not need their namespace table. One owner, one tree, one write at a time. Persist the row, then sign a download.

Shared links are a second object. The current create call is /2/sharing/create_shared_link_with_settings. You pass the path after the upload finishes. A v1 copies the idea. A token, an expiry, a revoke time.

The bytes sit somewhere else. Inside the Magic Pocket is the public storage picture, from May 2016. Files split into encrypted chunks up to 4 MB. A block never changes after the write. Mutations live in a separate system they called FileJournal. Treat “the 2026 metadata store is still named FileJournal” as an educated guess. Immutable blocks below, a journal of changes above.

That post puts clusters in the western, central, and eastern United States. Each block is stored in at least two zones. Frontends accept puts and gets. A Block Index maps hash → cell, bucket, checksum on sharded MySQL. Cells were about 50 PB then. Cross-zone replication aimed to copy a new block within one second.

A v1 does not need cells. Put the object in R2. Put the row in D1. That is the stack on the card.

The v1 path: authorize, write a row, store a private object, then mint a signed download.

Screens of a Dropbox alternative

Three surfaces for v1. If the agent starts matching Dropbox’s live UI, send it back.

The folder is home. Breadcrumb, usage, an upload button. Each row is a folder or a file. Name, size, uploaded time. Open a folder. Download uses a signed URL. Search can wait three days if the tree is short.

Home is the folder. Download and share sit on the file row.

The upload screen is a file picker and a destination. If the name already exists, stop. Offer replace or keep. Keep writes invoice-oct (2).pdf. Do not overwrite in silence. The guardrail on the card is the useful sentence: keep objects private, serve downloads only through short-lived signed URLs, and authorize every list and write by owner.

Same name stops the write. The person picks keep or replace.

The share screen is a token, an expiry, and revoke. The recipient page shows the file name and a download button. It does not list the rest of the library. Passcodes wait three days if you want them.

The share page is one file. Revoke kills the token. The bucket stays private.

How a Dropbox alternative upload works

The loop is pick a folder, upload, maybe share, download later.

You choose /Clients and invoice-oct.pdf. The app checks the owner, hashes the bytes, and writes the object under a key the browser cannot guess. Then it writes the row. Then it returns the folder. Share is a second request. It mints lk_bootcamp_oct and an expiry. Download signs the object for a few minutes. Revoke sets revokedAt. The next download 404s. It does not delete the file.

The 8-hour v1 is folder, private upload, row, optional share, signed download.

Search is file names in the tree you already loaded. Previews are the skip row. The performance guide points apps at /files/get_thumbnail so they do not download a raw PDF to show a page. Your v1 can say “download the file”.

The hard half of a Dropbox alternative

The skip row starts when a folder on disk has to match the folder in the cloud.

Rewriting the heart of our sync engine is the public picture of the desktop client. In March 2020 they said they had shipped a new engine, Nucleus, to every Dropbox user. They wrote it in Rust. Almost all of the logic runs on one Control thread. Network IO, hashing, and filesystem IO leave that thread. The Control thread is deterministic when its inputs and schedule stay fixed, so they can fuzz it with a seed. Treat “the 2026 desktop client is still this Nucleus process” as an educated guess.

The testing post is the data model. Nucleus keeps three trees. Remote is the latest Dropbox in the cloud. Local is the last observed folder on disk. Synced is the last known fully synced state, a merge base. If Local matches Synced and Remote added /foo/fum, the file came from the cloud. Without Synced you cannot tell that apart from a local delete. Nodes have globally unique ids. A rename is a move. The protocol refuses orphan files. A client cannot learn about /baz/cat before it has /baz.

That is why conflict copies exist. Two devices edited offline. Both trees diverged from Synced. Automatic merge of arbitrary binary files is not a weekend. The catalog puts that work on the month-plus row on purpose.

Obsidian Sync is the cousin if the rent is a notes vault, $5–$10 a month. I already wrote that teardown. Versioned files are 2 days. Automatic merge is the other product. Dropbox is the same split, for every file type.

Ship the folder, the object, and the link. Leave the sync engine and the preview farm on the skip row.

I would rebuild Dropbox for the client files I already keep in one laptop folder. /Clients/bootcamp, invoices, a zip of brand files. A signed link when someone needs a copy.

Search comes after I cannot find a file by clicking. I would not sync a desktop folder. I would not preview a Photoshop file in the browser.

Host it next to the product, on Node.js and Astro, with HTMX on the folder page and R2 for the bytes, because that is the stack on the card. Use TanStack Start if React is your weekday language. The hosting post already says signed URLs and private objects. Persist folders and share tokens in D1.

If the rent is “send a zip once”, that is Dropbox Transfer, 3 hours. If they should open the PDF in a browser, that is DocSend, 4 hours.

Start with the first row

Go to Build your own Dropbox. Copy the Astro prompt, or TanStack Start if that is what you write.

Tell the agent the first estimate only: folders, uploads, signed download links. Eight hours.

If the company already lives in a desktop folder that has to stay correct on every laptop, keep paying.