The Kirby Fleet Manager (Idea presentation)

Dear Kirby enthusiasts, I want to share an idea I’m working on to gather some feedback on it.

Within the last two years as a freelance software developer, I built a lot of websites and tools with our favourite CMS. For me it is very important to also offer my customers good support in the maintenance and up-to-dateness of their Kirby installations after launch. To keep track of the many Kirby instances, I’m currently working on a monitoring tool under the working title “Kirby Fleet Manager”.

The idea is to display the information from the System page of the panel for many instances in one overview. Therefore, you just install a minimal Kirby plugin and add an API key from the fleet manager to the config.php. In the screenshot you see the current state based on that I already have a lot of feature ideas:

  • Automated check of the Kirby version against for version support status and known security incidents
  • Doing the same for the PHP version
  • Automated mail reports (website not reachable, Kirby / PHP version outdated, new Kirby / PHP version available, …)

As you see, this project is still in an early stage and I would love to hear your opinions (not only) on the following questions:

  • How do you currently keep track of your Kirby instances?
  • Do you already use comparable tools and if so which ones?
  • I probably won’t be able to handle the project in my spare time, so the question: Would you be willing to pay money for such a tool? If so, would you prefer it self-hosted or as a cloud service? What would it be worth to you?
  • Are there any other must-have features for you that such a tool should be able to do?

I’m really looking forward to a lively discussion!


I’m very interested to see where you are going to take this. My current setup only really has one missing piece, which is to see current Kirby versions of installations at a glance, across different sites. Usually I go through all sites I have a maintenance contract with as soon as a new release comes out.

Everything else is covered by other pieces:, BetterUptime, my Grafana, etc.

1 Like

Thanks @tobimori for your feedback! Yeah, my goal would be to be able to provide at least the application-sided monitoring tools within one application. Gathering error logs from Kirby (a hook on system.exception) would also be a nice feature I think.

Which features do you use from BetterUptime, just the basic response time stats or more of the suite?

I use the free tier, no specific features, just basic monitoring with Slack notifications. Same for Sentry, which I use for error capturing.

My current setup only really has one missing piece, which is to see current Kirby versions of installations at a glance, across different sites.

This is something I think I pitched to @bastianallgeier ages ago as an extra feature for the licenses website. Maybe it was back in the Slack days.

Like you, most of my setup is already covered by other tools (a combination of monitoring, telegram bots, and DO/Hetzner emails if something is happening) so an overview of the various Kirby installations is the only thing missing.

  • How do you currently keep track of your Kirby instances?

I personally don’t. If it’s personal projects I keep them up to date. If it’s client stuff when I’m tasked to do anything on a site i’ll just use that opportunity to upgrade what needs to be upgraded. But my sites are 99% of the time only using Kirby and no plugins so there’s not much that can break. And i’m not all that concerned about security since I don’t work on anything critical.

  • Do you already use comparable tools and if so which ones?

Personally don’t use anything similar. I do general monitoring using other tools though.

  • I probably won’t be able to handle the project in my spare time, so the question: Would you be willing to pay money for such a tool? If so, would you prefer it self-hosted or as a cloud service? What would it be worth to you?

Would not pay for it as a subscription/hosted service since it’s not mission critical for me. As a standalone product I can download and run on my server or even on my local machine it could be interesting.

  • Are there any other must-have features for you that such a tool should be able to do?

For my personal use case no.

1 Like

This looks really cool. We always thought about adding more system information to the overview in the hub and as @manuelmoreale mentioned we also discussed similar tools before. The main point for us in the team has always been security. How could we reliably build a secure connection to each installation to fetch system and server info? Our best bet so far has always been to not communicate with the client servers at all. It feels like it would open a can of worms. But that’s only our team decision.

I personally would love to see something like this as a third-party offer for freelancers and agencies who have to deal with a lot of installations. If this is something that users can run on their own servers, the responsibility is completely different. While a hosted solution of course offers a lot more comfort, I would probably always prefer something self-hosted tbh. Or maybe there’s room for both: Free as a self-hosted solution and paid as a hosted solution?


I think a self hosted solution combined with a way to expose the information currently available in the System tab in the panel could go a long way.

1 Like

Thanks @bastianallgeier and @manuelmoreale for your perspectives!

I totally share your thoughts regarding security and responsibility, Bastian! Self-hosting may be the ideal compromise and would certainly meet the expectations of many Kirby developers, including myself.

Publishing the source code would be a matter of course for me. The transparency certainly also helps in terms of security and trust. The overall challenge will probably be to find a fair licensing model, at least for commercial use, that allows financing development but especially the maintenance of the tool.

I’m very curious about further feedback, because ultimately the idea is to make life easier for the community here :slight_smile:

Same as Manuel, I use to manage my servers and Kirby website. I update Kirby with Composer.

@manuelmoreale Do you get a free email box with your DNS when you sign with Hetzner ?

1 Like

I have no idea. I don’t mix my hosting with my emails so I never looked into that.

I’d love to see something like this, and (once I have a few more Kirby sites under my belt) would definitely be willing to pay for a self-hosted version.

I host my sites using Ploi and monitor them using Oh Dear. Oh Dear has an “Application Health Monitoring” feature, and I’ve always thought it would be great to have a Kirby plugin for this so that the various Kirby environment and security statuses could be monitored centrally.

[Scroll down for some screenshots]

Hey guys, many thanks for all of your opinions! After your cautious but overall very positive feedback, I decided to give it a shot! In the following, I want to give you some insight into my ideas and considerations as well as my progress on the kirby fleet manager (short: kfm):

