# Kirby CMS Core Architecture, Installation, and Adoption Limits > Kirby is a PHP-based, file-oriented CMS whose repository contains the core application rather than a ready-made site. It suits developers who want a customizable editing interface and editors who will work with content, but it requires a separate license. **getkirby/kirby** — Kirby's core application folder - Repository: https://github.com/getkirby/kirby - Website: https://getkirby.com - Stars: 1,540 · Forks: 195 - Language: PHP - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/getkirby-kirby ## Why the getkirby/kirby core repository exists Kirby addresses projects in which editors need a CMS interface while developers retain control over the site's structure and presentation. The README describes a system for building an interface around forms, galleries, articles, spreadsheets, and other editorial components. That positioning makes Kirby relevant to small sites, curated collections, and content-driven applications where the CMS should fit the project rather than impose a generic administration screen. The repository itself is not the usual beginning point for a new Kirby site. It is described as "Kirby's core application folder," and the README directs users to two separate repositories: Starterkit and Plainkit. This distinction matters because cloning the core repository does not, according to the README, amount to receiving a complete starter project with site setup and content structure. New users should treat getkirby/kirby as the CMS core, then choose one of the documented kit repositories as their starting point. Kirby is also not open source under a conventional free-software license. The repository metadata identifies the license as Other and points to `LICENSE.md`. The README says that Kirby is not free software, while allowing local or test-server evaluation for as long as needed to decide whether it fits a project. This affects both adoption planning and repository selection: developers evaluating technical fit also need to examine the license for the intended deployment. ## PHP structure across src, config, panel, and views The repository layout exposes several distinct layers of the application. PHP source is concentrated under `src`, while `config` contains configuration-related files and `etc` contains other application data. Rendering files sit in `views`, and `panel` is a separate top-level area associated with the CMS interface. This separation shows that the core is not limited to a single PHP entry script. The top-level `bootstrap.php` provides a visible bootstrap entry point, while `router.php` supplies a distinct routing file. These files indicate application startup and request routing concerns without requiring assumptions about the internal class hierarchy. Internationalization also has a dedicated `i18n` directory, which is consistent with a CMS whose interface messages may need translation. The repository includes `composer.json`, `composer.lock`, and a `vendor` directory. The two Composer files connect dependency declarations with a locked dependency state, although the README does not document the supported PHP version, required extensions, or exact installation command. It would therefore be unsafe to invent a `composer install` tutorial. The repository also contains `assets`, `panel`, and `views`, indicating separation between front-end assets, panel code, and rendered views rather than a single monolithic file layout. This architecture is useful to an engineer deciding whether to depend directly on the core repository, but the README does not provide an extension API, request lifecycle, content schema, or upgrade procedure. Those details must come from the official guide or the chosen starter repository. ## Starting a real Kirby site with the separate kits The README gives no one-command installation or first-content walkthrough for getkirby/kirby. It explicitly says to start with the Starterkit or Plainkit instead of using the core repository directly. Consequently, this article cannot provide a verified shell command, package name, environment variable, or configuration snippet without inventing details absent from the README. The documented path is to visit `https://getkirby.com/try` for an online demo or download one of the kits. The README links Starterkit at `https://github.com/getkirby/starterkit` and Plainkit at `https://github.com/getkirby/plainkit`. It does not explain the technical differences between those two repositories, so choosing between them based on claims not stated in the core README would be guesswork. A first real use should therefore begin with the official try page or one of those kit repositories. The README links the guide at `https://getkirby.com/docs/guide`, which is the relevant source for setup requirements and editor workflows. It also identifies an online demo, official documentation, a forum, Discord, YouTube, and a feedback platform. Those resources have different purposes: the demo supports evaluation, the guide supports implementation, and the feedback platform is for feature ideas rather than bug reports. Because the README gives no runnable command or sample content file, no fenced command block is appropriate here. A concrete setup tutorial should be taken from the selected kit, with its exact steps preserved rather than reconstructed from the core repository's file list. ## The starter-kit path versus direct core development The practical alternative to starting directly from getkirby/kirby is one of the two kits named by the README. This is an alternative in project setup and source distribution: the core repository contains the CMS application, while Starterkit and Plainkit are presented as repositories through which a new project is started. The difference is not described as a change to the CMS engine or as a switch between storage backends. That distinction is easy to miss in automated repository workflows. Selecting getkirby/kirby as the initial repository may produce an application codebase rather than the intended site scaffold. Selecting a kit may provide a closer starting point, but the core README does not state what files, content models, configuration, or deployment assumptions each kit includes. An engineer should inspect the selected kit rather than assume that "starter" and "plain" encode a documented technical distinction. Direct use of the core repository may still make sense when the goal is to study or work on the CMS application itself, but the README frames that repository as the core folder and sends general users elsewhere. It does not document extension development, local bootstrapping, test setup, or a stable procedure for replacing a kit's framework with the latest core release. That makes the core-plus-kit path the only setup route traceable to the core repository's README. A useful evaluation should compare the selected kit against the desired project structure, especially content organization and editor-facing templates. The README does not support claims about which kit is lighter, faster, or more configurable. ## Custom interface freedom with documentation gaps Kirby's main technical promise is interface adaptation. The README says developers can build their own interface and combine forms, galleries, articles, spreadsheets, and more into the editing experience. This is more specific than a generic claim that the CMS is customizable, because it identifies several content and editorial shapes. It also separates CMS capabilities from a fixed visual design, which can help projects with unusual editorial requirements. The repository provides visible support for that direction through `panel`, `views`, and `assets`. However, the README does not explain how those pieces are extended, which APIs are stable, or how an upgrade affects custom templates and panel code. It also does not document authentication, roles, publishing workflows, backups, media processing, or deployment. Those omissions do not mean that Kirby lacks such features. They mean that the core repository's README is not evidence for them. This matters most for teams that expect a conventional plug-in marketplace or a database-backed CMS model. The repository topics include `file-based` and `flat-file-cms`, but the README does not provide a storage schema or explain content persistence. An adoption decision should therefore be based on the official guide and the chosen starter project, not on the topic labels alone. The flexibility is useful when a project needs an editorial interface shaped around its content. It is a poor choice as an unexplained black box for a team that requires all extension points and upgrade behavior to be visible in the README. ## License, releases, and maintenance obligations for Kirby The release history shows version 5.6.1 on 2026-10-06 and version 5.6.0 on 2026-09-16, followed by 6.0.0-beta.1 on 2026-10-15. The presence of a beta release means that teams evaluating the 6.x line should distinguish between the stable 5.6 releases and the beta release rather than treating all recent versions as equivalent production choices. The last push was on 2026-10-16, so the repository is not dormant based on its recent push. However, the README does not describe a release policy, supported release line, upgrade automation, migration process, or compatibility policy. The repository also has CI, PHPUnit, Psalm, and PHPMD-related files, but their presence does not by itself establish runtime compatibility or upgrade ease. The license is a material adoption constraint. The repository metadata calls it a custom license that GitHub cannot classify, the repository contains `LICENSE.md`, and the README links the license agreement at `https://getkirby.com/license`. It also states that Kirby is not free software. A deployment plan must account for the applicable license rather than assuming the repository's public availability makes production use free. The license text should be reviewed for each intended deployment, but this article does not interpret its legal terms. For an existing site, the first upgrade check should be the exact transition between the installed version and the selected release, using the official documentation. The README does not document rollback, migration files, or an upgrade command, so none can be recommended from that source. ## Conclusion Adopt getkirby/kirby when a PHP CMS with a customizable editing interface and file-oriented content model matches the project. Do not choose it solely because the core repository looks installable, since the README directs new projects to separate kits. Verify first that your team can use the Starterkit or Plainkit and accept Kirby's custom license terms. ## FAQ ### How do I install Kirby CMS for a new project? The README says to start with the Starterkit or Plainkit rather than this core repository. It also provides an online demo at `https://getkirby.com/try`, but does not provide a verified installation command for the core folder. ### Is getkirby/kirby free open source software? No. The README says Kirby is not free software, and the repository is classified under a custom license. It allows local or test-server evaluation while deciding whether to buy a license. ### What is the difference between the Kirby core repository and Starterkit? The core repository contains Kirby's core application folder, while the README directs new users to Starterkit as a separate starting repository. The README does not document the technical differences between them. ### Can I customize the Kirby editing interface? Yes. The README says developers can build their own interface and combine forms, galleries, articles, spreadsheets, and other elements into the editing experience. ## Sources - [getkirby/kirby on GitHub](https://github.com/getkirby/kirby) - [Issues](https://github.com/getkirby/kirby/issues) - [Project website](https://getkirby.com) - [README](https://github.com/getkirby/kirby/blob/main/README.md) - [Releases](https://github.com/getkirby/kirby/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/getkirby-kirby