KanaDojo: a self-hosted Next.js trainer for kana, kanji and vocabulary

What KanaDojo is for, and who it is not for

KanaDojo is a browser-based drill platform for Japanese script and vocabulary. The README describes three training dojos: Kana, covering Hiragana and Katakana; Kanji, organised by JLPT levels N5 through N1; and Vocabulary. Each dojo runs through four game modes, named Pick, Reverse-Pick, Input and Reverse-Input, which cover recognition in both directions plus typed recall. That is a narrow, well-defined job: repeated retrieval practice on characters and words.

It is not a course. The README lists no grammar lessons, no listening exercises, no speaking practice and no spaced-repetition scheduler. The inspiration credits name Duolingo as the main influence and Monkeytype for UI and design, which matches what the feature list actually delivers: a typing-practice aesthetic applied to Japanese characters rather than a lesson tree. If your goal is conversational Japanese, this is the wrong tool and no setting in it will change that.

The audience the repository addresses is twofold. Learners get a free web app at kanadojo.com or a local copy they run themselves. Contributors get a TypeScript codebase with a documented beginner path, and the README points to an open issue filter for good first issues. The project states that all contributions are welcome, including translation work.

The architecture behind the four drill modes

The stack is Next.js 15 on React 19, TypeScript, Tailwind CSS, shadcn/ui components, Zustand for state and Framer Motion for animation. The repository layout separates app/, components/, core/, features/, entities/, shared/ and data/ at the top level, which is the shape you would expect from a feature-sliced Next.js project: routing in app/, domain logic in core/ and features/, and the kana, kanji and vocabulary datasets in data/.

Japanese text handling is delegated to three libraries the README credits explicitly: Kuroshiro for conversion and romanization, Kuromoji as the tokenizer for text analysis, and Wanakana for kana and romaji transliteration. Dictionary and reading data comes from JMdict and KANJIDIC, with JLPT study references credited to Jonathan Waller's resources and jlptsensei.com. That combination explains how the Kanji and Vocabulary dojos can show readings and meanings without shipping a hand-written dictionary.

Zustand matters for how the app behaves. It is a client-side store, and the README does not describe a server-side progress database or an account system. Progress tracking is listed as a feature (statistics, streaks, 80+ achievements), but where that state lives is not documented in the README. Anyone who needs the same streak on a phone and a laptop should read docs/ARCHITECTURE.md before assuming it works.

Installing KanaDojo and running your first kana drill

The README gives a four-command quick start. You need Node and npm available; the Dockerfile targets Node 20, so a recent LTS release is the safe assumption.

git clone https://github.com/lingdojo/kana-dojo.git
cd kana-dojo
npm install
npm run dev

The dev server uses Turbopack, since the package.json dev script is next dev --turbo. Open http://localhost:3000 and you land on the app. From there, pick the Kana dojo and one of the four modes; Pick and Reverse-Pick are recognition drills, while Input and Reverse-Input expect you to type an answer, which is where the Monkeytype influence is most visible.

Before opening a pull request, the README says to validate changes with one command:

npm run check

That script runs tsc --noEmit --incremental --pretty followed by eslint . --cache, so it type-checks and lints in one pass. It does not run the test suite. Tests are separate: the package.json defines npm test as vitest run, with npm run test:watch for the interactive runner.

If you prefer containers, the repository ships a docker-compose.yml whose app service builds Dockerfile.dev, maps port 3000, sets NODE_ENV=development and bind-mounts the working directory with an anonymous volume over /app/node_modules.

docker compose up

The production Dockerfile is a three-stage build on node:20-alpine that runs npm run i18n:check and npm run build, then starts the standalone output with node server.js as a non-root nextjs user on port 3000. A production service definition exists in docker-compose.yml but is commented out, so you have to uncomment it or build the image yourself.

Where the documentation goes quiet

