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.
Information about the server requirements for running the application.
# Hardware requirements
Since Collaboration Server On-Premises can be installed in two ways, below are the hardware requirements for both installation approaches.
You can find more information about available installation methods in the Installation section.
- Concurrent user — A user who is active in a collaborative editing session. Idle users connected to the document do not increase the server load much.
- The above configurations are able to handle an even larger number of active users, but due to the server load, the response times will be significantly higher and as a result, the user experience will be affected.
- The Collaboration Server On-Premises performance was checked on Amazon AWS, using EC2 “t2” instances.
The number of containers that can be run depends on your servers. Crucial resources are CPU (cores) and RAM. The number of containers that can be started in the environment depends on them.
For every 250 concurrent users, Collaboration Server On-Premises requires 1 additional Docker container with minimum 500MB of RAM limit.
- 1 Docker container and minimum 500 MB RAM support up to 250 concurrent users.
- 2 Docker containers and minimum 1 GB RAM support up to 500 concurrent users.
- 4 Docker containers and minimum 2 GB RAM support up to 1,000 concurrent users.
- 8 Docker containers and minimum 4 GB RAM support up to 2,000 concurrent users.
- 16 Docker containers and minimum 8 GB RAM support up to 4,000 concurrent users.
For every 250 concurrent users, Collaboration Server On-Premises requires 1 additional core of CPU and 500MB of RAM.
- 1 core and 500 MB RAM support up to 250 concurrent users.
- 2 cores and 1 GB RAM support up to 500 concurrent users.
- 4 cores and 2 GB RAM support up to 1,000 concurrent users.
- 8 cores and 4 GB RAM support up to 2,000 concurrent users.
- 16 cores and 8 GB RAM support up to 4,000 concurrent users.
These calculations allow you to run Collaboration Server On-Premises without having to set up load balancers.
# High availability
To ensure high availability, we recommend running at least 3 instances of the application.
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 SSL communication guide), is required for scaling on several machines. Of course, it is possible to use any cloud provider for scaling, like Amazon ECS, Azure Container Instances or Kubernetes.
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.
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.
- 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.
- Version 5.6 or 5.7.
- 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_unicode_ci;
- Change the
max_allowed_packetsetting 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 12.0 is the minimum and recommended 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
CREATE DATABASE "cksource"; \connect "cksource"; CREATE SCHEMA "cs-on-premises";
# High availability
To ensure high availability of Redis, we recommend using Redis in Cluster mode with at least 3 nodes (must be an odd number of nodes) and using the master-slave model, which means that the number of servers increases to 6. In this configuration, every node should have at least 2 cores and 2 GB of RAM.
Please note that when using Redis Cluster you must run applications with the correct configuration, which is described here.
To ensure high availability of MySQL, we recommend using MySQL Master-Slave Replication with one active master. You can find more information about MySQL replication here.
We recommend using one master because the data in the application is modified quickly and it is often the case that the data between nodes is not synchronized due to replication lag.
In case of a failure, the application will not automatically switch between the nodes, so it is worth looking into a load balancer that will automatically turn the connection between the nodes.