tauri-docs: the Astro and Starlight site behind the Tauri 2 documentation
The source for all Tauri project documentation.
At a glance
- What is it?
- tauri-docs is the source for the Tauri 2.0 documentation, an Astro site with the Starlight theme that generates its API reference, CLI reference and configuration reference from the Tauri source tree at build time. It suits a developer who wants the framework's behaviour described precisely, and a contributor who wants to fix a page, with the build pipeline doing most of the reference work.
- Who is it for?
- tauri-docs fits a developer working with Tauri 2 who needs the reference rather than the tutorial, because the API, configuration and CLI references are generated from the source tree rather than written by hand, so they track the code. Skip it if you are looking for the framework itself, since this is the documentation repository and the Tauri source lives elsewhere, and note that the v1 documentation is a separate branch, so anything you find for Tauri 1 may not apply.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly MDX, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A documentation site that generates its own reference
This repo is used to build the docs for Tauri at https://tauri.app, and the README is explicit that it is the home for the Tauri 2.0 documentation. If you are looking for the old v1 docs, there is a separate v1 branch, and the default branch here is v2.
The interesting part is the build pipeline, and the package manifest is unusually revealing because the reference pages are not hand written. The `build` script chains the whole thing together:
pnpm dev:setup && pnpm build:references && pnpm build:config && pnpm build:cli && pnpm build:releases && pnpm build:astroThree of those steps are generators, each one a separate workspace package with its own name. `build:references` runs the js-api-generator, which produces the API reference. `build:config` runs the config-generator, which produces the configuration reference. And `build:cli` runs the cli-generator for the command line reference. Then `build:releases` runs the releases-site generator, and `build:astro` is the actual site build.
So the reference material is derived from the framework's own source at build time. That is the design decision that makes this repository worth reading even if you never contribute to it. A configuration reference that is generated from the actual config schema cannot drift from the config schema, and the same goes for the API and the CLI. The pages you read are a projection of the code rather than a description of it that someone has to remember to update.
The site itself is Astro 7.3.2 with the Starlight theme at 0.42.0, and the primary language of the repository is MDX, which is the format Starlight uses for documentation pages that need a component. The dev script is simply `astro dev`, and `preview` is `astro preview`.
The setup step pulls the framework in as a submodule
The `dev:setup` script is three steps and it is where the pipeline earns its keep.
`dev:setup:submodules` runs `git submodule update --init`, and that is the important one, because the reference generators read the Tauri source tree. The `.gitmodules` file at the top of the repository and the `dev:setup:tauri` script that installs into `packages/tauri/packages/api` confirm it. The Tauri source is a submodule of this repository, and the API generator reads the type definitions out of it to produce the reference pages.
That explains why the setup is more involved than `pnpm install`. There is also a plugins workspace to install with `dev:setup:plugins-workspace`, and a final `build:compatibility-table` step that runs the compatibility-table package to produce the table of which platform versions each release supports.
The install commands themselves carry some care. The Tauri API install uses `--ignore-workspace --no-frozen-lockfile --pm-on-fail=ignore`, and the plugins workspace uses `--pm-on-fail=ignore` as well. The reason is that these are nested package trees with their own lockfiles, and they are not part of the documentation workspace, so the workspace's own lockfile rules do not apply to them.
The repository is a pnpm workspace, with `pnpm-workspace.yaml` and `pnpm-lock.yaml` at the root, and the `packages/` directory holding the generator packages alongside the submodules. The root `package.json` is private and marked as a module, and its version is `0.0.1`, which is the conventional way of saying this is not a published artifact.
So the setup order is submodules first, then the nested Tauri and plugins installs, then the compatibility table. The build then runs the three generators and hands the result to Astro. Nothing about that is unusual, but the fact that the reference comes from the framework source rather than from prose is the thing to take away.
Translations, and the tooling that keeps them honest
The site is localised, and the tooling around that is the part of the repository with the most moving pieces.
`locales.json` at the top level holds the locale configuration, and the Lunaria packages are there for it, `@lunariajs/core` and `@lunariajs/starlight`. Lunaria is the translation tracking tool, and having a dedicated Starlight integration means the translation status can be shown inside the documentation itself, which is how a reader knows whether a page they are looking at is the English original or a translation that may be behind.
There is a script for the correctness of that, `check:translations`, which runs `node ./scripts/check-translation-slugs.mjs`. The name tells you what it checks, translation slugs, and the reason it matters is specific. Localised routes are keyed by slug rather than by path, and if a page is renamed in the source language the localised versions keep the old slug unless the slugs are updated to match. The result is a broken or orphaned translation, and this script catches that.
The `llms-txt.config.mjs` file is a more recent addition and points at a direction the project is heading. An llms.txt file is a machine readable index of a documentation site, produced for the benefit of language models and tools that read documentation programmatically, and having a config for generating one in the repository means the docs are usable by an assistant rather than only by a browser.
The Astro and Starlight dependencies show the rest. `@astrojs/markdown-satteri` is the MDX integration, `@astrojs/rss` generates the feed, and `@types/mdast` types the markdown AST that Starlight parses. The `netlify.toml` at the root and the Netlify deploy status badge tell you the site is built and hosted on Netlify.
The formatting and linting story is small and consistent. `prettier` with `prettier-plugin-astro` handles the MDX and Astro files, with a `--cache` flag on both the write and the check script, and a `.prettierrc` and a `.prettierignore` at the root. There is a `.pre-commit-config.yaml` for the hook, a `renovate.json` for dependency updates, a `tsconfig.json`, and a `.vscode/` directory.
How a contributor gets in, and what the repo does not contain
The Get Involved section names three ways in, and they are aimed at different kinds of contributor.
Join the Discord, in the `#docs` channel, to ask questions or give feedback. Check out the Tauri 2.0 Documentation Roadmap, which is an issue in the repository, and see if there is anything you would like to get involved in. And read the contributing guidelines in `.github/CONTRIBUTING.md` to learn how to get up and running.
The roadmap as an issue is a good pattern for a documentation project, because it turns a vague need for more docs into a list of addressable tasks, and it lets a newcomer pick a page without needing to understand the build first.
The Gitpod and GitHub Codespaces buttons are both present, and both point at the v2 branch, so a contributor can get a working environment without installing the toolchain. That matters more here than in most repositories, because the setup involves submodules and two nested installs.
What the repository is not is the framework. There is no Tauri source here in the ordinary sense, it arrives as a submodule, and the Tauri project has its own repository. The documentation describes a framework whose behaviour is defined elsewhere, and the generators in `packages/` are the bridge that turns that behaviour into pages.
The other structural pieces are the `scripts/` directory, which holds the translation check and whatever else the build needs, the `src/` directory holding the Astro site content and configuration, the `public/` directory for static assets, and the `lunaria/` directory for the translation tracking configuration.
The sponsor list is worth a mention for a different reason. The README shows a single sponsor in the table, CrabNebula, and then points to the project website and to Open Collective for the complete list, so the funding arrangement is both a company and a community fund.
The licence is MIT, with the copyright held by the Tauri Programme within The Commons Conservancy for 2020 to 2023, and the repository is not archived with the last push on 2026-10-15.
Editorial conclusion
tauri-docs fits a developer working with Tauri 2 who needs the reference rather than the tutorial, because the API, configuration and CLI references are generated from the source tree rather than written by hand, so they track the code. Skip it if you are looking for the framework itself, since this is the documentation repository and the Tauri source lives elsewhere, and note that the v1 documentation is a separate branch, so anything you find for Tauri 1 may not apply. Before you contribute, read the contributing guidelines and the documentation roadmap, and run the setup step first, because the reference pages need the submodules and the generator workspaces to be present. The last push was on 2026-10-15 and the default branch is v2.
Frequently asked questions
What is the tauri-docs repository?
It is the source for all Tauri project documentation, specifically the Tauri 2.0 docs, and it is used to build the docs site at tauri.app. The default branch is v2, and the older v1 documentation lives on a separate branch.
How are the API, configuration and CLI reference pages generated?
By separate generator workspaces run during the build: the js-api-generator produces the API reference, the config-generator the configuration reference and the cli-generator the CLI reference, with the results then handed to the Astro build.
What do I need installed to work on the Tauri documentation?
The setup script runs a git submodule update, then installs the Tauri API package and the plugins workspace with their own lockfiles, and then builds the compatibility table. Gitpod and GitHub Codespaces configurations are provided so you can skip the local setup.
How are translations handled in the Tauri documentation?
Locales are configured in locales.json and tracked with Lunaria, which has a Starlight integration, and a script called check-translation-slugs verifies that localised slugs still match the source pages after a rename.
How do I contribute to the Tauri documentation?
Join the Discord in the #docs channel, look at the Tauri 2.0 Documentation Roadmap issue for tasks, and read the contributing guidelines. The licence is MIT and the last push was on 2026-10-15.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/tauri-apps-tauri-docs)Was this useful?