liuzi6612/nav: a static Angular navigation site you edit from the browser

What problem liuzi6612/nav solves, and for whom

Browser bookmarks fail at the point where more than one person needs them. They are per-profile, per-device, and there is no review step. liuzi6612/nav, published as 发现导航 (Discovery Nav), is a link directory that replaces the bookmark file with a Git repository. The README lists three intended uses: an internal company navigation system for shared links, personal bookmark management as a replacement for the browser favourites bar, and a public navigation site meant to be shared.

The repository is TypeScript and Angular, currently at version 17.0.0, and the README describes it as a purely static site with SEO support and online editing. It ships with 800+ sites already categorised, which matters more than it sounds: an empty directory tool asks you to do the curation work before it is useful, and this one does not. The three-branch category tree (三叉树分类) is the organising idea, and the README calls the structure clear rather than deep.

The people this fits are small teams and individuals who want a hosted link page without running a database. The people it does not fit are anyone who needs per-user login, row-level permissions, or an API that other services can query. Nothing in the README describes any of those.

How the no-database design actually works

The design principle in the README is explicit: no database, no server, zero-cost one-click deployment, working out of the box, but able to manipulate and save data the way a database would. The mechanism that reconciles those two claims is Git. The root configuration file nav.config.yaml carries a gitRepoUrl field, and the README instructs fork users to change only that field. Edits made through the site are written back to that repository.

That is why the feature list includes importing from browser bookmarks and exporting back to them. The bookmark file is the interchange format, and the repository is the store. It also explains the site liveness check, the automatic scraping of a site's icon, name and description, and the AI translation option: these are jobs a build step can do against a list of URLs, which is exactly what a static site generator can run before emitting HTML.

Two configuration keys expose the consequences. hashMode controls whether routing uses hash URLs, and the README says it must be set to true when deploying to GitHub Pages, because a static host with no rewrite rules cannot serve deep paths. address is described as the marker for self-hosting: once it is filled in, the project treats the deployment as self-hosted, and only then do password and mailConfig apply. Fork users are told they do not need password at all.

The backend is reached by changing the route to system, so https://www.nav3.cn becomes https://www.nav3.cn/system. There is no separate admin application to deploy.

Installing liuzi6612/nav and reaching the admin route

The README's cheapest path is a fork plus GitHub Pages. Fork the repository, create a token at github.com/settings/tokens/new with read and write scope and save it, then open the Actions tab of your fork to confirm automatic deployment is enabled. Next, edit nav.config.yaml at the repository root and set gitRepoUrl to your own repository address. The README says this is the only field you need to change for the fork case. The configuration table lists gitRepoUrl, branch, imageRepoUrl, hashMode, email, password, address and mailConfig as the fields in that file.

The README gives the following commands for upgrading a fork. They are the same sequence the update package script runs.

git pull
git remote add upstream https://github.com/liuzi6612/nav.git
git fetch upstream main
git merge upstream/main --allow-unrelated-histories --no-edit
git push

# 如果安装了node只需执行
npm run update

The README also states that npm run start runs the init script and serves the site, and that the package scripts include build-gh-pages, build and setup. Once the site is up, append /system to the URL to reach the backend. Netlify, Vercel and Cloudflare Pages are all listed as free options; for Netlify the README gives the publish directory as dist/browser.

Where the Git-backed model gets awkward

Every write is a commit, and the README never describes a review, rollback or conflict story. If two people edit the directory at the same time, the resolution happens in Git, not in the application. That is a real difference from a database-backed directory, where the last write wins silently and nobody has to think about a merge. Here you have history, which is the upside, and merge conflicts, which is the cost.

The self-hosting path is thinner in the documentation than the fork path. The README's configuration table marks password, address and mailConfig as self-hosted only, and says address is what makes the project consider you self-hosted, but it does not explain what happens when address is set and password is empty. The deployment section names pm2, Docker and 宝塔 as supported self-hosting options without giving a command, a Dockerfile or a compose file, and the top-level repository listing does not include one either. Anyone choosing self-hosting is reading the source rather than the README.

The upgrade instructions also assume a specific Git layout. You add the upstream remote, fetch main, and merge with --allow-unrelated-histories and --no-edit, which is the shape you need when your fork has its own history. The package script update does the same against the Gitee mirror. If you have edited files that upstream also changed, that merge is where you will spend your afternoon. The README does not document a rollback path.

Finally, the 800+ bundled sites are the maintainer's curation, not yours. Replacing them wholesale is a data edit, and the README gives no bulk-import path other than the browser bookmark import.

How it compares with a self-hosted bookmark manager

The obvious alternative is a self-hosted bookmark manager running as a server application with a database, of which Linkding and similar tools are the usual examples. The difference is where the data lives and who can read it. A server-side bookmark manager owns a database file or a Postgres instance, serves authenticated pages, and can answer queries about its own contents. liuzi6612/nav owns a Git repository, serves static HTML, and has no query layer beyond what the build produces.

That changes the failure modes. A database-backed manager breaks when the container or the database goes down, and you restore from a dump. liuzi6612/nav breaks when the host is unreachable or the last commit was bad, and you restore by reverting a commit or pushing from your local clone. The second is easier to reason about and harder to do anything clever with.

It also changes the cost curve. Static hosting on GitHub Pages, Netlify, Vercel or Cloudflare Pages is listed as free in the README, and a static site has no idle server to pay for. A server-side manager needs a machine that stays up. If your directory is public and read-mostly, the static model wins on both counts. If your directory needs per-user visibility rules, the static model cannot express them, and the README's only privacy feature is a single flag for making a configuration visible to yourself only.

Licence, commercial use and upgrade cost

The repository is GPL-3.0. The README states that commercial sites, themes, projects and applications can keep their source code private by purchasing a commercial licence, and that the GPL-3.0 terms cover compatible open source projects and non-commercial use. Copyright is held by xiejiahe, 2024 to present. If you intend to run this for a company and keep your modifications closed, the licence question is not optional, and it is worth reading the terms yourself rather than taking a summary from an article.

Upgrade cost is a Git merge, not a package bump. The README's upgrade section clones your repository, adds the upstream remote for github.com/liuzi6612/nav, fetches main, merges with --allow-unrelated-histories --no-edit, and pushes. The package script update performs the equivalent sequence against the Gitee mirror at gitee.com/xiejiahe/nav. The project is on a major-version cadence: v15.0.0, v16.0.0 and v17.0.0 were all released in 2025, and package.json pins the Angular packages at ^21.2.13. The last push to the default branch was on 2026-06-30.

Because the site is static, a bad upgrade is visible immediately and reversible by reverting the merge commit. There is no migration script to run against a database, which is the main cost this design avoids. There is also no compatibility shim if you have customised the templates, so the merge conflict count is your real upgrade estimate.

Editorial conclusion

Adopt liuzi6612/nav if you want a link directory whose data lives in Git, whose hosting bill is zero on GitHub Pages or Netlify, and whose editors are comfortable with the /system route. Do not adopt it if you need per-user accounts, a database query layer, or a licence that permits closed-source commercial use without buying one. Before you commit, verify the gitRepoUrl and hashMode values in nav.config.yaml, confirm the GitHub Actions workflow in .github/ actually runs on your fork, and check the Pages branch is set to gh-pages. If your team will not maintain a Git repository, this project is the wrong shape.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. liuzi6612/nav on GitHub
4. README
5. Releases