1. System design

The first idea evaluation from the screenshot above was with Python/FastAPI as a backend framework, which is my intuitive choice for tinkering. But as you expressed a clear preference for self-hosting, a PHP-based stack will probably be much more intuitive for the Kirby developer community. So I decided to go with Laravel, which is an really awesome framework and brings nearly everything I need. It also brings multiple database adapters (sqlite, MariaDB, PostgreSQL, …), which might be helpful for different deployment scenarios.
Frontend-wise I thought about using Vue.js, but for now I will stick with Blade templates and Alpine.js for some interactive elements.

2. Features

I want to get started with the three main features: Uptime monitoring, a Kirby system overview and of course Notifications if something goes wrong. All three are or will be based on Laravel’s tasks scheduling, which comfortably needs a single cronjob to be configured.

2.1 Uptime monitoring

As a first step, I implemented a simple ping request with latency measurement, status code tracking and some other metrics. The data get stored in the database and I set a data retention period of seven days – later this will surely be an user adjustable value. And: Uptime monitoring will of course work for any website, not only Kirby pages.

2.2 Kirby System Overview

The overall goal is to display all relevant metrics from the Kirby system tab and give some helpful advices. Currently, it only visually indicates if Kirby is at the latest version (green) or not (orange). The next step here is to give more insights by parsing and distinguish between feature (orange) and necessary updates (red). And the same also for Plugins. Additionally, also the known incidents will be listed on the details page for a website, as in the Kirby system tab.

I’ve taken @bastianallgeier security concerns about dumping system information out of Kirby to heart, and after much deliberation I think I’ve come up with a really good and secure solution for this:
I’m planning to implement an OpenID Connect/OAuth2.0 based authentication/authorization flow using Json Web Tokens (short: JWT) and Json Web Key Set (short: JWKS). Thereby, kfm issues a JWT using public-key crypto and sends it together with the query request to the endpoint provided by the kirby-fleet-manager-plugin at a Kirby instance. In the plugin config, the web address to the kfm is configured, so that the Plugin can reach the kfm’s JWKS (containing the public key of the issuer) and can thereby cryptographically verify the incoming request.
This exact method is for example used by Microsoft Azure to provision user and group data to external directories, which are at least as worthy of protection as our Kirby system information. And for those who are particularly cautious, there can additionally be an IP whitelisting :wink:

2.3 Notifications

Obviously, this is quite important. I’ll start with basic email alerts and if the need is there, there will certainly be further integrations such as Telegram bots later on. The exciting part is definitely finding sensible mechanisms so that the notifications don’t get on your nerves. Good default settings are certainly the first, generous configurability the next step for later on.
Uptime issues should probably be sent after some retries and I’m thinking about a batched email notification for all pages when there are available or necessary Kirby updates. It should also be possible to mute individual pages if, for example, the support contract with the customer has expired.

3. Roadmap

It’s really important to me to build something many can profit from. So please let me know what you think, here, on Discord or via Please also let me know (preferably by mail) if you’re interested in beta testing or even contributing!

After collecting your feedback, I’m planning to add the missing features described above for a stable and satisfactory V1 of the kirby fleet manager. Until then, I would also like to find a suitable license model. Currently I have in mind that the tool can be used for up to 3 websites free of charge and above that a one-time license fee for each major version is needed. And as soon as the license is in place, the source code can also be published.

When I got this far I will be very happy, but I have many more feature ideas for later on and I hope you too! For example:

  • Multi-user and team management
  • 2FA security for login
  • Collecting error logs from Kirby installations
  • Lexoffice integration for automatic sending of Kirby update offers to customers without maintenance contracts

So, please let me know your ideas and opinions on this!


You can hook into our UpdateStatus class to avoid having to reimplement the version comparisons from security.json manually:

Maybe is already planned, I think showing version number of the installed plugins can be really useful too

Hi @lukasbestle, many thanks for pointing this out! I had already seen that class, this should be of great help!

Hi @ponchoelastic, this is already (partly) there. If the plugin version is available (requires a composer.json in the plugin directory), it gets shown on the details view with an indication, if it is on the latest version. Later on, there will also be the check for updates and possible vulnerabilities.

Hey guys, here comes an update on the progress :tada:

I just published the Kirby plugin, which will enable the communication between a Kirby instance and the KFM. It’s called kfm-connector and is available at

The plugin exposes a single API endpoint at kfm-api/v1, which is used by KFM to query the relevant data of the Kirby installation and secured by JWT authentication.

Out of transparency reasons, I decided that the plugin should include all the code necessary for the JWT authentication flow (as described above). Under the hood it uses firebase/php-jwt and also includes implementations to create RSA certificates and generate JSON Web Key Sets, which is used on the KFM side.

I decided to publish the plugin as open source under the MIT license and the whole implementation is only a few lines of code. Any code reviews are very welcome!

Meanwhile, also the KFM itself makes good progress. The remaining tasks are primarily the notification system and the licensing part.

So much for the current status, I’ll report back here if there is anything new.

Very interesting and good idea. It would be nice aswell to display plugin versions (maybe only from selected ones). For e.g i have a template for my customers and this would be a nice way to keep track of outdated versions.

Thanks @Khepri.Design! Plugin versions are already shown on the details page, if the version is set in the composer.json (same behaviour as in Kirby`s System page). I’m also planning to later have the same granularity of version hints as for the Kirby version, although plugins must support this.