Pico

Last reviewed Sep 13, 2026 · 769 words

A Pico site is a folder of Markdown files and a PHP interpreter, and that sentence is also the complete architecture. Drop about.md into content/ and /about exists. There is no database, no install wizard, no admin login, and nothing to update except the one release archive. On 128 MB of RAM it will serve a personal site or documentation for years, which it has been doing since 2012. The trade is stated plainly in the cons: no admin UI, and no place in the design for a large dynamic site.

How a page becomes a URL

Pico maps the content/ directory straight onto URLs. content/index.md is the home page, content/projects/pico.md is /projects/pico, and content/projects/index.md is /projects. Each file opens with a metadata block in YAML between --- lines, with keys like Title, Description, Date, Author and Template, followed by ordinary Markdown. Pico renders it at request time through a Twig template from the active theme, so a change to a file is live on the next reload with no build step. That is the difference from Hugo and its cousins: same flat files, but the rendering happens per request in PHP rather than once at build time.

Install is an unzip

Download the release archive from the official site, unzip it into the web root, and serve it with PHP. Apache users get clean URLs from the shipped .htaccess. On nginx you add a rewrite so unknown paths land on index.php:

location / {
    try_files $uri $uri/ /index.php?$uri&$args;
}

Composer users can instead run composer create-project picocms/pico-composer to get the same layout with plugins managed as packages. There is no official Docker image; community images exist, and the simplest honest container is the official php:apache image with the release unzipped into /var/www/html. That is a two-line Dockerfile and it stays in your control. Configuration is a single config/config.yml for the site title, base URL, theme and plugin settings.

No admin means editing is your editor

This is the part that decides whether Pico suits you. Content changes happen over SFTP, in a git repo that a hook deploys, or in a text editor on the server. A third-party admin plugin has existed on and off, and I would not build a workflow on it; Pico's own maintainers treat the absence of an admin panel as a feature, and the plugin ecosystem reflects that. If the person editing the site would rather click than commit, that is the moment to look at Grav, which is the bigger flat-file project in the same family with a supported admin panel, or at the wider CMS category for the database-backed options.

Themes and plugins are small and PHP

Themes are Twig templates plus CSS; the default theme is plain, and the theme index on the site has a few dozen options of varying age. Plugins are single PHP classes hooked into Pico's request lifecycle, with the popular ones covering pagination, tags, search and sitemap generation. Writing one takes an afternoon if you know PHP. Keep the count low; every plugin runs on every request, and part of the point of Pico is that a request costs almost nothing.

Where it stops

Pico is not for a site with comments, user accounts, a shop, or thousands of pages that need querying. It reads the content directory on each request, so a very large site slows down in ways a static generator does not, and it has no caching layer of its own beyond what your PHP setup provides. It is also single-author by design; there is no concept of users because there is no login. For a personal site, a project's documentation, or a small business's five pages, none of that matters. Compared with WordPress, you are trading a plugin ecosystem you would not use for an attack surface you no longer have.

What I'd do

Pico in the official php:apache image behind Caddy, content in a git repo, a post-receive hook that pulls into the container's volume. Two plugins at most. For a documentation site or a personal homepage I would choose it over a static generator when I do not want a build step in the way of a quick fix, and over Grav when nobody but me will ever edit the files. The moment a second, less technical editor appears, move to Grav and keep the Markdown.