The README is a landing page, not a manual, and several practical questions are unanswered there. The most consequential is progress persistence. Statistics, streaks and achievements are advertised, but the README never states whether that data is stored in the browser, in a database, or in a hosted service. The repository does contain a supabase/ directory, which suggests a hosted backend exists for the deployed site, but the README does not describe it, and nothing in the quick start tells a self-hoster to configure Supabase credentials. Treat that as an open question, not a feature.

Related to this, the README does not document rollback, backup or export of progress. If you run KanaDojo for a year and want to move your streak to another machine, the documented material gives you no procedure.

The licence is another boundary worth stating plainly. KanaDojo is AGPL-3.0. If you modify it and let users interact with it over a network, the AGPL's network clause is the part that typically surprises people, because it can require you to offer the modified source to those users. This is not legal advice; if you plan to run a modified KanaDojo as a service, read LICENSE.md and get your own counsel.

Maintenance is a separate judgement. The last push to the default branch was on 2026-05-27, and the most recent release, v0.1.18, carries the same timestamp. The repository is not archived, but roughly four months passed between that push and the point at which this was written, so the honest description is a project with a recent release and a quiet period since, not one under continuous development.

KanaDojo against Anki and WaniKani

The obvious alternative for character and vocabulary drilling is Anki. The difference is in what each tool optimises. Anki is a general spaced-repetition engine: you supply or download decks, and the scheduler decides when a card reappears based on your recall history. KanaDojo is the opposite arrangement. It ships its own kana, JLPT kanji and vocabulary content, and the practice loop is immediate and manual: you choose the dojo and the mode, and you drill. The README describes no spaced-repetition scheduling, so the two tools are not interchangeable. If your retention depends on interval tuning, Anki is the better fit; if you want to sit down and type kana for ten minutes without managing a deck, KanaDojo removes that setup work.

WaniKani is the closer comparison on content, since it teaches kanji and vocabulary through a fixed curriculum with its own ordering and review system. KanaDojo does not impose an order: the Kanji dojo is organised by JLPT level N5 to N1, and you pick what to practise. That is freedom if you already know what you need, and a lack of guidance if you do not. WaniKani is a hosted paid service; KanaDojo is AGPL-3.0 source you can run locally, which is the deciding factor for anyone who wants the app on their own machine or wants to read and change the code.

There is also a plain browser-tab argument. Both Anki and KanaDojo run in a browser, but KanaDojo's theming is a deliberate feature: the README claims 100+ themes and 28 Japanese fonts. Anki's interface is functional rather than decorative. That is a real difference in daily use, though it is a preference, not a capability.

Upgrade cost and the contributor toolchain

Upgrading a self-hosted KanaDojo means pulling the branch and rebuilding, because the app is compiled. The release cadence visible in the repository is roughly monthly: v0.1.16 on 2026-03-30, v0.1.17 on 2026-04-21, v0.1.18 on 2026-05-27. The package.json version is 0.1.19, one ahead of the newest published release, which is normal for a main branch between tags. There is no migration guide in the README, and no documented database schema to migrate, which is consistent with the absence of a documented server-side store.

For contributors, the toolchain is conventional but opinionated. Husky runs on npm install via the prepare script, so git hooks are installed automatically. Prettier and ESLint are both configured, with lint-staged wired in. Internationalisation has its own pipeline: npm run i18n:check chains a config check, a translation validator and a type generator, and the production Dockerfile runs that step before the build. If you add user-facing strings, that pipeline is where they get validated.

The AGPL-3.0 licence is the main constraint to weigh before building on the code. Forking for personal use or contributing upstream raises no unusual questions. Running a modified copy as a public service does, and the repository's LICENSE.md is the document to read for that.

Editorial conclusion

Adopt KanaDojo if you want a local, themeable drill loop for kana and JLPT kanji and are comfortable running a Node app or the supplied Docker image on port 3000. Skip it if you need a structured curriculum with grammar and listening, or if you require a hosted account that syncs progress between devices, because the README documents neither. Before committing, run npm run check on your own fork to confirm the toolchain passes, and verify how progress is stored by reading docs/ARCHITECTURE.md rather than assuming it is server-side.

Frequently asked questions

Official sources

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