@QingQ77: FlareMo — A Cloudflare-native personal knowledge management system https://github.com/realchendahuang/FlareMo… A personal note-taking system running on Cloudflare Workers, leveraging Cloud…

FlareMo — A Cloudflare-Native Personal Knowledge Management System https://github.com/realchendahuang/FlareMo… A personal note-taking system running on Cloudflare Workers, leveraging Cloudflare’s free tier (D1 database + R2 object storage) for zero server maintenance. It offers a Flomo-style timeline note experience with support for tags, attachments, search, archiving, trash, public share links, and is compatible with a subset of the Memos /api/v1 API. — # realchendahuang/FlareMo Source: https://github.com/realchendahuang/FlareMo # FlareMo A personal note-taking system that runs 24/7 in the cloud with just one free account. Native Cloudflare deployment, complete with database and object storage. Login using your own Cloudflare account, and it retains a Memos-compatible API for external tools. GitHub stars (https://github.com/realchendahuang/FlareMo) license Powered by Cloudflare (https://www.cloudflare.com/) Memos compatible (https://github.com/usememos/memos) English Deploy to Cloudflare (https://deploy.workers.cloudflare.com/?url=https://github.com/realchendahuang/FlareMo) The screenshots show the current backend-connected timeline, editing, filtering, and mobile navigation experience. Unimplemented features like AI review, semantic search, and WeChat input will not appear in the interface. — ## Why This Project Flomo proved that a lightweight note-taking experience (“quick capture + quiet timeline”) is valuable. But self-hosting such a system usually means a VPS, a Postgres, a bunch of Docker containers, a backup script to maintain weekly, and the risk of data loss if the hard drive dies. FlareMo aims to answer a different question: Can you have a personal note-taking system that runs 24/7 online, never loses data, supports custom domains, and can be called by various tools, using only a free Cloudflare account, without buying a server, installing a database, or writing backup scripts? The answer is yes. A free Cloudflare account provides: - Cloudflare D1: 5 GB database — stores notes, tags, relationships, shares, settings. - Cloudflare R2: 10 GB object storage — stores attachments, images, export packages. - Cloudflare Workers: free request quota, global edge nodes — code and front end run on the nearest node. - Cloudflare Access: login with your own Cloudflare account — no need for a separate username/password or Bearer token within the app. - Workers Static Assets — front end and API served by the same Worker, deployed in one go. The entire system runs on a single Worker. There is no “server” to maintain, just one piece of code and one free account. — ## How Much Can That Free Tier Actually Handle? Many people have no sense of scale for 5 GB database / 10 GB object storage, assuming “free” means “insufficient”. In reality, for personal note-taking with very low write volume and mostly plain text, the free tier is more than enough. 5 GB D1 Database: - A typical note (including tags, timestamps, index overhead) is about 2 KB, so 5 GB can store approximately 2.5 million notes. - Even if you write 100 notes per day, that’s 68 years worth. - In practice, most people never write 5 GB of plain text notes in their lifetime. 10 GB R2 Object Storage: - A compressed phone photo is about 1–2 MB, so 10 GB can hold roughly 5000–10,000 images. - Or about 80 hours of medium-bitrate voice memos. - R2 egress traffic is free, so sharing images with others incurs no data charges. In other words, the free tier is not a ceiling you’ll hit quickly, but a capacity you’ll most likely never exhaust. — ## Why Running on Cloudflare Is More Reliable Than Running on a NAS Self-hosting also has a frequently underestimated cost: physical data security. - NAS / self-built server: Data lives on a hard drive in your home. Hard drives fail, power surges happen, leaks and theft are possible, and moving can cause damage. Even with RAID, you’re only delaying a single drive failure; it won’t protect against the entire machine or room being compromised. Offsite backups require separate setup. - Cloudflare: D1 and R2 data is persisted by Cloudflare on enterprise-grade infrastructure with built-in redundancy. You don’t need to buy a second hard drive, write cron backup scripts, or monitor disk SMART alerts. Cloudflare won’t lose your data because your home loses power. This doesn’t mean you shouldn’t export your data—FlareMo supports Memos-format export packages, and keeping a local copy of important data is always a good practice. But the daily anxiety of “will my notes be gone tomorrow?” is taken care of by Cloudflare. Additionally, Cloudflare provides several things that are hard to get all at once with self-hosting: - Global edge network: You and your friends in different countries both access the nearest node. - Free HTTPS and custom domain: Just bind a domain, and certificates auto-renew. - No tunneling needed: No frp, no Tailscale, no public IP required—share links can be sent directly to others. - Zero maintenance: No system patches, no database upgrades, no watchdog processes. — ## What Works Now - Quick note capture with tags and attachments. - Timeline, archive, and trash. - Search, tag filtering, activity heatmap. - R2 attachment storage. - Public share links. - Memos data import/export. - Memos-compatible subset of /api/v1 for memo / attachment / share. - OpenAPI output. - MCP endpoint. - Chinese and English interfaces. The front end only shows entry points for features that are currently connected. Unimplemented features like AI review, semantic search, random walk, and WeChat input won’t appear in the UI. — ## Deployment: One Click or Let an Agent Do It Deploying FlareMo is intentionally lightweight. Choose one of two methods. Method 1: One-Click Deploy Button Click the “Deploy to Cloudflare” button above. Cloudflare will read wrangler.jsonc, create the Worker, and generate D1/R2 bindings. After deployment, run a remote migration: bash pnpm migrate:remote If your Cloudflare Dashboard isn’t already connected to GitHub or GitLab, Cloudflare will ask you to connect your Git provider. This OAuth authorization is confirmed by you within the Cloudflare page; FlareMo never requests an in-app token. Method 2: Let an AI Agent Deploy for You The repository includes a docs/agent-deploy.md file—a deployment runbook designed for AI agents like Codex, Claude Code, or Cursor. Give the repo to an agent that can execute commands, and it will follow the runbook to create D1/R2 resources, fill in database_id, run migrations, and deploy. You don’t need to memorize commands; the agent follows the steps. Manual Deployment (if you prefer to do it step by step): First, create the resources: bash pnpm exec wrangler d1 create flaremo pnpm exec wrangler r2 bucket create flaremo-attachments Write the database_id from the D1 output into wrangler.jsonc, then run: bash pnpm verify pnpm deploy:dry-run pnpm migrate:remote pnpm deploy Full deployment instructions in docs/deploy.md. English instructions in docs/en/deploy.md. Deploy Button test results in docs/deploy-button-test.md. Pre-Deployment Checklist - Wrangler is logged into the target Cloudflare account: pnpm exec wrangler whoami. - The D1 binding in wrangler.jsonc is DB and contains the correct database_id. - The R2 binding in wrangler.jsonc is ATTACHMENTS and the target bucket exists. - Remote D1 migrations will be executed after the first deployment: pnpm migrate:remote. - A Cloudflare Access application is configured for human access, Service Tokens, and public share bypass paths. - Before publishing, run: pnpm verify and pnpm deploy:dry-run. — ## Login: Use Cloudflare Access, No In-App Tokens FlareMo does not accept in-app Bearer tokens for login. The production access boundary is handled by Cloudflare Access: - Humans use Access login and allow policies (supports Google, GitHub, SSO, one-time PIN, etc.). - Scripts, Memos-compatible clients, MCP use Access Service Tokens. - Public share paths have separate Access bypass configurations. This means you don’t have a second set of credentials to remember, and there’s no app-level token stored in the database. Who can access is determined by the unified boundary of Cloudflare Access. Example script access: bash curl "$FLAREMO_URL/api/v1/memos" \ -H "CF-Access-Client-Id: $FLAREMO_ACCESS_CLIENT_ID" \ -H "CF-Access-Client-Secret: $FLAREMO_ACCESS_CLIENT_SECRET" Example MCP access: bash curl "$FLAREMO_URL/api/v1/mcp" \ -H "content-type: application/json" \ -H "CF-Access-Client-Id: $FLAREMO_ACCESS_CLIENT_ID" \ -H "CF-Access-Client-Secret: $FLAREMO_ACCESS_CLIENT_SECRET" \ --data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' Recommended public bypass paths: - /share/* - /api/public/shares/* - /assets/* Shared content is still validated by FlareMo’s share token, expiration time, and memo status. — ## Tech Stack - Runtime: Cloudflare Workers - Web: React, Vite, Tailwind CSS, shadcn/radix primitives - API: Hono-style Worker routes, Zod contracts, OpenAPI - Database: Cloudflare D1, Drizzle - Object storage: Cloudflare R2 - Auth boundary: Cloudflare Access - Package manager: pnpm D1 is the source of truth for business data (notes, users, tags, shares, relationships, etc.). R2 stores only attachments, export packages, and object files. KV, Vectorize, Workers AI, Queues/Cron are only integrated when the corresponding feature is actually implemented; they do not replace D1. ## Architecture mermaid flowchart LR Browser["FlareMo Web UI"] --> Worker["Cloudflare Worker"] Clients["Memos-compatible clients / scripts / MCP"] --> Worker Worker --> D1["D1: memos, users, relations, shares, settings"] Worker --> R2["R2: attachments and exports"] Worker --> Assets["Workers Static Assets"] A single Worker serves both the API and front-end static assets. D1 holds authoritative data; R2 stores attachments. The Memos compatibility layer is an adapter, not the original Memos server running on Workers. — ## Memos Compatibility FlareMo retains the core entity model of Memos, aiming to reuse Memos clients, scripts, import/export, and ecosystem tools, rather than porting the original Memos Go server. Entities retained: users/{id}, memos/{id}, attachments/{id}, memo payload/property, relations, shares, settings. Current public API subset: - POST /api/v1/memos - GET /api/v1/memos - GET /api/v1/{name=memos/*} - PATCH /api/v1/{memo.name=memos/*} - DELETE /api/v1/{name=memos/*} - GET /api/v1/{name=memos/*}/attachments - PATCH /api/v1/{name=memos/*}/attachments - GET /api/v1/{name=memos/*}/relations - PATCH /api/v1/{name=memos/*}/relations - POST /api/v1/{parent=memos/*}/shares - GET /api/v1/shares/{share_id} - POST /api/v1/attachments - GET /api/v1/attachments - GET /api/v1/{name=attachments/*} - GET /api/v1/{name=attachments/*}/blob - DELETE /api/v1/{name=attachments/*} - GET /api/v1/export - POST /api/v1/import - GET /openapi.json - POST /api/v1/mcp Internal services do not replicate the original Memos’ multi-database abstraction, local file assumptions, background runners, SSE, social features, or instance admin panel. See docs/memos-compatibility.md for compatibility scope, and docs/memos-ecosystem.md for a compatibility matrix with third-party clients and tools. — ## Local Development bash pnpm install pnpm migrate:local pnpm dev Default local address: http://localhost:8787. pnpm dev builds the front end first, then starts the Worker via Wrangler, using Wrangler’s local emulation for D1/R2. — ## Project Status FlareMo currently has: - A deployable Cloudflare Worker + Workers Static Assets all-in-one application. - D1 + Drizzle schema and migrations. - R2 attachments. - Memos-compatible API subset, import/export, OpenAPI, and MCP. - A Flomo-style quick note and timeline UI. - Cloudflare Access for production access boundaries. - A Deploy to Cloudflare button. - Agent deployment runbook, release rules, compatibility matrix, and open-source collaboration documents. Future directions are in ROADMAP.md. The scope for semantic search is documented in docs/semantic-search.md. — ## Engineering The project does not use GitHub Actions as CI. Before publishing, maintainers run locally: bash pnpm verify pnpm deploy:dry-run Common maintenance commands: bash pnpm format:check pnpm screenshots pnpm backup:drill pnpm release vX.Y.Z pnpm verify runs type checking, Vitest, production build, and Playwright E2E tests. The Memos compatibility layer has separate Worker contract tests covering DTO shape, attachment import/export, and OpenAPI paths. Screenshots are generated from a local Worker instance via pnpm screenshots; images in the README are not design mockups. Release rules in docs/release.md. Maintenance guide in docs/maintenance.md. Contribution guidelines in CONTRIBUTING.md. Support in SUPPORT.md. Security policy in SECURITY.md. Community code of conduct in CODE_OF_CONDUCT.md. — ## References - usememos/memos (https://github.com/usememos/memos): Reference for data model, resource naming, and compatible API. - blinkospace/blinko (https://github.com/blinkospace/blinko): Reference for search, attachments, and editing experience. - XuYouo/MeowNocode (https://github.com/XuYouo/MeowNocode): Reference for lightweight Cloudflare D1 application. ## Star If you like this project, consider giving it a star to stay updated. Star History Chart (https://star-history.com/#realchendahuang/FlareMo&Date) ## License MIT