What are the hardware requirements for running Magnolia?
Hardware recommendations are dependent on the way the application is hosted, as the underlying stack (i.e. hypervisor / OS / containerization stack) must be accounted for.
The recommended specifications for the application itself (in production mode) are:
- CPU: 4vCPU
- Memory: 12GB for the author instance, 8GB/instance for publics
- Storage: Min 30GB. This size depends on the amount of content (pages / assets) that will be stored and may vary from project to project. In addition, external storage (i.e. S3 or Azure Blobs) might be used for the storage of assets.
The considerations are identical to the Self-hosted variant. On Magnolia PaaS, the application is hosted using Managed Kubernetes Services. Kubernetes runs on clusters of 3 nodes, which can be provisioned as:
- 3x 4vCPUs / 16 GB memory
- 3x 8vCPUs / 32 GB memory
Which operating systems and servers are supported by Magnolia?
The Magnolia application is OS agnostic. Please refer to the certified stack for more details.
The application is hosted in a containerized environment making use of Linux as base image (Alpine Linux / Debian / Amazon Linux).
What are the software dependencies for installing Magnolia?
The dependencies can be found in our documentation, on the certified stack page. In a nutshell, the following components are required:
- A database (supported options can be found in the documentation)
- A Java runtime environment (Java 11 or Java 17)
- An application server (preferably Tomcat or JBoss EAP)
- Also, we strongly recommend hosting the application behind a Firewall (WAF) and a LoadBalancer / Reverse Proxy.
All the required dependencies are taken care of when the application is hosted on the Magnolia PaaS. Magnolia PaaS comes with a CDN and WAF Service from Fastly and makes use of Nginx as Ingress (Load Balancer / ReverseProxy) service.
Is there a recommended web server or application server for hosting Magnolia?
It’s best to use a technology stack your engineers are familiar with. Our recommendations are:
- Tomcat as an application server
- Nginx as a potential reverse proxy server (in case the target architecture requires this component).
Not applicable. The software dependencies are taken care of when the application is hosted on the Magnolia PaaS.
Do we need additional capacity to handle scalability and high availability for the infrastructure?
This depends on the technology used. Generally speaking, this can imply more compute resources (v)CPU, memory and storage in order to account for more Magnolia Public Instances.
The same considerations apply to Magnolia PaaS. More resources can be added to a cluster by scaling out horizontally or vertically depending on the use case. Also, Magnolia PaaS extensively leverages CDN caching for scalability purposes.
Do we need additional capacity to handle scalability and high availability for the infrastructure?
This depends on the technology used. Generally speaking, this can imply more compute resources (v)CPU, memory and storage in order to account for more Magnolia Public Instances.
The same considerations apply to Magnolia PaaS. More resources can be added to a cluster by scaling out horizontally or vertically depending on the use case. Also, Magnolia PaaS extensively leverages CDN caching for scalability purposes.
Are there any specific network requirements to consider for integrating Magnolia with other systems?
This depends on the on-premise architecture decisions.
Third-party systems should preferably be accessible via HTTPs. mTLS can be used for mutual authentication of the systems. IP whitelisting or VPN might be configured on request, but we generally don’t recommend them.
What backup and disaster recovery (DR) solutions are in place for the Magnolia infrastructure?
This depends on the stack used to host the application. Operations remain the customer's responsibility.
We recommend regular backup (or snapshots) of the disks for the application server and potential storage areas (external / network drives) and application level backups for the database layer.
The infrastructure DR plan can be provided on request. The DR depends on the underlying provider (Swiss Hosted platform, Amazon or Azure).
On the application layer, the entire infrastructure gets snapshotted on a daily basis. Database backups are in place in order to allow PITR (Point In Time Recovery) of instances.
RPOs granularity can be defined by configuration and are subject to agreement.
What are the recommended server and database backup strategies for Magnolia?
We recommend regular backup of the OS and application stack, in accordance with each company’s internal IT policies.
The database should be backed up regularly (typically once a day or once a week), depending on the RTO / RPOs required.
As an example, when using PSQL as the backing RDBMS, “Basebackups” are typically performed once a week, with regular WAL archiving (timeout definable depending on RPOs required). The same policy should be applied to any external (remote) filesystem (e.g. S3 storage / Azure Blob) if applicable.
Backups are integrated in the platform by design, using the strategy described in the Self-hosted option.
Are there any security considerations to keep in mind while setting up the infrastructure for Magnolia?
Magnolia is not different from any web application and should be hosted adequately. Please refer to the Magnolia PaaS section of this question for more details.
We strongly recommend the usage of “Security hardened” (i.e. OWASP) reverse proxies, load balancers, web servers. In addition, the usage of a WAF is strongly recommended.
Magnolia PaaS comes with several security layers out of the box.
Data is encrypted at rest, and can optionally be encrypted while in transit in the cluster itself (across nodes / pods) by using SSL. External traffic is always TLS encrypted.
In addition, Magnolia PaaS comes with Fastly WAF services by default.
What monitoring and logging tools are used to ensure the health and performance of the Magnolia infrastructure?
Not applicable, as the application hosting and operation are the responsibility of the customer.
Magnolia PaaS makes use of Prometheus / Thanos and Loki to monitor the system, collect log files and assess the health. The metrics / logs can be fed to a third party system (i.e. customer system) by leveraging Prometheus Federation and FluentBit.
What database options are supported by Magnolia?
Please refer to the certified stack for available options. In a nutshell, MySQL, MariaDB, Oracle, H2 and PostgreSQL are the products seen the most. PostgreSQL is the preferred RDBMS.
In Magnolia PaaS, PostgreSQL is the only option. Postgres is tightly integrated with Magnolia’s PaaS Cockpit and with the blueprints provided when operating Magnolia on PaaS.
Are there any specific configuration requirements for integrating Magnolia with a content delivery network (CDN)?
There are no specific requirements when integrating a CDN. Caching policies need to be set on Magnolia level.
Magnolia PaaS comes with Fastly CDN services (content delivery + WAF, Fastly IO) out of the box. Fastly services are tightly integrated in Magnolia’s PaaS infrastructure.
The customer can nevertheless bring his own CDN if so desired.
How do you handle SSL/TLS certificates and secure communication for Magnolia?
Not applicable, as the application hosting and operation are the responsibility of the customer.
Magnolia PaaS comes with ACME (by default Lets Encrypt) certificate out of the box. If desired, the customer can provide their own certificates via Magnolia’s PaaS cockpit.
What version control system (VCS) does Magnolia support for managing content and code changes?
Any VCS can be used. We commonly see in use TFS, AzureDevOPS and Git.
Magnolia prefers GIT and optionally offers GitLab hosting for PaaS projects. Customers can bring their own VCS, CI/CD pipeline, which must include a container registry.
Are there any specific requirements for integrating Magnolia with third-party systems or APIs?
There are no specific requirements, as Magnolia is very flexible regarding integrations. Integrations are mostly done via REST APIs, but other technologies might be used as well, depending on the third-party system.
There are no specific requirements, as Magnolia is very flexible regarding integrations. Integrations are mostly done via REST APIs, but other technologies might be used as well, depending on the third-party system.
How do you handle content replication and synchronization across multiple Magnolia instances?
Content replication is possible on JCR workspace level by exporting select items or entire workspaces to XML or YAML.
Alternatively, entire instances can be replicated by using database level backup and replication.
Content replication is possible on JCR workspace level by exporting select items or entire workspaces to XML or YAML.
Alternatively, entire instances can be replicated by using database level backup and replication.
How do you handle user authentication and authorization in Magnolia?
Magnolia is very flexible regarding user authentication and authorization. Authorization typically stays within Magnolia (even if managed externally) and can either remain “local” to Magnolia or “external” via the usage of the SSO module.
The SSO module natively supports Open ID Connect compatible identity providers (Azure AD or equivalent) and can be extended to other protocols (e.g LDAP / SAML) by using an identity broker like Keycloak.
Magnolia PaaS makes use of SSO for authentication and authorization. In addition, the platform comes with Keycloak IDP out of the box for flexible integration with third party identity providers.