# kiwix-tools: serving, searching and managing ZIM archives > kiwix-tools is the command line side of the Kiwix project, three programs that operate on the ZIM archive format: an HTTP daemon that serves those archives as a web site, a full text search tool, and a manager for the XML library that indexes a collection of them. It is a C++ project built with Meson and it is mostly interesting because of how carefully it documents its own dependencies. **kiwix/kiwix-tools** — Command line Kiwix tools: kiwix-serve, kiwix-manage, ... - Repository: https://github.com/kiwix/kiwix-tools - Website: https://download.kiwix.org/release/kiwix-tools/ - Stars: 969 · Forks: 152 - Language: C++ - License: GPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/kiwix-kiwix-tools ## Three programs, one file format The tool list is short and each program has a clear job. kiwix-manage manages the XML based library of ZIM files, which is the index that says which archives exist, what they contain and where to fetch them. kiwix-search does full text search inside ZIM files, which is the feature that turns a pile of static archives into something you can query. kiwix-serve is the HTTP daemon that serves ZIM files, and it is the one people actually deploy. The common thread is the ZIM format, which is the compressed archive format Kiwix uses to store offline copies of web content. Everything here is built around treating a ZIM file as a publishable unit rather than as a directory of files, and that is what lets an offline copy of a site be served as a browsable web site with its own internal links intact. The topics attached to the repository say daemon, HTTP, library, offline and ZIM, which is a fair summary of the scope. The homepage points at the release download page rather than at a documentation site, and the documentation itself is hosted on Read the Docs with a separate build badge. For a reader who has never used Kiwix, the practical question is which of the three you need. If you are running a server for a school, a library or a field team, it is kiwix-serve, and the Docker images exist precisely so that you do not have to build anything. If you are a developer working on the tooling, it is the other two. ## The dependency chain, and why it is the interesting part The dependencies section is short but unusually candid, and it is the reason to read this readme even if you never compile the project. The tools rely on two third party libraries, libkiwix and libzim, and the readme enumerates the ways they might not be usable. They may or may not be packaged by your operating system. They may also be packaged but only in an older version. They may also be packaged but without providing a static version. And the compilation script will tell you if one of them is missing or too old. In the worst case, you have to download and compile a bleeding edge version by hand. That three-way enumeration is a good sign about the project's support policy. Most build documentation says install the dependencies and moves on. This one tells you the failure modes you are likely to hit, which is exactly the information a first-time builder needs and which is usually learned the hard way. Two follow-on instructions matter. If you want the dependencies installed locally, you use the kiwix-tools directory itself as the install prefix, which keeps the whole stack in one place. And if you want to compile the tools statically, the dependencies have to be compiled statically too, for example with the enable-static option to the configure script, which is a real constraint and one that bites people who only read the top of the file. The disclaimer at the top of the readme sets expectations honestly. The document assumes you have some knowledge about software compilation, and if you have trouble with the dependencies or with the compilation itself, it points you at the separate kiwix-build project. ## Meson, Ninja and two command lines The build system is Meson, and the environment section lists what it needs. Meson version 0.43 or higher, and Meson itself relies on Ninja, pkg-config and a few other compilation tools. The readme notes that these are packaged on a recent operating system and points at the troubleshooting section otherwise. Once the dependencies are in place, the build is two commands: ```bash meson . build ninja -C build ``` The second line can be written as ninja-build on some systems, which the readme mentions because it is a genuine stumbling block on distributions that ship Ninja under that name. By default the build produces dynamically linked libraries, and the static option is a flag on the Meson command line, the static-linkage option set to true. That flag only matters if you are chasing a single binary that carries its dependencies, which is a common requirement for distribution or for embedded deployments, and it is the option that ties back to the static dependency discussion in the previous section. The build directory is created by the Meson command rather than assumed, and the source tree keeps a meson build file at the root, a meson options file for the options, and a format_code.sh script alongside a clang-format configuration, so the code style is enforced by the same tooling the project uses. ## Installing, uninstalling and the daemon images Installation is one more Ninja target, with the usual caveats about privileges. ```bash ninja -C build install ``` You might need to run that as root or with sudo depending on where you want the tools installed, and after the installation succeeds you may need to run the library cache command as root as well, so that the shared libraries the tools just installed are found. Both of those are the kind of detail that is mentioned once and then causes an hour of confusion for somebody who missed it. Uninstallation has a matching target: ```bash ninja -C build uninstall ``` which, like the install, may need root. The Docker route is the one most people should take. There is an official image of the tools on the GitHub container registry, and a dedicated image for the server alone. That split is a small piece of design that says something about how the project thinks about deployment: the library manager and the search tool are administrative programs you run occasionally, and the daemon is the thing that runs for ever. ## The troubleshooting section, which is a tutorial in disguise The troubleshooting section is worth reading on its own, because it teaches you how the build works by showing you how to install its parts manually. For Meson, the recipe is a virtual environment, activating it, installing Meson with pip, and refreshing the shell path cache so the new binary is found. The point of showing this is that the build tooling is itself a set of tools you install, and the failure mode of a missing Meson is not a compile error but a command not found. For Ninja, the recipe is even more instructive. It clones the Ninja repository, checks out the release branch, runs the bootstrap script, creates a bin directory and copies the built binary into it, then steps back out. Ninja bootstraps itself, and the readme walks you through it because on an older distribution you may need the tool before you can build anything that depends on it. Then there is the general escape hatch. If the compilation still fails, you might need a more recent version of a dependency than the one packaged by your distribution, and the advice is to try a source tarball from the upstream project or to go directly to the source repository. That is the same advice as in the dependencies section, given twice for the two different points at which it applies. Together with the disclaimer at the top, the documentation makes a clear statement about who this build path is for. It is for people who will read an error message and act on it. If you want a binary rather than a build, the container images and the distribution packages are the route. ## Licence, releases and the shape of the repository The administrative details are short and worth stating. The licence is GPL version 3 or later, with the details in the copying file at the root. The readme repeats it in the licence section at the bottom, and the project also ships a Debian packaging directory, which is consistent with the stated support for Debian and Ubuntu. The release history shows a project on a 3.8 line with a steady cadence: 3.8.0 on 2025-10-31, 3.8.1 on 2025-12-02 and 3.8.2 on 2026-03-02, with the last push on 2026-10-18 and the repository not archived. The release badge points at the download page rather than at the tags, which is a small hint that binary artefacts are the thing people come for. The repository layout is conventional for a C++ project with a modern build system. There is a src directory, a docs directory, a docker directory, the Debian packaging, the meson build file and options file, a changelog, an authors file, a formatting script and a clang-format configuration. There is also a well-known directory, and a readthedocs configuration for the documentation build. The most useful single artefact for an evaluator is the dependency list, because it tells you that this is a thin layer over two libraries, libkiwix and libzim, rather than a project with its own format handling. That is a good design for a tool that has to keep working with archives produced by other parts of the Kiwix ecosystem for years. ## Conclusion kiwix-tools is the right choice if you are running a Kiwix server, because the dedicated daemon image and the packaged builds remove the dependency wrangling that the source route implies. It is a poor fit if you only want to read an archive on your own machine, because these are server and management tools rather than a reader. Before you build it, check that your distribution ships recent versions of libkiwix and libzim, since the documentation is explicit that an older or non-static package is the most common reason the build fails, and decide early whether you want static linkage, because the dependencies have to be built that way too. ## FAQ ### What do the kiwix-tools programs do? kiwix-manage manages the XML based library of ZIM files, kiwix-search does full text search inside ZIM files, and kiwix-serve is an HTTP daemon that serves ZIM files as a browsable offline site. All three operate on the ZIM archive format used by Kiwix. ### How do I build kiwix-tools from source? You need libkiwix, libzim, Meson 0.43 or newer, Ninja and pkg-config. Then run meson . build followed by ninja -C build, and install with ninja -C build install. Adding the static-linkage option to the Meson command produces a statically linked build, which requires the dependencies to be static too. ### Is there a Docker image for kiwix-tools? Yes, an official image of the tools is published on the GitHub container registry, and there is a separate dedicated image for the server alone, which is the one to use if all you want is to serve archives. ### What usually goes wrong when compiling kiwix-tools? The readme names the dependency problems explicitly: the libraries may not be packaged, may be packaged at an older version, or may be packaged without a static version, and in the worst case you have to build a bleeding edge version by hand. It also covers installing Meson and Ninja manually, and refreshing the shell path cache afterwards. ## Sources - [kiwix/kiwix-tools on GitHub](https://github.com/kiwix/kiwix-tools) - [License: GPL-3.0](https://github.com/kiwix/kiwix-tools/blob/main/LICENSE) - [Project website](https://download.kiwix.org/release/kiwix-tools/) - [README](https://github.com/kiwix/kiwix-tools/blob/main/README.md) - [Releases](https://github.com/kiwix/kiwix-tools/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kiwix-kiwix-tools