ShowDoc: self-hosted API docs that ship their own SQLite exposure

The Sqlite/ directory ships inside the served root and must be denied

The repository carries a Sqlite/ directory at its root, and the deployment notes flag it as a remote code execution risk. That warning is addressed specifically at self-hosted Nginx and Apache users, with an instruction to deny access to the directory. The reason is structural rather than accidental: this is a PHP application whose data lives in files, and in this layout those files sit inside the directory the web server hands out. Copy the tree into a vhost without the deny rule and the directory is reachable, which is exactly what the note guards against. The README points to a Chinese-language Security.md for the hardening details.

The arm/v7 fallback path chmods the whole document root to 777

The 32-bit ARM build is where permissions get loose. The default base image webdevops/php-nginx:8.3-alpine covers amd64 and arm64, and for arm/v7 the build file tells you to inject an older wordpress:php8.1 base. When the build sees a wordpress:* base it copies the application into /var/www/html, writes a small PHP entry point that renders web/index.html, and relaxes permissions. The comment says the relaxation exists to stay compatible with historical behaviour. What you end up with is a document root with loosened permissions, on the same host where Sqlite/ is supposed to be unreachable.

Two volumes decide what ShowDoc stores and what the web server serves

The compose file says more about storage than any feature description does. It declares two volumes. /showdoc_data on the host is mounted at /showdoc_data_old inside the container, annotated as compatibility with historical version files, and ./showdocdata/html is mounted at /var/www/html, the directory the web server actually serves. Application state and rendered content therefore land in a host directory that is, by definition, web-facing. The service also publishes container port 80 on host port 4999, sets hostname showdoc, and restarts always. Backing ShowDoc up means copying those host paths, and tightening the application down means tightening a directory the web server already points at. Two build arguments shape the image, and ready-made invocations ship in the compose file for both:

docker compose build --build-arg IN_CHINA=true

BASE_IMAGE=wordpress:php8.1 docker compose build

IN_CHINA selects the domestic mirror path, and BASE_IMAGE is how the base image gets swapped without editing the file.

Two roles, two visibility states, and no per-page control

The permission model is exactly that shallow. A project is public or private: public projects can be viewed by anyone, private projects require a login, and the password is set by the project owner. Members can be added and removed freely, members can edit documents, and only the owner can transfer or delete a project. What is missing is granularity. Visibility is decided per project rather than per page, and no role between editor and owner is documented. An internal API document cannot be handed to a contractor as an editor while the rest of the project stays locked, and a public project exposes every page it holds to anyone who has the link.

Markdown plus exactly two insertable templates

The editor is Markdown, and the structural shortcuts are two fixed templates. A single click on the button at the top of the editor inserts either an API interface template or a data dictionary template, after which you fill in data instead of structure. That matches the two use cases named first in the project, API documentation and the data dictionary. The third use case, explanation documents, gets neither template, so a team writing runbooks, design records or incident notes is composing raw Markdown with no form fields, no required-field marking and no layout guarantee. No validation step is documented either, which leaves a half-filled template looking identical to a finished one to whoever reads it six months later.

Version history restores a page, and export stops at Word

Every page keeps a version history and any earlier version can be restored, so a bad edit is recoverable at the granularity of a single page rather than a whole project. What is not stated anywhere is how long that history is retained, whether entries can be pruned, or what restoring does to the versions in between, which leaves retention as something a self-hoster discovers by watching a disk fill. For distribution, a project exports as an offline Word document, and the normal reading path is a responsive web page that works on computers and phones. No other output format is named, so a team that needs PDF or static HTML ends up writing its own conversion around the Word file.

Apache 2.0 on the surface, a consent clause underneath

The licensing story has two halves that do not line up. The project states that ShowDoc is released under the Apache 2.0 Open Source License and is free to use, then attaches a separate copyright notice on top. Under that notice the official site and the author star7th hold the copyright and corresponding rights, the program may be used or developed further provided the copyright information and links in the program UI are kept, and changing that copyright information or those links requires the official's consent and authorization. A LICENSE.txt file sits at the repository root, while the repository's own license field reads NOASSERTION instead of a licence identifier. For a team planning to self-host and restyle the UI, the retention clause is the part to read twice.

The image declares 3.4.2 while the newest tag is v3.9.4

The container's declared version and the release tags do not agree. The Dockerfile sets an environment variable SHOWDOC_DOCKER_VERSION=3.4.3, while the release list tops out at v3.9.6 dated 2026-10-30, with v3.9.5 on 2026-10-21 and v3.9.4 on 2026-09-04 behind it. The compose file does not override that value and refers to star7th/showdoc:latest, so what you receive is whatever the latest tag carries, wrapped in a string that names an older line. Compose also sets both image and build, meaning a local image is used when you have one, a pull is attempted otherwise, and a local build is the fallback, with docker compose up --build there when you want to force the rebuild. For an application that keeps its database as files under a served directory, knowing which version wrote those files matters the moment you upgrade or roll back. The repository is not archived and master took its last push on 2026-10-30.

Editorial conclusion

ShowDoc suits teams that want one place for API documentation, data dictionaries and internal notes, and that will run it on their own hardware rather than a hosted service. Three things deserve a look before you commit: the Sqlite/ directory sits in the served document root and needs an explicit deny rule, the arm/v7 image path relaxes permissions on the web root, and the extra copyright notice requires you to keep the vendor's copyright links in the UI. Check the retention behaviour of page version history and confirm which version the image tag actually carries before you migrate an existing database into it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. star7th/showdoc on GitHub