# Pico CMS: a flat file PHP CMS that is now end of life > Pico stores your site as Markdown files in content/ and renders them with PHP and Twig, with no database anywhere. The repository carries an end of life notice, so this is a review for people inheriting an existing Pico site, not for anyone starting fresh. **picocms/Pico** — Pico is a stupidly simple, blazing fast, flat file CMS. - Repository: https://github.com/picocms/Pico - Website: http://picocms.org/ - Stars: 3,905 · Forks: 607 - Language: PHP - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/picocms-pico ## What Pico actually is, and the notice at the top of the README Pico is a flat file CMS written in PHP. There is no database, no admin panel and no setup wizard. Content lives as Markdown files inside content/, and the README describes the project as "a stupidly simple, blazing fast, flat file CMS". The repository is not archived, and the last push was on 2026-07-07. That date tells you the tree still receives commits, but the README's own notice tells you what those commits are not: the project states that development stopped a very long time ago and that it strongly advises against using Pico for new websites. Both statements can be true at once, and the notice is the one that matters for a decision. The people who still get value from Pico fall into two groups. The first is anyone running an existing Pico site, because the README says such sites have no known security issues and can keep running. The second is a developer who wants to read a small PHP CMS end to end: index.php, lib/, plugins/, themes/ and a config/ directory are the whole application, which is a rare size for a CMS. Neither group is well served by a new install in 2026. ## Markdown in content/, Twig in themes/, and no database in between The data flow is the part that makes Pico worth understanding. A request hits index.php, which boots the application from lib/. Pico walks the content/ directory, maps the directory tree onto URLs, and parses each Markdown file into a page. The page is then handed to the active theme, which is a Twig template set under themes/. The topics list on the repository names the two halves of this pipeline directly: markdown-to-html and twig. Configuration sits in config/. Per-page metadata goes at the top of the Markdown file, which is the convention Pico inherited from its 1.x line and which the PicoDeprecated plugin exists to keep working. Because there is no database, deployment is a file copy and the content directory is diffable in Git. That is the real architectural argument for the flat file model, and Pico implements it with very little ceremony. The cost of that design is equally concrete. Every page view triggers PHP work to read and parse files rather than a query against a cached store, and anything a database would normally give you, such as full text search across thousands of pages, is left to a plugin or to the browser. Pico is fast because the sites it was built for are small, not because the design scales to large ones. ## Installing Pico with Composer, and a first page The README gives two install paths. The Composer path is the one it recommends, and it needs PHP 5.3.6 or newer with the dom and mbstring extensions enabled. Run these two commands from the httpdocs directory of your server, for example /var/www/html: ```bash curl -sSL https://getcomposer.org/installer | php php composer.phar create-project picocms/pico-composer pico ``` The first line downloads Composer. The second creates a project directory named pico from the picocms/pico-composer starter project. There is no second step in the README: you point a browser at the new directory and Pico serves its sample contents, which explain how to write your own. The other path is the pre-bundled release. Download the latest Pico release, upload every file into the install directory, and open it in a browser. No database is created first and no setup script runs. If you want the site under version control, the README describes a Composer based workflow: fork the pico-composer starter project, clone your fork, then install dependencies on the server. ```bash curl -sSL https://getcomposer.org/installer | php git clone https://github.com// pico php composer.phar --working-dir=pico install ``` Later, after you commit and push content changes, the README's update sequence is a pull followed by a Composer update: ```bash git pull php composer.phar update ``` A first real page is a Markdown file in content/ with a metadata header, since that is the convention Pico's sample contents demonstrate. The README does not document the metadata keys themselves; read the sample content that ships in content-sample/ before you invent your own. ## The PHP version ceiling is the failure mode to plan around The README is explicit about how Pico breaks: it says you will ultimately run into issues because Pico wasn't designed for modern PHP versions. That is not a vague warning about age. It means the failure arrives as a PHP upgrade, not as a bug report, and it arrives on a schedule you do not control if your host moves the PHP version for you. A site that has been stable for years can stop rendering after a routine host change, and the project is not in a position to fix it. The README points at two escape hatches for the PHP problem: the last v3.0.0-alpha.2 release and the pico-3.0 branch. It describes them as being as stable as the last stable releases, but as never having made it through the release process before development was abandoned. That is a candid description and it should be read literally: alpha in the version string, abandoned release process, no supported upgrade path after it. The second limitation is the ecosystem. Pico's plugins and themes are third party, and the README's developer section asks anyone working on Pico to clone the PicoDeprecated plugin alongside Pico itself, which tells you how much of the install base sits on the older API. When you hit a plugin that no longer works, there is no upstream maintainer to escalate to. The README's offer to hand the project over to someone willing to take it on is the honest statement of where support stands. ## Pico against Grav, HTMLy, Automad and Typemill The README itself names the alternatives, which saves the guesswork: Grav CMS, HTMLy, Automad and Typemill. The useful comparison is not a feature table but the shape of each project's storage model. Grav keeps the flat file idea but adds a larger plugin and theme ecosystem plus an admin plugin, so it is the closest thing to a drop-in mental model if you liked Pico's file based content and wanted the surrounding tooling to exist. HTMLy is the nearest match on size: a flat file CMS in the same lightweight register, aimed at blogs. Automad and Typemill are both flat file systems with their own template and content conventions, and both are still being developed, which is the difference that matters here. What Pico has that none of these offer is the end of life notice. That sounds like a joke, and it is not meant as one. A project that tells you plainly it has stopped, that existing sites have no known security issues, and that you should look elsewhere for new work is easier to plan around than a project that is quietly unmaintained. If you are choosing a flat file CMS today, the README's own list is the shortlist, and Pico is not on it. ## Licence, maintenance and what an upgrade costs Pico is MIT licensed. The practical effect is that you can fork it, modify it and ship it inside a commercial product, and the LICENSE.md file in the repository root is the document that governs this. Nothing in the licence obliges anyone to maintain the project, and the README's handover request shows that no one currently is. This is a general observation about permissive licences, not legal advice; read LICENSE.md and get your own answer for your situation. Upgrade cost is where Pico differs from a maintained CMS. There is no release cadence to follow. The most recent release listed is v3.0.0-alpha.2 from 2020-12-24, and the two before it are v2.1.4 from 2020-08-29 and v2.1.3 from 2020-07-10. An upgrade therefore means moving between a stable 2.x install and an abandoned alpha, or staying put. Staying put is a defensible choice for a site that works, but it means pinning your PHP version and treating that pin as part of the deployment. If you take the site over, the files that carry the operational weight are SECURITY.md for reporting and disclosure, CHANGELOG.md for what changed between the versions you might move across, and composer.json for the dependency set you inherit. Those three are what a new maintainer would read first. ## Conclusion Pico is for people keeping an existing Pico site alive, or studying a compact PHP flat file CMS. It is not for new websites: the README says development stopped a very long time ago and advises against using Pico for new sites. Before you commit, verify that your PHP version still runs Pico, check whether you need PicoDeprecated for a 1.x era theme or plugin, and read SECURITY.md before you point the site at the public internet. ## FAQ ### Is Pico CMS still maintained? The README carries an end of life notice stating that development stopped a very long time ago and advises against using Pico for new websites. The repository is not archived and the last push was on 2026-07-07, but the project states it is no longer able to maintain Pico and invites someone to take over development. ### How do I install Pico CMS? The README recommends Composer: download Composer and run create-project with picocms/pico-composer. If you have no shell access, download the pre-bundled release and upload all files to your install directory. Pico requires PHP 5.3.6+ with the dom and mbstring extensions enabled. ### Does Pico CMS need a database? No. Pico is a flat file CMS: content lives as Markdown files in content/ and is rendered through Twig themes, with no SQL database and no setup script to run. ### What should I use instead of Pico CMS for a new website? The README's own end of life notice points to Grav CMS, HTMLy, Automad and Typemill as alternatives for a new flat file site. It also notes that you can keep using Pico for an existing website, which has no known security issues. ## Sources - [License: MIT](https://github.com/picocms/Pico/blob/master/LICENSE) - [picocms/Pico on GitHub](https://github.com/picocms/Pico) - [Project website](http://picocms.org/) - [README](https://github.com/picocms/Pico/blob/master/README.md) - [Releases](https://github.com/picocms/Pico/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/picocms-pico