Self-host a bookmark manager on Cloudflare

Why most self-hosted bookmark lists assume a server

Roundups of self-hosted bookmark managers, such as linkding, Linkwarden and Shiori, mostly start from a Docker host or a VPS you keep patched and backed up. That is a fair choice if you already run one. If you do not, the server is the main cost of self-hosting a bookmark manager, not the software.

CloudMark is built the other way round. Its pinned configuration declares a single Cloudflare Worker and one D1 database. This guide goes through what that configuration contains, what you would need to change before running your own copy, and where it stops short of a SaaS like Raindrop.io.

What CloudMark's pinned config declares

Our snapshot is pinned to commit 7a3ee47. In wrangler.jsonc at that commit:

• One Worker (./src/worker/index.ts, built with Hono) serves the API.
• A DB binding to D1, which holds collections, bookmark rows, token hashes and rate-limit rows.
• An ASSETS binding for the bundled React frontend, with single-page-app fallback. Requests to /api/* run the Worker first; everything else is served as static assets.
• No R2, KV, cron triggers or external services in the core deployment.

The architecture diagram on the project page is derived from this file. It shows declared infrastructure, not a deployment we ran.

What to change before you deploy your own copy

The repository ships with the author's identifiers. Replace them with your own:

1. Create your own D1 database and put its ID in the DB binding.
2. Replace the author's custom-domain routes and BASE_URL. A workers.dev address avoids buying a domain.
3. Apply every D1 migration to your database before the first deploy.
4. Back up the data and your write tokens, since there is no account recovery.

The optional Chrome extension is a separate, unpacked install and was not audited. Favicons load through Google by default, so treat them as an external request.

What it replaces from Raindrop.io, and what it does not

In our catalog, CloudMark is mapped to Raindrop.io for a narrow job: saving URLs with titles and notes, organizing them by category, and filtering and searching a personal collection. The Raindrop.io alternatives page has the wider comparison, so it is not repeated here.

We did not establish these features in CloudMark, so do not plan around them. We have not reviewed Raindrop.io's documentation for them, so compare against its own docs:

• tags
• full-text search of saved pages
• permanent copies of pages
• automated broken-link checks
• team permissions and private read-only invitations

The demo screenshot on the project page comes from the author's seeded demo. We searched it read-only. We did not save bookmarks, install the extension or test a fresh deployment.

Access and privacy: read this before saving anything private

Collections default to public: anyone who knows the URL can read them. The source supports private collections that require the same token that allows writes, but there are no user accounts and no separate read-only invitations.

Write tokens are kept in browser localStorage and in the bookmarklet. The bookmarklet sends the token in a query string, so it can end up in browser history and access logs. Some legacy collections can issue a write token on the first read until their migration is finished, so review that path before exposing an old collection URL.

Cloudflare free-tier limits that matter here

Free hosting is conditional, not guaranteed. The relevant published limits at the time of review:

Resource	Free allowance	Why it matters for CloudMark
Worker requests	100,000 per day, account-wide	Every API call counts; static assets are free and unlimited
Worker CPU	10 ms per invocation	Token hashing and bulk imports need measuring
D1 rows read	5 million per day	A collection read loads all its bookmarks, so filtering in the browser does not cut the database scan
D1 rows written	100,000 per day	Imports, rate-limit rows and index updates all write
D1 storage	5 GB total, account-wide	Not the constraint for a small collection

The source limits a collection to 1,000 bookmarks and an import request to 500 items. If those caps suit you, a personal collection fits inside the free plan on paper. We have not measured it, and the limits behave differently. Daily read and write quotas reset each day. Storage does not reset, so you would need to delete data or upgrade. Your domain, backups and maintenance time are separate costs.

Checklist before you rely on it

1. Deploy to workers.dev with your own D1 database and migrations.
2. Create a collection and decide public or private on purpose.
3. Import a small export, then confirm the count and categories.
4. Check search against links you know are saved.
5. Open the collection URL in a private window to see what a stranger can read.
6. Read the AGPL v3 license guide if you change the code and share the result.