Recommended Deployment

The small deployment consists of a single instance of each of these components: Gentics CMS, Gentics Mesh, Gentics Portal, MariaDB, Elasticsearch and Keycloak. This setup offers all the recommended feature set, while not offering high availability.

The medium deployment improves on the small deployment by adding a master-slave setup for MariaDB, running Gentics Mesh as a 3-node cluster plus one node for non-disruptive backup, and two instances of Gentics Portal. Furthermore, Elasticsearch and Keycloak are recommended to be run in clustered mode.

For large deployments, where downtimes are to be avoided at all cost, we recommend to also run Gentics CMS in clustered mode, and add additional nodes to Gentics Portal, MariaDB, Elasticsearch and Keycloak.

If you need high availability in the backend, choose “large”.

If you need high availability in the frontend, choose “medium”.

Only choose “small” when website downtimes in certain deployment or upgrade scenarios are acceptable.

The following table contains the recommended number of CPU cores and memory you should plan for each deployment. The values are required per instance — so don’t forget to multiply with the number of instances you plan to run concurrently.

We recommend using Kubernetes to manage all your applications, keep them in a healthy state, and allow for rolling updates and maximum availability.

If the complexity brought in by Kubernetes exceeds your acceptable level of infrastructure fanciness, the second best choice is to spawn the docker containers manually in virtual machines, and take care of error recovery, logging, load balancing, etc. manually. In such a setup, it is usually a good idea to give your Elasticsearch instances separate virtual machines, as Elasticsearch is not a good neighbor.

For maximum stability and performance, databases require a storage backend that supports direct I/O and reliable locking. Therefore, make sure that the database files of Gentics Mesh, MariaDB and Elasticsearch can access their storage via SCSI, iSCSI, Fibre Channel, FCoE, or equivalent. Local disks are fine as well, if that’s an option. Don’t use a remote or clustered file system, like NFS or GlusterFS. Don’t use a fancy file system like ZFS, unless you know what you are doing.

However, shared filesystems like NFS are fine for using as a shared storage for binary uploads, logs, backups, etc.

While most components support clustering, this always comes with an additional, sometimes hidden cost of added complexity. Make sure you have assessed your availability requirements and downtime costs before deciding which components to cluster. Disclaimer: We do not recommend clustering with OrientDB.

We have successfully deployed Keycloak in many customer projects and recommend using it if your application requires such functionality.

Gentics Content Management Platform comes with many optional components, like plugins, language tools, file-upload manipulators, etc. These add-ons are not covered in this recommendations.

Place the backend components (Gentics CMS with its database(s)) and the frontend components (Gentics Mesh, Gentics Portal, Elasticsearch) in separate network segments, separated by a firewall.

Don’t use Windows servers in production for Gentics Content Management Platform.

For development, use a docker-compose stack. This stack can be used on either Linux, MacOS or Windows. Please make sure that the machine is equipped with sufficient memory — especially on the latter platforms.