Instances
Magnolia CMS is distributed as two web-applications, one acting as the authoring instance and the other as the public environment. This allows for better security, having one application inside your firewall and one outside. It also enables clustering configurations.
Author instance is where all authors work. It typically resides in a secure location such as behind a corporate firewall, inaccessible from the Internet. The author instance publishes content to public instances.
Public instance receives the public content and exposes it to visitors on the Web. It resides in a public, reachable location. You can have more than one public instance, serving the same or different content.
Each instance functions as an independent application but technically they are the same. An author instance can be configured to function as a public instance and vice versa. The differences are small adaptations in configuration and security. Security for the public instances is usually managed separately.
- Public instances serving different content
- Intranet and extranet
- Planned redundancy and high availability
- Instance configuration examples
- References
Public instances serving different content
You can manage multiple sites from the same author instance. Each public instance can serve content targeted for a specific geographical area, for example.
Magnolia CMS's multi-site feature provides granularity for content control on multi-language and multi-domain installations. Administrators have the option to direct content authors to the public site through a specific domain. Authors 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
Magnolia CMS allows for flexibility in placing secure and sensitive application instances. The diagram below illustrates a possible placement strategy where an extranet publishing instance resides outside the firewall but an intranet instance is inside. More advanced configurations can be built to place intranet and extranet instances inside a firewall, for example.
Planned redundancy and high availability
A distributed instance setup allows you to respond to high availability requirements and sudden increases in traffic. Each of the following problem scenarios can be addressed by adding a new public instance to serve the same content, helping existing instances deal with the load.
- Public instance failure. Imagine you have two public Magnolia CMS 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 on your site, also known as Slashdot effect. Spin off new public instances until the traffic subsides.
- Public instance blackout. All public instances are corrupted, broken or compromised. No instances exist to serve content.
Instance configuration examples
Magnolia CMS configurations range from a minimal one-machine setup to a standard three-instance production setup and beyond.
- Minimal. Author and Public instances exist on the same server. This is the default configuration when you install Magnolia CMS on your computer to try it.
- Reduced. Author and Public instances exist on separate servers. The two Public instances are on the same server or one of the Public instances resides on the same server as the Author instance.
- Standard. Public instances exist on separate servers. This configuration enables load balancing. Incoming requests can be directed to one server or another depending on availability.
