Daux.io turns a folder of Markdown files into documentation with no build step

Documentation is a directory, not a site

Daux.io is a documentation generator that uses a simple folder structure and Markdown files to create documentation on the fly, in a developer friendly way. The homepage is daux.io, and the project is MIT licensed with the current release at 0.26.0, published on 2026-09-10, after 0.25.0 in July 2026 and 0.24.0 in February 2026. The last push to the repository was on 2026-10-22.

The central idea is that the documentation site is a directory in your repository. By default the generator looks for folders inside a docs folder, and you can nest folders any number of levels to get the exact structure you want, because the folder structure is converted into the nested navigation. There is no sidebar file to maintain, no link graph to keep in sync, and no place for a navigation entry to drift away from the file it points at.

The feature list reinforces the minimalism. It is 100 percent mobile responsive, CommonMark compliant, supports Markdown tables, creates a homepage automatically, does syntax highlighting automatically, generates the navigation automatically, ships four built-in themes or lets you roll your own, uses a functional flat design style, produces shareable and linkable SEO friendly URLs, is built on Bootstrap, requires no build step, and is Git and SVN friendly. It also supports Google Analytics and Piwik Analytics, and it can generate static output.

The no build step claim deserves a note. It means there is no webpack or bundler to run for your documentation, which is a real saving in a repository where the documentation is one small part of the work. The project itself does use a front end toolchain, but that is for building Daux.io, not for building your docs.

Two commands, and one of them writes files

The command line tool has two commands, generate and serve, and running Daux.io without an argument automatically runs the generate command. daux --help gives more detail about each.

If you have PHP and Composer, the install is a global Composer require.

composer global require daux/daux.io

# Next to your `docs` folder, run
daux generate

If the command is not found, the README says to ensure your $PATH contains ~/.composer/vendor/bin, which is the usual global Composer bin directory.

The distinction between the two commands is the important design point. generate produces static output, and serve runs Daux.io as a server. The feature list mentions static output generation, and the remote deployment section says you can download the repository as a zip, unpack it, put your documentation in the docs folder and serve it with Apache or Nginx. That is a hosting story with no application server in it: the output is static files, and any web server can serve them.

The Docker route runs the same tool in a container.

docker run --rm -it -w /build -v "$PWD":/build -u "$(id -u):$(id -g)" daux/daux.io daux

The image is built from php:8.5.11 with the intl extension installed and the Composer binary copied in from a composer:2.10.3 stage. It exposes port 8085 and its default command is daux. The user mapping in that run command, running as your own uid and gid, is what stops the container writing root owned files into your working directory, which is the detail that makes the one line command usable in a real repository.

File names carry the ordering, and the URLs carry the title

The generator looks for Markdown files, both *.md and *.markdown, inside the docs folder and any of its subfolders. The naming rules are strict, and the reason is that the file name is what produces the page title and the URL.

File names join words with the _ character instead of using spaces. The README gives the conversions explicitly.

01_Getting_Started.md = Getting Started
API_Calls.md = API Calls
200_Something_Else-Cool.md = Something Else-Cool
_5_Ways_to_Be_Happy.md = 5 Ways To Be Happy

A file name with a space in it fails. That is a rough edge for a project that otherwise aims to be unobtrusive, and it is the one convention most likely to annoy a team, since spaces in file names are perfectly normal in a repository and the generator will simply not pick them up the way you expect.

Ordering is done with a numeric prefix and a _ character, for example /docs/01_Hello_World.md and /docs/05_Features.md, which lists Hello World before Features and overrides the default alpha-numeric sorting. The numbers are stripped out of both the navigation and the URLs, so the sort key does not pollute your links.

There is a wrinkle for a file that starts with a digit in its title. For a file called 6 Ways to Get Rich, the README suggests /docs/_6_Ways_to_Get_Rich.md, where the leading _ stands in for the digit that the sorting parser would otherwise read as a prefix.

Landing pages come from index.md files

The homepage is automatic. If you want a landing page for your project, you create an index.md file in the root of the /docs folder, and that file becomes the landing page. You can add a tagline and an image through the configuration file.

{
    "title": "Daux.io",
    "tagline": "The Easiest Way To Document Your Project",
    "image": "app.png"
}

The image can be a local or a remote image, and the convention is that the placeholder for the base URL refers to the root directory of the Daux instance, so a config can refer to the site's own root without hard coding a domain.

Section landing pages work the same way at one level down. A folder such as /docs/01_Examples has a landing page because it contains an index.md, and if you want an index page for a section without the landing page format, the file is named _index.md.

