Requirements

This article describes the requirements that need to be met for Collaboration Server On-Premises to run smoothly.

A valid license key is needed in order to install Collaboration Server On-Premises.
Contact us for a trial license key.

# Collaboration Server On-Premises

# Hardware requirements

It is impossible to provide a single infrastructure setup, that will fit all use cases. In this section, we provide recommendations for ensuring high availability and high performance of Collaboration Server On-Premises. As every use case is different, you need to monitor your application and adjust the infrastructure to your needs.

The performance of On-Premises is influenced by used features. Currently, we can consider 2 cases:

  • basic features related to collaboration on documents,
  • features that require an editor bundle.

Basic functions such as: creating a document, writing in a document, broadcasting changes to users, adding comments, creating suggestions, or sending webhooks do not require a lot of hardware resources. The performance of the On-Premises server can be defined as the number of simultaneously processed requests per single CPU core.

A single instance of On-Premises running on a server with 1 core can handle 20 requests per second. This number may be different for your use-case and it is recommended to monitor the load and adjust the infrastructure if needed. To measure the number of requests handled by the On-Premises server, you can turn on the metric logs section where you can see what requests are processed by the server and check the processing time of these requests (duration property).

Based on the observation of the number of requests and the time of their processing, it can be concluded whether the number of On-Premises instances should be increased or changes should be made to other parts of the infrastructure (e.g. databases). Read more about our recommendations for monitoring logs and resources.

# Features that require an editor bundle

Collaboration features (that use an uploaded editor bundle) have high CPU consumption. The above-mentioned throughput of 20 requests per second may significantly drop. Therefore, if features that require an editor bundle are used and frequent use of these features is expected, we recommend using the Collaboration Worker.

A single instance of Collaboration Worker running on a server with 2CPU and 2GB RAM can handle an average of 30 document conversions per minute. In addition, we recommend that every single instance (docker container) of the Collaboration Worker should be on a dedicated server because 2 instances on the same server will steal each other’s server resources. It means that the number of simultaneous document processing will not be doubled.

The conversion processing time may change depending on what plugins are used in the editor bundle and on the size of the content. Therefore, to provide users with a good experience, it is necessary to monitor the processing time of requests and in the case of delayed times, scale up the Collaboration Worker instances. Read more about our recommendations for monitoring logs and resources here.

# High availability

To ensure high availability, we recommend running at least 3 instances of the CKEditor Collaboration Server On-Premises.

CKEditor Collaboration Server On-Premises can be scaled with Docker containers on a single host machine. However, we recommend scaling on at least three host machines to provide the reliability of the system.

A load balancer, like HAProxy or NGINX (see the load balancer configuration examples in the Reverse proxy guide), is required for scaling on several machines. Of course, it is possible to use any cloud provider for scaling, such as Amazon ECS, Azure Container Instances, or Kubernetes.

# Software requirements

Currently, we only provide Linux-based Docker images for the CKEditor Collaboration Server. We highly recommend running them on machines with Linux, but you can also use Docker Desktop to run our Docker images on other operating systems.

The application is provided as a docker image by default.

It can be run with any Open Container runtime tool e.g. Kubernetes, OpenShift, Podman, Docker and many others.

In the case of Windows machines, you need to enable the WSL 2 backend and switch to Linux containers. Make sure that your operating system supports such an option. Refer to the Docker Desktop installation guide for more information.

# Databases

Information about the requirements for databases.

# Hardware requirements

The minimum database server requirements (for MySQL and Redis installation) to handle up to 8,000 concurrent users is 2 cores and 4GB of RAM (a1.large equivalent on Amazon EC2).

If your installation has to support more than 8,000 users, contact us to discuss the most optimal hardware setup for your needs.

# Containers

Databases can be launched as containers, but this requires high awareness and responsiveness. Because each company has different policies and arrangements, we do not recommend any approach and leave the decision as to how the databases will be launched for you.

However, we encourage you to read this article “To run or not to run a database on Kubernetes: What to consider” before making a decision.

# Software requirements

Requirements for database engines: Redis and MySQL/Postgres.

# Redis

  • Version 3.2.6 or newer.
  • Redis stores all temporary data related to collaboration and is used as cache. The storage requirements for Redis depend on the number of active documents.
  • The average size of one document is around 500KB of memory in Redis. This size depends on many factors — the document length, the number of users, the number of changes, etc. and it can grow to many megabytes.
  • Use Redis Cluster if the application needs to handle a large number of active users. Please contact us if this is the case.

# MySQL

  • Version 8.0 (recommended) or 5.7 (minimal supported version).
  • Create the database and a user with the following permissions: ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, TRIGGER, UPDATE, LOCK TABLES, REFERENCES. Example database creation script:
    CREATE DATABASE `cs-on-premises`
      DEFAULT CHARACTER SET utf8mb4
      DEFAULT COLLATE utf8mb4_bin;
    
  • Change the max_allowed_packet setting to allow saving blobs for documents storage feature (editor bundles, document content, etc.) in the database:
    set global max_allowed_packet = 209715200;
    
  • MySQL stores all persistent data like comments, users, environments information, etc. The storage requirements for MySQL depend on many factors.
  • If you want to use another SQL database like Microsoft SQL Server, etc., please contact us.

If binary logging is enabled without the SUPER privilege, please make sure that log_bin_trust_function_creators is enabled. Check your configuration, especially when you use managed database service (DBaaS) like AWS RDS/Aurora, Azure Database, Google Cloud SQL or DigitalOcean Managed Databases.

# PostgreSQL

  • PostgreSQL version 14 (recommended) or 12 (minimal supported version)
  • The database and user should have at least the following privileges: SELECT, INSERT, UPDATE, DELETE, REFERENCES, CREATE, USAGE.
  • The database with a schema should be created before running Collaboration Server On-Premises. Example database and schema creation script (for psql):
    CREATE DATABASE "cksource";
    \connect "cksource";
    CREATE SCHEMA "cs-on-premises";