neno: a flomo style note taker that keeps its data in a GitHub repository

A flomo clone where the backend is a GitHub repository

The project description is in Chinese, but it is short enough to translate cleanly: neno is an open source version modelled on flomo, built as a PWA with Svelte and Tailwind CSS.

The interesting decision is the one in the feature list. There is no backend. All of your data, text and images, is stored using GitHub. The readme states the basic functionality stays the same as flomo, and the same list of features is claimed, but the storage substrate is entirely different from the commercial service it imitates.

That choice explains everything else about the design. There is no server to run, no account system to build, no database to operate, and no recurring hosting cost. In exchange, the notes live in a Git repository, which means they are versioned, diffable, greppable and backed by a copy of your data that is not inside a proprietary database.

The remaining feature list is what you would expect from a capture-first note tool, and the way it is phrased tells you the priorities. It supports full offline use. It supports complete data import and export. It supports sharing images out. It supports syncing content to Notion through a GitHub action.

Then there is the list of input paths, which is where the project has done more than the readme's flomo comparison suggests. There is a uTools plugin, a WeChat official account that records notes into neno, a Telegram bot that records notes into neno, a CLI tool, and a Chrome extension for quickly capturing selected text. Every one of these is a separate repository, and the readme lists their addresses.

The last two entries in the todo list, a daily review and a random walk, are unchecked. The other seven are marked done, including the browser based offline version, GitHub storage, the Notion sync through a GitHub action, and the serverless based WeChat and Telegram note capture.

How a GitHub token becomes the database

The usage section is two sentences and a screenshot, and it explains the whole data model.

You fill in your own GitHub token, click to fetch your GitHub username, fill in the name of the repository that will hold the data, and click save.

So the application is a client that talks to the GitHub API with a personal access token the user enters, and the storage is a repository the user names. There is no schema on a server because there is no server, and the notes become files in that repository.

That design has consequences that are worth being explicit about, because they are the same consequences that come with any client-side application holding a long lived credential. The token lives in the browser, in storage the application controls, on a device that may be shared. The repository it points at is writable by that token. A compromise of the browser session, or of the device, or of the extension that can read the page, is a compromise of the repository.

The readme does not discuss token scoping, revocation or storage location, and it does not mention any encryption of the data at rest. That is not necessarily an omission in the code, but it is an omission in the documentation, and it is the first thing an adopter should resolve for themselves.

The other side of the design is that the data is portable in a way most note apps are not. The readme claims support for complete data import and export, and the underlying format, whatever it is, is a repository of files rather than an opaque blob. A user who decides to leave can take everything with them, and a user can read their own notes with ordinary tools.

The GitHub action for Notion synchronisation follows from the same model. Because the notes are already in a repository, a scheduled workflow can read them and push them into a Notion workspace, and the two scripts in the repository root, syncNenoToNotion.js and syncAllNenoToNotion.js, are that mechanism. There is no import step, because there is no export format to convert.

The frontend stack says what the app is made of

The package manifest is short, but every dependency in it tells you something about the product.

The build is Vite with the Svelte plugin, TypeScript on the side, Tailwind CSS at version 4 with the PostCSS plugin and autoprefixer, and vite-plugin-pwa with workbox-window. That last pair is the offline story: a service worker precaches the application shell so the app opens and captures notes with no network, and the workbox-window integration is what lets the page know when a new version is ready.

The scripts are three.

    "dev": "cross-env NODE_ENV=development vite",
    "build": "vite build",
    "serve": "vite preview"

The dev script sets NODE_ENV through cross-env rather than in the shell, which is the portable way to do it across operating systems, and the serve script runs the preview server against the built output.

The runtime dependencies describe the editing experience. quill is a rich text editor, and wangeditor is a second one, so the app carries two editors. dayjs handles dates. idb is the IndexedDB wrapper, which is how a browser app stores data locally, and it is the mechanism behind both the offline capture and the local copy of the notes. html2canvas-pro renders DOM to a canvas, which is how images get produced for sharing. js-base64 encodes binary content, and qrcode-generator makes QR codes, which fits an app whose notes contain short text and images.

The package is named sttv with version 0.0.0, which is worth noting because it is clearly a leftover name from an earlier version of the project rather than the neno application it now is. The repository, by contrast, is properly named and has a bun.lock, so the current toolchain is Bun even though the scripts still call npm style commands.

The repository root also holds the usual suspects for a Svelte and Tailwind project: a svelte.config.mjs, a vite.config.js, a tailwind.config.js, a postcss.config.cjs, a tsconfig.json, and a globals.d.ts. The readmepic/ directory holds the images the readme embeds, including the settings screenshot that shows the token and repository fields.

Five ways to write a note, and only one of them is the app

This is the part of the project that goes beyond a client side clone, and it is organised as a list of external tools.

