Technical best practices: Enonic for large organizations


TLDR; A strategy document on how to use enonic at scale from a technical persective.

I think it would be very useful for large organizations to have a guideline or “Best practices” document on how to use Enonic/XP at scale when you have a large body of sites, apps, projects and repositories. I have looked at this article, which was useful, but it is written more from a high level organizational perspective and not a technical perspective. Given an organization with well over 20 sites, many different projects and custom apps, I have some specific questions which I’m sure the Enonic team might have some thoughts and perspectives on:

  • Is there a good strategy on the relationship between Apps and sites? Obviously you’d want re-usability, but how much? Should Apps be small “micro services” or is it useful to keep all parts, content etc. in a few set of Apps? Why or why not? A strategy or “best practices” document could include tips like “Apps should be small and somewhat generic and customizable”.

  • What should/could be the relationship between Apps and repositories? A 1-1 explicit relationship seems easier to maintain and develop, but I can imagine scenarios where an App might use many different repos, or multiple Apps using the same repo. Do you have any thoughts?

  • Are there any strategies to make the developer experience as easy as possible given this scenario? To develop on a site locally (many developers think in terms of sites rather than Apps), we might need many apps and repos, which all need to be downloaded and configured, often manually. To dump and import the whole instance/rig to a local machine just to fix a bug on site x (out of 20 sites) seems overkill and is time consuming.

I grant that given a vast diversity of requirements and potential cases it is very hard to write an all encompassing document that will fit everyone’s needs. A good approach might be to showcase what you’d consider a good adaptation of the enonic ecosystem for a large enterprise and use that as an inspiration for documentation. A good example of what I’m talking about is terraform’s best practices documentation (I grant that an IaC tool and a CMS are two different things, but it can still be an inspiration).

Let me know if something was not clear. Otherwise, keep up the good work.

Harald Vinje


Traditionally we have usually gone for a very “1 site = 1 app”-type approach for our sites, with shared functionality (parts, services, etc) pulled in from a Gradle dependency. We have a few different brand sites that we manage which all are similar, but not exactly the same.

The big challenge over time has been to keep the different repos updated when we improve the build process for one site or if we add functionality for a specific site to the common dependency library to make sure that other sites don’t start using this functionality without having the proper styling in place and so on. We are currently trying to figure out the best way to restructure the way we build and compose sites from apps.

Reading your post gave me an idea that I haven’t looked into previously, though. Have anyone attempted to build sites from apps that provide specific capabilities instead of bundling all functionality for one site in one app? Let’s say you have one app that provides the content type, listing page, and details page for showing articles, one that provides search functionality with a search result page and a service for returning search results maybe, one app that provides a customizable landing page content type with a few associated parts and so on. On top of this, you would probably have to have a “styling app” that pulls in some CSS and maybe allows you to adjust some CSS variables so you can give each site a bit of its own theming/identity.

In theory, this should allow us to reuse functionality and compose capability per site without the complicated build process we have today. I am not sure if this introduces any other challenges either with developer experience or with editor experience though.

Anyone got any experience trying to build XP sites like this?


Hi Harald, and thanks for reaching out.

This is certainly a good topic for people that know the basics, and want to go to the next level. This might very well deserve a section (or maybe even a separate guide) in our documentation.

Immediately, I can think of the following topics that could be included:

  • List of relevant tools you can use to research your solution/setup
  • Apps vs libs - when to use what
  • Apps - Micro, or “monolith” approach
  • Headless vs hybrid
  • Content projects - what and how
  • Content layers - what and how
  • Content modelling guidelines
  • Etc etc