EdgeEver: a self-hosted Evernote alternative on Cloudflare, with MCP built in

The gap EdgeEver is aiming at

The README is unusually explicit about who this is for. It names three groups of existing tools and the tradeoff each one imposes: Evernote, which the README describes as having grown bloated with ads and restricted free tiers; Obsidian, which the README calls powerful but heavy for quick capture, with sync behind a subscription or a third-party setup; and Memos or Stream Notes, whose social-timeline layout the README says differs fundamentally from a three-pane workflow. EdgeEver's pitch is that it keeps the three-pane layout and removes the storage bill by running on Cloudflare's free quotas.

The second half of the pitch is data ownership. The README states the application is built on standard SQLite, with REST API, MCP and CLI access, and that a full library can be exported as a ZIP containing Markdown, Front Matter, nested folders, relative attachment links and version histories. That combination is the actual product claim. A notes app that stores your writing in a format you can read without the app is a different commitment from one that stores it in a proprietary blob, and the README leans on this harder than on any editor feature.

The third piece is AI. EdgeEver describes itself as AI-native and ships an MCP integration, which the README says lets tools like Claude Code, Codex and Antigravity read, organise and summarise notes, or push them to Notion and Feishu Bitable. There is also a bring-your-own-model path for OpenAI, Anthropic and Gemini-compatible endpoints, used for summarisation, key point extraction, proofreading, translation and text continuation. If you do not want an agent anywhere near your notes, most of the marketing here is irrelevant to you, and the remaining question is simply whether the editor and the sync are good enough.

How EdgeEver stores notes and moves them between devices

The repository layout tells you more than the feature list. The top level has apps/ and packages/ as Bun workspaces, a migrations/ directory, a wrangler.toml, a Dockerfile, a compose.yaml and a crates/ directory, which suggests at least one Rust component alongside the TypeScript. The package.json declares "packageManager": "[email protected]" and marks the workspace root private, so the build is Bun-first rather than npm-first. Any contribution or local build starts from that assumption.

There are two deployment shapes for the same application. On Cloudflare, the wrangler.toml and the dev:api:remote script (which runs wrangler dev with --remote on port 8787) indicate a Workers-based API with Cloudflare's storage bindings behind it. In Docker, the Dockerfile builds a runtime image from oven/bun:1.3.14-alpine, sets EDGE_EVER_DATA_DIR=/data and PORT=8787, and copies in a self-hosted server entry point. That is the same web client talking to a different persistence layer, which is why the README can claim both a free serverless path and a VPS path without maintaining two products.

The client side is a Vite app (apps/web, built with build:web, served from EDGE_EVER_WEB_DIR=/app/apps/web/dist in the container). The README mentions Web, PWA, Android, macOS, iOS and a browser extension, with Windows listed as coming soon. Sync is described as unlimited across devices with no device caps, and offline drafts queue locally and sync on reconnect.

Nothing in the README documents the conflict resolution rule when two devices edit the same note offline. That is the first thing I would want to know before trusting it with a long-form draft on a plane. The README also does not say how the offline queue behaves when a note was deleted on the server while the local copy was still being edited, which is the classic failure mode for queue-based sync. Those are questions for the source, not for the marketing page.

The multi-tenant story is worth noting because it changes the deployment shape. The README says a single instance can host multiple user accounts with strictly partitioned spaces and admin account management. On Cloudflare that means one Worker serving several people; in Docker it means one container and one volume holding several people's notes. If you are deploying for a family or a small team, the isolation guarantee is the thing to test, because the README states it but does not describe the mechanism behind it.

Installing EdgeEver with Docker Compose

The README recommends Cloudflare as the zero-server path and offers Docker for a VPS, NAS or home server. The compose.yaml in the repository is the concrete artifact, so start there. It pulls ghcr.io/tianma-if/edgeever, maps port 8787, and mounts a named volume at /data.

