Joplin Cloud

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the sync server instead of paying for Joplin Cloud: my notes, end-to-end encrypted, synchronised between my own devices.

Read this first: Joplin itself is free and the apps are excellent — only the hosted sync is paid, and it costs very little. The cheapest honest alternative is not building anything: point Joplin at any WebDAV server or S3-compatible bucket you already have and you are done in ten minutes. Build this when you want the sync service to be yours, or when you want publish links and a web view alongside it.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Local disk or an S3-compatible target for the item blobs
- Caddy in front

THE HONEST APPROACH
- Speak a protocol the existing clients already know. Implementing the sync target that Joplin's own clients use means every app on every platform works on day one, with no client to build and no format to invent
- The alternative — a new sync protocol and your own apps for four platforms — is a year of work for the same result
- Read the client's sync algorithm before writing a line of the server. The server is deliberately simple; the intelligence is in the client, and fighting that is how this goes wrong

THE DATA MODEL
- users: id, email, password_hash, storage_quota_bytes, storage_used_bytes, created_at
- items: id, user_id, name, kind, size_bytes, blob_path, sha256, updated_time, created_time, is_deleted — the item is opaque ciphertext to the server
- deltas: id, user_id, item_name, kind, at — a monotonically ordered change feed, which is how a client asks 'what changed since'
- shares: id, item_name, owner_id, recipient_id, permission, accepted_at — a notebook shared between accounts
- publish_links: id, item_name, owner_id, token, password_hash, expires_at, view_count, revoked_at
- sessions: id, user_id, token_hash, device_label, created_at, last_used_at, revoked_at

ENCRYPTION, WHICH IS THE POINT
- The client encrypts before uploading. The server stores ciphertext and metadata and can decrypt nothing
- Never add a feature that requires the server to read a note. Server-side search over encrypted notes is impossible by construction, and the right answer is that the client searches locally
- The one exception is a published note, which the client decrypts and uploads as readable content deliberately. Make that a distinct, explicit action with a clear warning, and store those separately from the encrypted items
- The threat model in the README: what somebody with the database gets, what somebody with the disk gets, and what somebody with a session token gets

THE SYNC ENDPOINTS
- List changes since a cursor, get an item, put an item, delete an item, and a lock mechanism so two clients do not migrate the format at once
- Conditional requests and content hashes, so an unchanged item is not transferred
- Ordering by an increasing change identifier rather than by timestamp — clocks on devices disagree and a timestamp-ordered feed will skip changes
- Idempotent puts by item name and hash
- Quotas enforced on write with a clear error, not silently

CONFLICTS
- The server never resolves a conflict. It stores what it is given and reports the current state; the client creates a conflict copy
- That is the correct design and it must be resisted the first time it seems tempting to be clever

SHARING AND PUBLISHING
- A notebook shared with another account, with the key exchange happening between clients — the server passes an encrypted key and never holds a readable one
- A publish link with a long token, an optional password and an expiry, revocable, serving a static rendered page
- A published note is decrypted content on a server. Say so at the moment of publishing, in one sentence, and record which notes are published so nobody forgets

WEB VIEW
- Read-only, server-rendered, for published notes only. Nothing else can be shown, because nothing else is readable
- Markdown rendered on the server, sanitised, with attachments served from the same store

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, S3_*, MAX_ITEM_BYTES
- Migrations on boot, each once
- Nightly backup — which is safe to store anywhere, because it is ciphertext — and a tested restore
- Storage sweeper for orphaned blobs, run carefully: an over-eager sweeper deleting a live item is the worst bug this service can have
- Health endpoint reporting free space and the newest delta per user

WHAT MATTERS MOST
Protocol compatibility and the change feed. Get an existing client syncing against your server before adding anything of your own, and order the feed by a change counter rather than a clock. And be honest about whether this is worth it — for most people, pointing the client at a WebDAV server they already pay for is the whole answer.

Give me the repository, migrations, .env.example, a compatibility test suite that runs a real client against the server, and a README that opens with the WebDAV alternative.