What is the strategy to maintain multiple Kirby installations?

I’m currently implementing my :tada: first Kirby project, with more to come.
The question is how to reduce the maintenance effort. Some blueprints, controllers, snippets collections etc. will be used in unchanged form in further projects. It makes a difference whether I make changes, optimizations and bug fixes to one Blueprint or 10 times.
I am aware that each Kirby installation is on its own server. But it is easier to synchronize folders or individual files than the content/code.
What is the foresight concept to not get bogged down in maintaining quite a few installations at some point and to keep track of everything?

Blueprints, templates etc. can all be registered in plugins, so for stuff that you will likely have in multiple projects, it might make sense to create something like a base stuff plugin that you can then reuse across projects.

Blueprints/controllers/templates etc. defined in plugins can be overwritten in the site folder, so for individual changes to projects, that would be the way to go.

Thanks for the quick reply.

Is there any further information on this subject, either at getkirby.com or externally?

I’m not expecting a ready-made cookbook recipe to copy-and-paste. But basic info would be helpful to get on the right track.

I imagine the situation where I have 15 Kirby projects and need to apply a security update in a timely manner. Or want to make an improvement that will benefit all 15 projects.

Now at the beginning with the first project it is still easy to find a good strategy.

Well, we have the documentation about the different plugin types and general plugin information. I think that’s all that is really needed, no?

Regarding Kirby itself, i.e. updating all projects with a single stroke, that would only be possible if the projects live on the same server, then you could use a single Kirby folder with multiple projects.

Two options here:

1 Like

Thanks for the link compilation.
There is valuable info in there.
Especially interesting for me:

and

Can this concept be used for projects that are in development?

  • kirby
  • company-123
    • content
    • media
    • site
    • assets
  • company-abc
    • content
    • media
    • site
    • assets
  • index.php

This also raises the question of the license. If a project is final and goes to the live server, the license is also activated for this domain.

How do I license the test environment? Is 1 license enough for this?
These projects are not public and the license for the live server is already purchased.

This note refers to live projects, right?

Yes, of course.

You don’t need a license during development. Please re-read the license terms :grinning:

But you do need a license for every project in production, no matter if you use the “multiple-sites one kirby folder” approach or not.

1 Like

Thabk you! On the subject of licenses, I have understood everything correctly.
And with the links I have plenty of reading to deepen my knowledge.

I feel very much what Jon Hicks writes on the front page of getkirby.com:

I feel like I’ve only scratched the surface of what Kirby’s capable of.

Happy to help!

1 Like

The instructions seem to fit only for an installation on a web server. I would like to use with MAMP only one Kirby folder and there my different customer projects. The structure can remain as in the instructions. But I have to adjust the routing very likely, but I see myself a little overwhelmed…

That doesn’t make a difference, because MAMP comes with a webserver (or in fact two to chose from, Apache and Nginx), otherwise you wouldn’t be able to run your websites.

Having said that, I don’t know how you use MAMP, with or without hosts? I’d recommend using hosts.

So what exactly is the problem you encounter?

Although, MAMP has changed how it works a few versions ago, if I remember correctly I have run into issues with the multisite setup when I last tried it because they removed being able to point multiple sites to the same folder.