Typemill: A Flat-File CMS for Manuals, Handbooks and eBook Output
Typemill is a flat-file CMS based on Markdown and designed for informational websites like documentation, manuals, and handbooks.
At a glance
- What is it?
- Typemill stores content as Markdown files on disk, renders pages through Slim PHP and Twig, and ships an eBook plugin that converts the same source into PDF and ePUB. It fits documentation sites that want no database; it does not fit sites that need relational queries or a hosted editorial workflow.
- Who is it for?
- Adopt Typemill when the deliverable is a documentation site or handbook whose source you want to keep as Markdown files inside a Git repository, and when the same content has to leave as PDF or ePUB. Do not adopt it when editors need relational content models, multi-user approval chains, or hosting on a platform without PHP.
- 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 22 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Typemill Targets: Documentation That Has to Leave the Browser
Most CMS projects assume the website is the final product. Typemill assumes the website is one output among several. The README describes it as an open-source flat-file CMS for creating websites and eBooks with markdown files, and lists its common uses as user manuals, documentation, knowledge bases, wikis and handbooks. That is a narrower audience than a general-purpose CMS, and the feature set follows from it: the same Markdown source is meant to feed a web page and a downloadable document.
The project carries the topics epub-generation and pdf-generation alongside cms and documentation-tool, and the README names Single Source Publishing as a feature, with the eBook plugin performing the conversion to PDF and ePUB. So the intended user is a technical writer or a small documentation team that maintains one body of text and needs it in a browser, in a printed manual, and in an e-reader file without maintaining three copies.
It is not aimed at shops that want a marketing site with forms, user accounts and a product catalogue. Nothing in the supplied material suggests commerce, membership or complex content relationships. If your content is a set of pages that reference each other hierarchically, Typemill's model is a reasonable fit. If your content is a graph of records, it is not.
Flat Files, Twig Templates and a Symfony Event Dispatcher
The storage decision is the architectural one: no database. Content lives as Markdown files, and the README lists /content among the folders that must be writable, which is consistent with the application writing page files there rather than to a database table. That single choice explains most of the operational behaviour. Backups are file copies. Moving an installation means moving a directory. Version control is possible because the content is plain text, and the v2.26.0 release notes mention a GitSync plugin, which points at exactly that workflow.
The runtime stack is PHP-side: the README names Slim PHP for routing, Vue.js for the interface layer, and Tailwind CSS for styling. Themes are Twig templates, extensions are plugins, and the project describes YAML definitions as part of the developer-facing surface. Plugins hook into a Symfony event dispatcher, so extension code subscribes to named events rather than patching core files. That matters for upgrade cost, because a plugin that only listens to events is less likely to break when core internals change.
The README gives the packaged size as 2MB when gzipped. Treat that as the project's own figure for the distribution, not as a measurement of a running site with media and plugins loaded. The authoring surface offers two modes, a visual block editor and a raw markdown editor, which is a sensible split for the stated audience: writers who want structure, and writers who want the file.
What the material does not describe is the internal request lifecycle, the cache invalidation strategy, or how large a content tree can grow before file reads become the bottleneck. Those are open questions, and anyone evaluating Typemill for a site with thousands of pages should test that themselves rather than assume.
Three Install Paths and the Folders You Must Make Writable
The README documents three ways in. The ZIP route is the least technical: download and unpack the latest zip from typemill.net, upload all files to the server, check file permissions, then visit www.your-typemill-website.com/tm/setup, create an admin user, log in and write. Note the setup route, /tm/setup. That is the path the installer lives at, and the v2.26.2 release is titled Fix Setup Script, so the installer has been touched recently.
The Composer route is for people who want the repository itself:
git clone https://github.com/typemill/typemill.git composer update
The README says to run composer update rather than composer install. Follow the README, but be aware that update resolves dependencies to the newest versions allowed by the constraints, which is a different reproducibility story from a lockfile-based install.
The Docker route points at the official image on DockerHub under kixote/typemill, with further description on docs.typemill.net. The README does not give a docker run command or a compose file, so that detail has to come from the docs site.
Whichever path you take, the permission set is explicit. These folders must be writable: /cache, /content, /data, /media, /settings. Five directories, and each one has a job: rendered cache, page files, application data, uploaded media, configuration. Getting /settings wrong tends to surface as a failure to save configuration rather than as an obvious permission error, so set all five before running setup.
The stated requirements are a web server (Apache or Nginx), PHP 8.1 or higher, and standard libraries including mod_rewrite, gd, mbstring, fileinfo, session and iconv. The v2.26.0 release title references PHP 8.5, which suggests the project tracks new PHP releases, but 8.1 remains the documented floor.
Where the Flat-File Model and the PHP Requirement Become the Wrong Fit
The first limitation is the one that defines the product: no database means no queries. A documentation site rarely needs them. A site that has to list articles by author, join tags to products, or paginate a filtered index of thousands of records will end up doing that work in PHP over the filesystem, and the README offers no query layer to lean on. If your content model is relational, a database-backed CMS is the shorter path.
The second is the hosting requirement. Typemill needs a web server and PHP 8.1 or higher with mod_rewrite, gd, mbstring, fileinfo, session and iconv. That rules out static hosting on object storage, and it rules out environments where you cannot install PHP extensions. The Docker image softens this, but the container still runs PHP.
The third is write access to the application directory. Because /content, /settings and /data must be writable by the web server, the process serving pages also has permission to modify content and configuration. That is a normal trade-off for flat-file systems, and it is worth stating plainly rather than leaving implicit: the security posture depends on the web server being configured correctly, and the README's only guidance on this front is a security@typemill.net address for reporting issues.
The fourth concerns the extension ecosystem. The README notes that plugins, themes and services are published under MIT and commercial licenses. So some extensions are paid, and the licence of the core tells you nothing about the cost of the add-ons you may need. Budget for that before assuming the whole stack is free.
Finally, the supplied material says nothing about multi-user roles, editorial approval, or revision history beyond what GitSync implies. If your team needs an approval workflow inside the CMS, verify that it exists before you plan around it.
Typemill Against a Git-Backed Static Site Generator
The obvious alternative for a Markdown documentation site is a static site generator such as Hugo or MkDocs, where Markdown is compiled at build time into HTML and served from a CDN or a plain web server. The difference in approach is where rendering happens and what the author sees.
With a static generator, there is no PHP process at request time and no writable content directory on the server. You get the content files, a build step, and a deploy. The trade-off is that editing requires the toolchain: a writer either works in a Git client and a text editor, or the team builds an editing layer on top. There is no /tm/setup, no admin user, no visual block editor out of the box.
Typemill inverts that. The server renders pages through Slim PHP and Twig, the admin interface is part of the application, and a non-technical writer can log in and edit in a browser. You pay for that with a PHP host, a writable application directory, and a runtime that has to be kept patched.
The eBook output is the second axis. A static generator gives you HTML; producing a PDF or ePUB from it is a separate pipeline you assemble. Typemill bundles that as a plugin and calls it Single Source Publishing. If PDF and ePUB deliverables are part of the job, that is the concrete reason to pick Typemill over a generator, and if they are not, the generator is the simpler deployment.
A third option, a database-backed CMS such as WordPress, gives you the query layer and the plugin market. It also gives you a database to back up, migrate and secure. Typemill's answer to that is the file tree. Neither is universally better; the deciding question is whether your content needs joins.
Upgrade Cost, Release Cadence and the MIT Boundary
The release history shows a steady cadence rather than a slow one. v2.26.0 landed on 2026-08-17, v2.26.1 on 2026-08-23, and v2.26.2 on 2026-08-24. Three releases in eight days, with the last one titled Fix Setup Script. That is a project that ships fixes quickly, and it also means a self-hosted installation can fall behind within a week. Anyone running Typemill on a public server should decide how they track these, because the setup script itself was the subject of a patch.
The upgrade mechanics are the flat-file advantage. Replacing application files does not touch /content, so pages survive. Configuration in /settings and application data in /data are the parts to back up alongside content, and /media holds uploads. A file-level backup of those four directories plus a copy of the application version is a complete snapshot, which is a simpler story than dumping and restoring a database.
The cost that is easy to miss is plugin compatibility. Typemill exposes Twig templates, a Symfony event dispatcher and YAML definitions to extension authors. A plugin that registers routes or overrides templates is coupled to the core version it was written against. Frequent core releases mean plugin authors have to keep pace, and a stalled plugin is the most likely reason an upgrade stalls.
On licensing: the core is MIT, which permits commercial use and modification. The README states that plugins, themes and services are published under MIT and commercial licenses, so the MIT grant covers the core only. Which specific add-ons are commercial is not stated in the supplied material. Check the licence of each extension you install; this is a description of what the README says, not legal advice.
The README's security guidance is a single instruction: report potential security issues by email to security@typemill.net. There is no published policy on response times or supported versions in the material provided, so treat the disclosure channel as the one confirmed contact point.
Editorial conclusion
Adopt Typemill when the deliverable is a documentation site or handbook whose source you want to keep as Markdown files inside a Git repository, and when the same content has to leave as PDF or ePUB. Do not adopt it when editors need relational content models, multi-user approval chains, or hosting on a platform without PHP. Before committing, verify that PHP is at least 8.1 with mod_rewrite, gd, mbstring, fileinfo, session and iconv, that the /cache, /content, /data, /media and /settings folders are writable, and that the setup route at /tm/setup completes on your host.
Community notes