Magnolia is distributed as two web-applications: author and public. Editors work on the author instance, typically in a secure location inaccessible from the Internet. Editors publish content from the author instance to public instances. Public instances serve the content to visitors. In a typical production setup you have at least two public instances, often more.

Author and Public instances

Publish–subscribe pattern

Magnolia’s author-public instance model follows the publish-subscribe pattern. In this software design pattern, an author instance acts as a publisher. Public instances take on the role of a subscriber, or receiver in Magnolia 6.2 terminology. The publisher classifies content so that receivers can register interest in a particular type of content.

In Magnolia, editors create content in a particular workspace. It is common to organize content into a hierarchical tree structure on the author instance. This process is the equivalent of message filtering in the pub-sub pattern. Public instances receive content from a particular workspace and path in the content hierarchy, receiving only content they are interested in.


Separating author instances from public instances has its benefits:

  • Security: The author instance typically resides behind a firewall ensuring that your content is never lost. Content can be republished when things go wrong on the public site.

  • Loose coupling: The instances are loosely coupled through content publishing relations and operate independently regardless of the performance of the other. They reside on different servers and the authoring process is not disturbed by public server failure. Public instances can be easily decoupled and recoupled.

  • Scalability: A single author instance can connect to multiple public instances. The model fits any infrastructure size and you can upscale and downscale as necessary.

  • Flexibility: Variations of content can be served to different public instances. This makes for efficient authoring because content can be reused and adapted to specific audiences.

  • No single point of failure: If you run fully redundant configurations where an independent database backs each Magnolia instance. For more, see Deploying instances.

Magnolia’s author/public instance model is very similar to the publish-subscribe messaging pattern.

Differences between author and public instances

Author and public instances run identical software. They both have an AdminCentral that you can log into. The differences are configuration and security only.

Configuration Author Public





Not set.


anonymous role

Has author instance permissions

Has public instance permissions

anonymous system user

Has author instance roles

Has public instance roles


Has active receivers

Has no receivers

What kind of instance do I have?

There are many ways to find out what kind of instance you have:

  • Open the About Magnolia app and look for the instance type.

  • Check the /server/admin property in the configuration. It is true for author and false for public instance.

  • In Java code, use the isAdmin() method provided by the info.magnolia.cms.beans.config.ServerConfiguration class.

  • In a FreeMarker template, use the cmsfn.isAuthorInstance() or cmsfn.isPublicInstance() templating functions.

Public instances serving different content

Each public instance can serve content targeted to a particular audience or geographic area. For example, one instance can serve visitors from Europe and another visitors from the U.S.

Public instances serving different content

Magnolia’s multisite feature provides granularity for content control on multilanguage and multidomain installations. Administrators have the option to direct editors to the author instance through a specific domain. Editors edit only the part of the content structure that resides at the specified domain. To ensure a consistent browsing experience, URLs are adapted to always reflect the domain. You can also configure multiple domains to access the same instance.

Intranet and extranet

Place secure and sensitive content on separate instances. This diagram shows a possible placement strategy where a public extranet instance resides on its own instance and has its own URL.

Intranet and extranet

Planned redundancy and high availability

A distributed instance setup allows you to respond to high availability requirements and sudden increases in traffic. Here are common problem scenarios:

  • Public instance failure. You have two public instances and, due to hardware failure, one of them is out of operation for a few days. Start a new public instance to replace the broken one.

  • Sudden high load. Start new public instances until the traffic subsides.

  • Public instance blackout. All public instances are corrupted, broken or compromised. No instances exist to serve content.

You can address the issues by adding a new public instance to serve the same content, helping the existing instances deal with the load.

Instance configuration examples

Magnolia instance configurations start from a standard 3-instance setup and scale up. You can add any number of instances for load balancing and high availability. Public instances can subscribe to specific content such as intranet or extranet.

Instances configuration examples


DX Core



This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules
6.3 beta

Magnolia 6.3 beta

Magnolia 6.3 is in beta. We are updating docs based on development and feedback. Consider the 6.3 docs currently in a state of progress and not final.

We are working on some 6.3-beta known issues during this phase.