Should I vibe code
Cloud attachment storage and sync for Zotero research libraries
The $20 a year is not storage. It is the thing that funds the free client you rely on.
?
Their verdict, the 2 GB price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
This is the one entry where "just run theirs" does not mean running their app, because the app is already free, open source and yours. What Zotero sells is the file half of sync, and Zotero's own documentation hands you the alternative: point the client at any WebDAV server and your personal library's attachments go there instead. So the build in front of you is not software, it is an operations job. Stand up a WebDAV endpoint and from that morning you own the durability of every PDF, annotation and page snapshot behind a decade of citations, plus the certificate, the disk, the offsite copy, and the protocol edge cases Zotero's docs explicitly decline to support. The version an agent will happily produce — its own WebDAV implementation, or worse, something that reaches into the data directory — is the actively dangerous one: Zotero states outright that keeping the data directory in a cloud-synced folder is extremely likely to corrupt the database, and a three-quarters-correct PROPFIND is the same mistake with a longer fuse. Two facts to hold before you start. Files in group libraries cannot use WebDAV at all, so the first collaborator puts you back on the paid plan. And $20 a year is not really a storage fee — the storage page says in as many words that these subscriptions are what fund the client you are relying on.
What actually breaks
not "if". the specific failures.
- The WebDAV implementation's long tail: Zotero writes a zip and a .prop file per attachment and expects PROPFIND, MKCOL, If-Match and 207 responses to behave, and a partial implementation surfaces as "file sync error" with nothing useful attached
- Your only copy, on the day the server is where attachments live and local copies were pruned to save laptop disk
- The backup you never restored from, which was the entire thing you were replacing
- Group libraries, which cannot use WebDAV — the moment research becomes collaborative you are buying storage anyway
- zotero.sqlite, if anything you build touches the data directory: Zotero's own docs call cloud-syncing that folder extremely likely to corrupt the database
- A conflict between two machines, where the losing version is gone unless you enabled object versioning before the first sync
- The TLS certificate, quietly, at renewal, while you are travelling with the laptop that has the smaller copy of the library
- Full-text search over attachments and web access to your PDFs from zotero.org, which are Zotero Storage features and simply do not exist on the WebDAV path
- Your own attention span, which is the actual dependency for a service with a five-year job to do
Is that you?
the verdict is a default, not a law
- It is one person's personal library and every machine keeps local copies of everything
- You already run a WebDAV server for other reasons and it is already backed up somewhere else
- You use a well-tested existing server rather than writing the protocol — rclone serve webdav, a Nextcloud instance, a maintained standalone daemon
- You have restored the whole library from your own backup at least once, deliberately, before cancelling anything
- The library is shared, because files in group libraries require Zotero Storage
- Anything you build reads or writes zotero.sqlite, or syncs the data directory as a folder
- The attachments are the primary record of work you cannot recollect — interview recordings, fieldwork scans, licensed PDFs you no longer have access to
- You are doing it to save $20 a year, which is not a reason, it is a rounding error against one lost afternoon
- The thesis is due this year
If you build it anyway
the checklist, then the prompt that enforces it
- Use an existing WebDAV server. Implementing the protocol yourself is the failure mode, and rclone serve webdav or a maintained standalone daemon gives you a compliant endpoint in an evening.
- Verify with Zotero's own "Verify Server" button, then test the ugly cases: a 400 MB attachment, a filename with an em dash and a colon in it, two machines editing the same item, and a full restore onto a clean profile.
- Enable object versioning and a lifecycle rule before the first sync, so a bad delete has a previous version to come back from.
- Nothing but Zotero touches the data directory. No Dropbox, no rsync of zotero.sqlite, no "just sync the whole folder" shortcut, ever.
- Leave "Download files at sync time" on for every machine you care about, so the server is a copy rather than the copy.
- Back the WebDAV store up somewhere that is not the WebDAV store, and restore from that backup once before you rely on it.
- HTTPS with a real certificate, and a password you use nowhere else: Zotero sends those WebDAV credentials on every sync from every device.
- If you must write code, write the export instead — a script that walks the library through Zotero's local API and lays attachments out in a dated tree with checksums. That is the artefact worth having.
I want to stop paying for Zotero Storage and sync my attachment files to storage I
control. Zotero supports WebDAV for personal libraries. The failure I care about is
losing or corrupting a research library that a decade of citations point at, so order
the work with recovery first and push back on anything clever.
1. Before anything else, build and run the export: a script that reads my local
Zotero library and copies every attachment into a dated tree with a checksum
manifest. I should be holding a verified full copy before we change a setting.
2. Then do a restore drill. Prove the export can rebuild the attachments for a clean
profile. If that does not work, stop; nothing after this point is safe.
3. Do not implement WebDAV. Configure an existing, maintained server. If I ask you to
write one, refuse and explain that Zotero expects PROPFIND, MKCOL, If-Match and
207 handling to be correct and reports every deviation as an unhelpful sync error.
4. Never touch the Zotero data directory or zotero.sqlite: no syncing that folder, no
direct writes, no copying it while Zotero runs. Zotero's own docs call cloud-syncing
that directory extremely likely to corrupt the database — quote them at me if I ask.
5. HTTPS with a valid certificate and a dedicated password in my password manager.
No plain-HTTP fallback, not even for testing on the LAN.
6. Turn on object versioning and a retention window on the storage behind the server
before the first sync runs.
7. Set up an offsite backup of the WebDAV store that is not on the same machine or
the same account, then restore one file from it to prove it works.
8. Keep "Download files at sync time" enabled on every device so each machine holds a
full local copy. The server must never be the only place a PDF exists.
9. Verify with Zotero's Verify Server button, then test a large attachment, a unicode
filename, and the same item edited on two machines. Group libraries are out of
scope because they cannot use WebDAV, and so is replicating zotero.org data sync,
which is already free and unlimited.
10. Finish by telling me what this costs in attention per year, and comparing it with
$20 for 2 GB or $120 for unlimited, given that those subscriptions are what fund
Zotero itself.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Almost always, and unusually cheerfully. 2 GB is $20 a year and unlimited is $120; a WebDAV box costs more than that in electricity and far more in attention, and the storage page says in plain language that these subscriptions fund Zotero's development, support and infrastructure — so this is the rare subscription where paying is also the thing keeping the free tool alive. Buy it outright if the library is shared, since group files cannot use WebDAV, if the attachments are irreplaceable, or if you would rather spend the weekend reading the papers than testing a restore.
$1.67/mo is cheaper than your weekend.
Zotero's exit is unusually good and the job is not to spoil it. The client is free, item data syncs to zotero.org for nothing, and attachments are ordinary files on disk. Keep "Download files at sync time" on, keep a checksummed export of the storage tree that is independent of whatever server you are running, and never allow the WebDAV box to be the only place a PDF lives. Going back is genuinely cheap — switch the file sync setting, reset file sync history, let it re-upload — which is measured in hours rather than in a migration, and is a large part of why building anything more ambitious than a WebDAV endpoint is hard to justify.
The client itself: mature, open source, actively developed, and free — the part you were never going to have to build.
The code behind zotero.org's own sync API, developed in the open and still committed to, but shipped with no README and no supported self-hosting path.
Its serve webdav command turns almost any storage backend into the WebDAV endpoint Zotero expects, without you writing the protocol.
Questions
Zotero is open source. Why can I not just self-host all of it?
You can host the file half and you do not need to host the other half. zotero/dataserver — the code behind zotero.org's API — is public and still being committed to, but it arrives with no README and no supported deployment path, and it exists to run one specific service rather than to be installed. You also would not gain much: item, note and tag syncing through zotero.org is free and unlimited. Files are the only metered part, and WebDAV is the documented way to move those.
Is WebDAV actually supported, or is it a hack?
Supported and documented, with two stated limits. It covers personal libraries only — files in group libraries always use Zotero Storage — and Zotero's developers say they cannot support third-party WebDAV servers, so any protocol quirk is yours to diagnose from a generic sync error. Zotero Storage additionally gives web access to attachments and better upload handling for some files, which are real features you give up.
Can I skip all this and put my Zotero folder in Dropbox?
No, and this is the one thing in the entry that is not an opinion. Zotero's documentation states that storing the data directory in a cloud storage folder is extremely likely to corrupt your database, because two clients writing a live SQLite file through a sync agent is precisely how you lose a library. If you want an external service to handle only the files, use linked files or WebDAV — never folder sync.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Saving is the weekend. Finding the thing you saved six years ago is the product you will not finish.
A citation is a claim, not a formatting flourish. Your retriever cannot tell you whether the page actually says it.
Its premium feature is still called GPT3 Summaries. That is the entire build-versus-buy analysis.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice