Kirby: a file-based PHP CMS

It relies only on the Kirby documentation quickstart page supplied as the source packet. Anything that packet does not state is marked unknown.

What Kirby is

Kirby is a content management system (a CMS product) written in PHP. It is not part of PHP core, not a standalone PHP runtime, and not a framework component library. It runs on top of an ordinary PHP installation and a web server. That is a different category from Drupal, which is also a CMS product, and from PHP itself, which is the language engine. The assigned focus for this guide is Kirby as a file-based CMS.

The packet describes Kirby as having a Panel, which is its control panel for editors, plus templates, snippets, controllers, page models, collections, blueprints, plugins, an API and multi-language support. It also covers users and permissions, caching, routes, and headless integrations.

Architecture and content model

The packet shows three top-level folders that must be protected from direct web access: content, site and kirby. That tells us the broad layout:

• kirby holds the CMS core.
• site holds your project code and configuration, such as templates, blueprints and config. The license file also goes in site/config.
• content holds the pages you manage.

The packet does not describe the on-disk format in detail. The sample project below uses the commonly documented convention of one folder per page and a text file named after the template. That convention is not spelled out in the supplied packet, so treat it as something to verify in the Guide section.

The docs index also lists virtual content. This lets pages come from an API, a database, a spreadsheet or an RSS feed instead of files.

Execution model

The packet describes a classic request lifetime. A web server rewrites requests to a front controller (index.php), PHP runs, and the response is sent. Apache uses the shipped .htaccess. nginx and Caddy need manual configuration, and both examples in the packet hand PHP requests to a FastCGI backend. PHP's built-in server works if started with Kirby's router script.

The packet says nothing about persistent workers such as Swoole, Open Swoole or similar long-running servers, and it does not say whether Kirby supports them. Treat that as unknown. If you tried one anyway, you would be responsible for state leakage. Static properties, singletons, session data, caches, request-derived globals and open handles could survive from one request into the next. You would need to reset or rebuild that state between requests and recycle workers periodically. Those are general persistent-worker concerns, not Kirby guidance. In a classic request lifetime, PHP discards most of that state after each request.

Practical use cases

Based on the packet, Kirby suits editor-managed websites with a Panel for non-developers, projects that want content kept in files, and sites that blend file content with external data through virtual pages. The quickstart also points to cookbook material on headless CMS setups and frontend authentication. This guide does not assess how well those work.

Installation approach

The packet lists several routes: a manual ZIP download, Laravel Herd one-click installers, the Kirby CLI, Composer and Git. You choose between two kits. The Starterkit is a full installation with example content, blueprints and templates, and is aimed at exploring. The Plainkit is minimal and suited to starting a project from scratch.

For this track, the Composer route with the Plainkit is the most reproducible. Then run PHP's built-in server with Kirby's router for local development, bound to the loopback address. The quickstart lists PHP 8.5, 8.4 (recommended), 8.3 and 8.2. Our learning track stays on PHP 8.4, with 8.5 planned. Kirby also needs a standard set of PHP extensions, listed on a separate page that was not supplied. The extension list is therefore unknown here.

On first visit to the Panel, you create the first account. The packet says the Panel cannot be installed on a public server by default unless the panel.install option is enabled, which is a safeguard to keep in mind.

Strengths

• Several install paths and two starter kits.
• A documented PHP 8.4 recommendation, which matches this track.
• Clear web server guidance, including blocking content, site and kirby from direct access.
• An extension model through plugins, plus a reference and cookbook.
• Virtual content for non-file sources.

Limitations and unknowns

• A license is required once a site is published. The packet says a license code is issued per domain. Prices are not in the packet and are unknown.
• Since 5.5.0, a free development license exists for non-public development, staging or preview installations, if you confirm compliance with the license terms. Read those terms yourself.
• The Panel has browser requirements: Firefox 110+, Chrome 106+, Safari 16+, Edge 106+, Opera 94+ on desktop, and Mobile Safari 16+, Android Browser 126+ and Chrome for Android 126+ on mobile.
• Support timelines, the exact current version, performance and the software license are not stated in the packet and are unknown.
• Persistent-worker compatibility is unknown.
• This is a runtime-style PHP project needing Composer and local services, so it is not a browser exercise.

Deployment notes

Upload or deploy the project to the document root. With Apache, make sure the hidden .htaccess file is copied. If the site lives in a subfolder, the RewriteBase may need adjusting. For nginx or Caddy, port the rewrite and blocking rules from the official docs. Both examples there forward PHP to a FastCGI service at php:9000. Keep that FastCGI port on a private network and never expose it publicly. After publishing, activate your license through the Panel or by placing a downloaded license file named .license in site/config.

Example in this guide

The example creates a Plainkit project through Composer, then adds a small page type with a template, a blueprint and one content file. It serves the result with the built-in server on 127.0.0.1. It is a development-only setup.

Where to go next

The official documentation covers the Guide, Reference, Cookbook, plugins and troubleshooting. Start with the quickstart, then the templates and blueprint sections.

title: Note

fields:
  text:
    type: textarea

<?php /** @var Kirby\Cms\Page $page */ ?>
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title><?= $page->title()->esc() ?></title>
</head>
<body>
  <h1><?= $page->title()->esc() ?></h1>
  <?= $page->text()->kirbytext() ?>
</body>
</html>

Title: Hello from Kirby

----

Text: This page is stored as a plain text file inside the content folder.

composer create-project getkirby/plainkit kirby-notes
cd kirby-notes
php -S 127.0.0.1:8000 kirby/router.php
Open http://127.0.0.1:8000/notes in a browser
Open http://127.0.0.1:8000/panel to create the first Panel account