services:
  edgeever:
    image: "${EDGE_EVER_IMAGE:-ghcr.io/tianma-if/edgeever}:${EDGE_EVER_VERSION:-latest}"
    restart: unless-stopped
    ports:
      - "${EDGE_EVER_PORT:-8787}:8787"
    environment:
      EDGE_EVER_AUTH_USERNAME: "${EDGE_EVER_AUTH_USERNAME:-admin}"
      EDGE_EVER_AUTH_PASSWORD: "${EDGE_EVER_AUTH_PASSWORD:?Set EDGE_EVER_AUTH_PASSWORD before starting EdgeEver}"
    volumes:
      - edgeever-data:/data

The password line uses the Compose required-variable syntax, so the stack refuses to start until EDGE_EVER_AUTH_PASSWORD is set. That is a deliberate guard, not an accident, and it means you cannot bring the container up with a default credential. Set it in a .env file next to the compose file, then run:

docker compose up -d
docker compose logs -f edgeever

After the container reports ready, open http://localhost:8787 and log in with the username and password you set. The container also sets EDGE_EVER_CONTAINER_IMAGE and drops all Linux capabilities with no-new-privileges, so the process runs unprivileged inside the image. Data lives in the edgeever-data volume; back that volume up before you upgrade, because the compose file pins no version by default and will pull latest on the next up.

For local development against the source tree, the package.json exposes bun run dev:local, which starts via scripts/local-dev.mjs, plus bun run dev:doctor to check the environment. The README documents a Cloudflare deployment path with an AI-agent prompt as the recommended option, but the repository's wrangler.toml and the dev:api:remote script are the authoritative references for that route.

Where EdgeEver is the wrong choice

The Cloudflare free-tier story is a quota story, and the README states it plainly: roughly 150,000 short notes and 50,000 images for a personal deployment, based on Cloudflare's free storage allowances. Those are estimates tied to someone else's pricing page. If Cloudflare changes its free limits, the number changes and the cost of your deployment changes with it. Docker is the escape hatch, and the README says Docker storage scales on demand to support millions of notes, but that means you are now maintaining a host.

The second limitation is the AI surface. The README lists Claude Code, Codex and Antigravity as MCP clients. It does not describe a permission model, a scoping mechanism, or a read-only mode for the MCP endpoint. If an agent can write to your notebook, then a bad tool call can reorganise or overwrite notes, and the mitigation the README offers is revision history and ZIP backups. Those help, but they are recovery, not prevention. Anyone who wants an agent with strictly bounded access should check what the MCP server actually exposes in their version before pointing it at a real notebook.

The third is ecosystem depth. The README mentions a Plugin Marketplace for client plugins and themes, extending note actions, editor commands and custom panels. It does not say how many plugins exist, what the review process is, or whether plugins run sandboxed. Obsidian's plugin ecosystem is the obvious comparison, and on that axis EdgeEver is a much younger project. If your workflow depends on a specific community plugin, assume you will be writing it yourself or doing without.

Finally, the licence. The Dockerfile labels the image AGPL-3.0-only and the repository carries an AGPL-3.0 LICENSE. That is a strong copyleft, and it matters if you intend to modify EdgeEver and expose it to other users over a network. I am not giving legal advice here; if you plan to run a modified public instance, read the licence text in the repository rather than a summary of it.

EdgeEver versus Obsidian and Joplin

The closest comparison the README itself draws is Obsidian. Both store plain files you can read without the app, and both are extensible. The difference is the architecture. Obsidian is a local-first desktop application with a plugin runtime in the same process, and sync is a paid service or a folder you sync yourself. EdgeEver is a web application with a server component: the notes live in SQLite behind an HTTP API, and the client is a browser, PWA or mobile app. That server-centric design is what makes MCP and multi-device access straightforward, and it is also what makes the Cloudflare quota relevant in the first place. If you want a folder of Markdown files on your laptop that no server ever touches, Obsidian is the simpler answer and EdgeEver is not competing for that use case.