The configuration itself is a config.json file in the root of the /docs folder, described as a simple JSON object for changing the basic settings. The title bar is set with a title key, and the theme is chosen with the html.theme key, with four built-in Bootstrap themes available: daux-blue, daux-green, daux-navy and daux-red.

{
    "html": { "theme": "daux-green" }
}

The README also lists where the rest of the options live, with separate pages for global options, HTML options and Confluence upload options, the last of which points at a feature for pushing documentation into Confluence.

The front end is Bootstrap, with KaTeX, Mermaid and a search index

The repository layout explains what the generated site is made of, and it is a modern stack for a PHP project.

There is a themes/ directory for the Bootstrap themes, templates/ for the page templates, src/ for the sources, and daux/ and daux_libraries/ for the generator itself and the libraries it uses. The package.json is a private build package for the front end assets, with yarn 4.18.1 as the package manager and a build script that calls build.sh, a watch script that calls crafty watch, and a test script that calls test.sh.

The dependencies tell you what the output can do. KaTeX handles mathematical typesetting, Mermaid handles diagrams, FlexSearch provides the search index, and Preact is the component library rather than a full framework, which fits a static output. Webpack with the swc loader does the bundling, and the Swissquote Crafty toolchain handles the CSS and the asset pipeline, with a postcss plugin for page breaks, which is what you want when a section has to start on a printed page.

The test story is broad. There is a tests/ directory with phpunit.xml for the PHP side, an e2e/ directory with a Playwright configuration for the browser level tests, and a.deepsource.toml, sonar-project.properties and a code style configuration in.php-cs-fixer.php. The front end linting and formatting run through Biome, and the CSS is linted through the Crafty preset.

The examples/ directory contains a multilanguage example, which is the one piece of scope the README does not explain.

Static output and a PHP 8.4 floor on the server

Two operational facts decide where this can run.

The first is the PHP version. The Running Remotely section says to copy the files to a web server that can run PHP 8.4.0 or newer. That is a hard floor for the server, and it is worth checking before anything else, because a hosting plan on an older PHP is a dead end for the dynamic mode of this tool.

The second is the .htaccess file at the root of the repository, which is the Apache counterpart of routing rules. The presence of that file next to index.php tells you the dynamic mode expects to be served by a web server that reads it, and the README mentions both Apache and Nginx for the static output case.

There is a second configuration file that is easy to miss, global.json, which is where you specify the docs path if you want to keep your documentation somewhere other than the Daux.io root, for example outside the project directory. The Docker image copies it into the image alongside the composer files, the bin, libs, templates, themes and index.php, which confirms it is part of the runtime configuration rather than a development convenience.

The .dockerignore file, the Dockerfile and a docker/ directory complete the picture, and the README's badges point at a Docker Hub image at daux/daux.io and a Packagist package at daux/daux.io, so both distribution channels are supported.

Where a documentation generator like this stops being enough

Three cases call for something else.

The first is when you need versioned documentation. Daux.io derives the site from one folder of Markdown files, and there is no version dimension in the model described in the README. If your product ships two versions of an API and the documentation has to let a reader choose, the folder convention does not express that, and you end up generating several sites and linking them by hand.

The second is when you need a documentation platform rather than a generator. Search, a contribution workflow, a per page comment thread, a translation pipeline, an API reference generated from code, analytics on which pages people read: none of these appear in the feature list, and a platform that does them is a different kind of product with a different kind of cost.

The third is a codebase whose documentation is not Markdown files in a folder. A team whose docs live in an issue tracker, in a wiki, or in the docstrings of an API with a separate reference generator is not going to restructure for this tool.

Within its own shape, though, Daux.io is a good fit for a project that wants a documentation site with no framework to maintain, no build step to run and no server side application to keep patched. The output is static HTML, the input is Markdown in the repository, and the four built-in themes are enough for a project that does not want to design a site.

Editorial conclusion

Daux.io fits a team that keeps documentation next to the code in the same repository and wants a site without maintaining a site framework, because the navigation comes from the folder tree and the output can be static HTML served by any web server. It is the wrong choice when you need a documentation platform with versioning, per-version search or a plugin ecosystem, and the wrong choice if you cannot run PHP 8.4 or newer on the host. Before adopting it, run daux serve next to an existing docs folder to see the default theme against your real content, read the configuration options pages for the settings the README only summarises, and check that the naming convention, where words are joined with the _ character, fits how your team already names files.

Frequently asked questions

Official sources

1. dauxio/daux.io on GitHub
2. License: MIT
3. Project website
4. README
5. Releases