The uTools plugin is described as a fast tool platform, and searching for the neno plugin there gives you capture from a launcher. The WeChat official account option, the neno-wx repository, lets you post to an official account and have the note land in neno. The Telegram bot, the neno-tg repository with a live bot at NenoTG_Bot, does the same from Telegram. The CLI tool in the neno-cli repository records notes from a terminal. And the Chrome extension, neno-chrome-plugin, is for quickly capturing selected text.

What links all of them is the same storage substrate. Each one has to end up writing into the GitHub repository, which means each one needs a token, and each one is a separate program that has to keep that credential working. The design makes the app a thin viewer over a repository, so any program that can write files into a repository can be a capture client.

That is a genuinely reusable idea and it is the reason to look at neno even if you do not intend to use the PWA. The alternative approach to the same problem, a hosted API with a token, would require every capture client to talk to a server that understands the note format, and would need that server to exist, be maintained and be paid for.

The cost of the approach is that each extension becomes a place where a credential lives. Five capture paths means five places to revoke a token, and the readme does not describe a shared authorisation model between them.

Building the frontend and putting it on Vercel

The deployment section is short, and the built artefact is a static site.

The self build instructions are three lines.

npm install
node run build

The dist directory then holds the built frontend pages. The second command is written as node run build rather than npm run build, which does not look like a working invocation of a package script, so the practical route is the npm run build script from the package manifest, or the equivalent Bun command given the bun.lock file.

For hosting, the readme points at the Vercel deploy button for the repository. Since the output is a static bundle, this is a static hosting deployment, and the fact that the project is a PWA with offline support means the service worker has to be served over HTTPS for the install and offline features to work, which any of these hosts provide.

The live instance is published at neno.pages.dev, which is a Cloudflare Pages style domain, so the project has been deployed to more than one static host, or at least hosted somewhere with that address.

The build configuration in the repository carries a couple of details worth knowing. The @rollup/plugin-replace dependency is there for build time substitution of values, and the rollup config for a Svelte and Vite project is where environment specific values would be injected. The presence of vite-plugin-pwa with workbox-window means the service worker is generated at build time, and the workbox window integration is what triggers the update prompt, so a deploy of a new version depends on that library behaving as expected.

On the licence, the repository is recorded as GPL-3.0 and the readme's licence section says simply GPL, with a LICENSE.md file at the root. GPL is a strong copyleft licence, which for a self hosted personal tool that nobody distributes is largely irrelevant, but it matters if you fork it, host a modified version as a service, or want to reuse the code inside a proprietary product. Read the LICENSE.md file yourself before doing any of that; this review does not interpret its terms.

Where neno is the wrong tool

There are real limits, and they follow directly from the architecture rather than from missing features.

The first is the credential. A personal access token that can write to a repository, held in a browser, is a single point of failure for both the notes and the repository. The readme does not describe the token's scope, does not mention revocation, and does not mention whether the data is encrypted before it leaves the device. For a personal notebook of the sort people keep, that is the question to answer before you start filling it with things.

The second is that GitHub is a code host, not a note host. Files in a repository are subject to size limits, to rate limits on the API, and to the fact that every write creates a commit, which means every note you add is a commit in a repository. The readme claims a complete offline mode and the todo list marks a browser only offline version as done, which suggests the local IndexedDB copy carries the working set, but the readme does not describe the sync conflict model, what happens when two devices both write, or how the local store reconciles with the repository.

The third is the maintenance picture, and here the evidence is thin. The recent releases list contains exactly one entry, 21.4.22 from 2021-04-22, which is a date-based version number from five years before the most recent push. The last push was on 2026-10-15, so the code is being touched, but there are no recent tags, no release notes and no changelog in the repository listing.

The fourth is the comparison with flomo itself. The readme says the basic functionality is kept the same as flomo, and flomo is a hosted commercial product with server side search, mobile apps, sharing workspaces and a polished editing experience. neno is a client side app that stores files in GitHub. For personal capture, the two are comparable. For anything involving sharing, collaboration or server side processing, they are not the same category of thing, and the readme's claim of parity should be read as parity of the capture and storage workflow.

The alternative to weigh against is simply using the original service, or a local-first app that owns its storage. The difference in approach is where the data and the credential live. neno keeps both in your browser and your repository, so there is no vendor account, no subscription and no server to trust, and in exchange you are responsible for the token and for the durability of a GitHub repository as a notes backend. A dedicated notes app gives you better search, better editing and a real sync protocol, at the price of an account and a subscription. If you want a note taker as a service, neno is not that. If you want a notebook you control end to end, it is a reasonable answer.

Editorial conclusion

neno suits a person who wants a quick capture surface for short notes, owns a GitHub account and is comfortable putting a personal access token into a browser app, and it does not suit a team, a company, or anyone whose notes need to be private from the repository host or the token holder. Before you commit to it, read what a token in browser storage means for the repository it points at, and check the maintenance picture, since the last push was on 2026-10-15 but the only tagged release in the list is 21.4.22 from 2021.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. openneno/neno on GitHub
3. Project website
4. README
5. Releases