How to best organize files/folders/repos & the deploy strategy

I was thinking about following @bastianallgeier strategy and create two separate repos as he describes below (from Interesting use cases ):

So… one for the “content” folder and other for everything else. Simple.

Let’s call them “main” and “content”.

Since I won’t be using Gitlab what is the best way I wonder… because the folders below will be modified when new users are created by kirby’s user account system (the site will allow users to create accounts (without panel access):

  • assets/avatar
  • thumbs
  • sites/accounts

I was thinking about having the basic setup of localhost / dev subdomain (stage) / live (production) environments and now I’m worried about the repos getting conflicts after the site goes live.

Is it even recommended to keep the “main” repo in sync between these environments (local/dev/live) by some pulling/pushing strategy?

I like the idea of the panel not being public accessible (live/production) but it would change the whole deploy strategy… I’d prefer lesser complex solutions.

Also… should the “content” repo be a submodule of the “main”?
What about the “content” repo… should it contains the folder “/content” itself or only its contents?

I have no objections for using deployment services like (have used it before in non-kirby projects). But also have seen webhooks, node scripts and even rsync solutions here in the forum…

I’m really lost…

1 Like

Also, what is the best way to manage plugins? A submodule for every plugin?

This article explains plugin management quite extensively:

But in a later post they acknowledge that depending of the way you’re going to publish/deploy (ftp/sftp) the symlinks won’t work due to protocol incompatibility.

In a previous blog post we showed how Kirby plugins can be managed as Git submodules. This practice could be followed here, too! But for simplicity we’ll install the plugin the conventional way. Besides, we had to experience the unfortunate incompatibility of symlinks and FTP with some of our client projects, so, while offering less maintainability, the conventional way is more robust.


I read this post, it’s great! It wood be good to hear about other opinions/methods so we can choose the most appropriate, or pick the parts that suit our projects best.

Files and folders can be a bit confusing in Kirby, especially compared to most CMSes where you have a clear place for themes (btw is there such thing as a pluggable theme in Kirby?) and libraries.
There are many ways to do it, and it’s not always easy to choose the right one.

I’m working on my first Kirby powered site and was just thinking about the issue of deploying with git without overwriting content changes made by a user through the panel.

How do most people deal with this? For this particular project I really don’t want to use a cron triggered git commit because I’m not the main server admin and I’m worried about someone removing the cron job one day and content getting overwritten.

A web-focused Git workflow This article has been of some help to me and I’m trying out a similar approach.

Same here and I still haven’t found a solution that pleases me :disappointed:.

Interested in solutions as well!
Ideally with how to deal with an FTP-only access to the online version of the website…
Best practices anyone?
(I’ve spent the last 4 hours merging ‘by hand’ my local and online version and I don’t really want to do that again :frowning: )

If you don’t have SSH access to the FTP, there are lots of apps that can sync a local folder with an FTP one.

On OS X, Transmit has a “Synchronize” feature that looks very similar to rsync. But there are tons of others, including free ones.

Take a look at, I don’t have any experience with this tool myself but might be worth checking out. Don’t know if it supports submodules, though.

Also, as @Malvese mentioned, popular FTP clients usually come with sync features, if you are not on a Mac, have a look at the open source tool FileZilla or similar …

You might want to check out this thread as well Deploying via Git