Joplin is the other obvious reference point for an open-source Evernote replacement: it syncs through your own storage provider and has a mature desktop and mobile client. The README does not mention Joplin, so I will not put words in its mouth about how the two compare feature by feature. What can be said from the README is that EdgeEver's distinguishing bet is the serverless deployment target plus a first-class MCP endpoint, and that Joplin's is a sync target you already own. Pick based on which of those two you actually want, not on the editor, because both editors are adequate.

There is also the option the README suggests for people already invested elsewhere: use EdgeEver as an inbox and let an agent move curated notes into Notion, Feishu Bitable or Obsidian. That is a legitimate middle path, and it is the one the README recommends as the workflow. It also sidesteps the migration problem entirely, since you never have to move your archive, only the notes you are actively working on.

One more distinction worth making is what happens when the project stops. EdgeEver's export produces Markdown with Front Matter and relative attachment links, so a dead instance leaves you with a folder tree rather than a database dump. Obsidian's vault is already that folder tree. Joplin's export format is not described in the README. If exit cost matters to you more than the deployment model, that difference is the deciding factor.

Maintenance, releases and upgrade cost

EdgeEver is not archived. The last push was on 2026-08-29, and recent releases land close together: v1.45.2 and v1.45.4 on 2026-08-28, then v1.46.0 on 2026-08-29. The package.json version is 1.73.0, which is ahead of the release tags listed, so the version string in the manifest and the release names are not tracking each other one-to-one. Do not assume a package.json version tells you which release you are running; use the image tag or the build identifier.

That release cadence has a cost. If you run the compose file as written, the image tag defaults to latest, so a restart can silently move you to a new build. Pin EDGE_EVER_VERSION to a specific tag if you want upgrades to be a decision rather than a side effect. The Dockerfile accepts an EDGE_EVER_BUILD_ID argument, which is the hook for identifying exactly which build you deployed, and it is worth setting if you ever need to correlate a bug report with a build.

Upgrades also interact with the migrations/ directory at the repository root. Schema migrations run against your SQLite data, and the README does not document a rollback procedure for a failed migration. The practical implication is that your backup is the rollback plan. The README does document a lossless ZIP export containing Markdown, Front Matter, nested folders, relative attachment links and version histories, and for a Docker deployment the named volume is the other thing to copy. Take one of those two before you change the image tag.

The licence is AGPL-3.0-only per the image label and the LICENSE file. Running EdgeEver for yourself carries no distribution obligation. Modifying it and letting other people use it over a network is where the copyleft terms start to matter, and that is a question for a lawyer, not for this article.

What to check before you commit

Two things are worth verifying in a running instance rather than in the README. First, export a notebook and open the ZIP: the README promises Markdown, Front Matter, nested folders, relative attachment links and version histories, and the export is your rollback plan, so it should be tested before you need it. Second, list the MCP tools your client sees and confirm they match what you expect an agent to be able to do, because the README describes the integration's purpose but not its permission surface.

If both check out, the deployment question is straightforward. Cloudflare if you want zero servers and can live inside the free quotas; Docker on a VPS or NAS if you would rather own the disk and scale past the estimate. The compose file already runs the container unprivileged with all capabilities dropped, which is a reasonable default to keep. The one setting you must not skip is EDGE_EVER_AUTH_PASSWORD, and the compose file will stop you if you try.

Editorial conclusion

EdgeEver fits people who want the three-pane Evernote workflow back, are comfortable with Cloudflare Workers or a Docker host, and specifically want an MCP endpoint so an agent can read and reorganise their notes. It is the wrong tool if you need a mature plugin ecosystem, if you want a paid support contract, or if you are not prepared to run your own backups. Before committing, verify three things: that EDGE_EVER_AUTH_PASSWORD is set in your compose environment, that the ZIP export in the running version actually contains Markdown plus Front Matter plus attachment folders, and that the MCP tools your agent calls match what the documentation describes for your release.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes