Hardware and software requirements

This section presents information about the environment needed to run an OpenKM server. It lists the required and optional software and provides facts about their configuration.

Caution

This section aims to help you validate or define the production environment. However, the checklist is not exhaustive and needs to be completed with the user’s experience in mind.

Danger

For best performance, OpenKM stores the binary content of the document in the filesystem. So, if you have a server for the database and another for the application itself, remember that the OpenKM server needs enough free disk space to store all these documents plus extra space for other files like preview cache and extracted text and Lucene indexes.

Requirements

OpenKM can be installed on any operating system (Linux, Windows, Mac OS X) since it is a multi-platform application.

Tip

A Linux host is a good choice because it handles heavy I/O applications, works well with OpenKM, and is conveniently priced.

The only requirement to run OpenKM is to have Java 17 installed.

Checking the Java version

1. Open a terminal:
   • On Linux or Mac OS X: Open a terminal.
   • On Windows: press the “Windows” key + R, type cmd (or command) in the Run window, and press “OK”, or open the “Command Prompt” from the “Start > Programs > Accessories” menu.
2. Type java -version and press Enter.
   If Java is installed correctly on your computer, the name and version of the Java virtual machine are displayed:

openjdk version "17.0.18" 2026-01-20
OpenJDK Runtime Environment (build 17.0.18+8-Ubuntu-124.04.1)
OpenJDK 64-Bit Server VM (build 17.0.18+8-Ubuntu-124.04.1, mixed mode, sharing)

If Java is not installed on your computer, it will fail to display the Java version. Then, you will need to install Java (see below).

If Java is installed but not included in the PATH, it will fail to find the Java command. Then, you will need to add $JAVA_HOME/bin to your PATH (see How do I set or change the PATH system variable?).

Installing Java

For Windows users

If the required version of Java is not installed on your computer:

1. Download it from the Microsoft website and choose the right platform for your hardware and Windows version.
2. Run the MSI file and follow the instructions displayed.

More information at Installing on Windows

For Linux users

You can download it from the Linux repositories.

apt install openjdk-17-jdk

This way, your OpenJDK will be upgraded whenever a new release is available.

In case you have another OpenJDK installed (like GCJ), you can select the right one this way:

$ sudo update-alternatives --config Java

More information on installing Installing on Ubuntu and Debian.

Recommendations

Hardware configuration

Tip

OpenKM runs quite well on any computer with a standard hardware configuration. For better performance, we recommend at least 4 GB of RAM (>= 2 GB of RAM) and a fast hard disk like SATA or better.

A dual-core Intel-based CPU with 3.20 GHz should be fine for fewer users (30-50 concurrent users).

Have enough disk space for the document repository and its versions.

A Linux host is a good choice because this OS handles heavy I/O applications like this quite well, and it is inexpensive.

A 64-bit architecture is highly recommended.

Caution

We suggest having a modern server that performs well.

Although OpenKM can be installed on a server with other applications, the best scenario is a dedicated server. Remember that other applications can harm OpenKM in a shared scenario.

For more information about hardware requirements, please consult your sales and marketing representatives. They should provide you with an estimate of the hardware requirements.

(See the questionnaire at the bottom of the page)

Note

You can use your document and folder history to get some of these values.

Sizing considerations

Caution

There is no universal formula for producing an exact hardware estimate. Variables such as hardware quality, network infrastructure, storage technology, and workload patterns all influence performance in ways that cannot be fully anticipated upfront. Treat any estimate as a starting point, not a guarantee.

Keep the following guidelines in mind when sizing your OpenKM environment:

• Prefer Linux whenever possible. Due to its superior disk I/O performance, a Linux server will consistently outperform an equivalent Windows server under the same hardware specifications. When both options are available, Linux is the recommended choice.
• Plan for at least five years of growth. Hardware sizing should account for a minimum five-year horizon. Factor in user growth, document volume increase, and repository expansion over that period.
• Virtualized vs. dedicated environments. In virtualized environments, resources can be added on demand, so it is acceptable to start closer to the minimum and scale up as needed. In dedicated server deployments, the opposite policy applies: size generously from the start, or at the very least ensure the server supports future RAM and CPU upgrades.
• Account for peak demand scenarios. High-demand periods, such as scheduled bulk imports or automated robot uploads concentrated in specific time windows, can put significant stress on the system. These scenarios must be considered during the estimation phase.
• Apply performance best practices for high-throughput deployments. In addition to investing in capable hardware, high-performance environments benefit from good practices such as using tailored API requests, disabling unnecessary features or modules, and tuning the application configuration to match the actual workload.
• Write operations are the primary driver of hardware demand. Operations that modify application data — document creation, updates, and deletions — are significantly more resource-intensive than read operations, as they involve disk writes, index updates, and database transactions. Read operations, by contrast, are generally well-handled by standard hardware configurations and are rarely the root cause of performance issues. When sizing hardware, pay particular attention to the expected volume and frequency of write operations, as these will be the main factor determining the resources required.

Hardware sizing examples

The following examples illustrate hardware recommendations for three representative deployment tiers. They are intended as a reference, not as exact prescriptions. Always validate estimates against your specific workload using the questionnaire below.

Caution

The figures below assume a Linux server. For Windows deployments, add at least 2 CPU cores and 2 GB of RAM to each tier to account for the additional overhead of the operating system.

Basic tier

Moderate usage with the majority of users performing read operations. No automated ingestion processes — all uploads and queries are initiated by human users. Up to 20 concurrent users, fewer than 100,000 documents added per year, and a total repository below 1 million files.

Tip

4 CPU cores · 6 GB RAM
MariaDB is the preferred database for this tier. This configuration is well-suited to small teams and departmental deployments with predictable, low-intensity workloads.

Medium tier

More extensive usage with a predominantly read-oriented user base, but with approximately 25% of users performing write operations. No automated ingestion. Between 20 and 100 concurrent users, fewer than 500,000 documents added per year, and a total repository below 5 million files.

Tip

8 CPU cores · 12 GB RAM
MariaDB is the preferred database for this tier. This configuration suits mid-sized organisations with a significant volume of document activity and a mixed user base of readers and contributors.

High tier

Intensive usage with more than 100 concurrent users, automated ingestion processes (robots), more than 500,000 documents added per year, and a total repository exceeding 5 million files. Peak demand periods driven by scheduled bulk uploads must be accounted for.

Tip

16 CPU cores · 24 GB RAM
Oracle or PostgreSQL are the recommended databases for this tier. A dedicated database server is strongly advised to isolate database I/O from the application workload and ensure consistent performance under peak conditions.

Disk sizing

Disk capacity for the OpenKM server should be at least 1.3× the expected repository size to accommodate temporary files, preview cache, extracted text, and Lucene indexes.

Regarding storage technology:

• OS, application, and database should reside on an SSD. These components are highly sensitive to I/O latency, and SSD storage has a direct and significant impact on overall platform performance.
• The document datastore (where binary content is stored) is less sensitive to I/O latency. In high-volume deployments, it can be mounted on lower-cost spinning disks such as SATA 7200 RPM drives or equivalent, without a significant impact on the user experience.

Browser support

The OpenKM user interface is based on the GWT framework, which means the supported browsers are determined by GWT browser support.

Currently supported browsers:

• Mozilla Firefox
• Google Chrome and Chromium
• Microsoft Edge

Caution

Although you can use other browsers, such as Safari or Opera, we suggest using the latest version of Google Chrome.

Tip

We encourage you to keep your browser updated to the newest version.

We recommend Mozilla Firefox and Google Chrome because they offer the best performance, have fewer security holes, and follow the standards.

Operating systems

Linux (Known working configurations):

• Ubuntu
• Debian
• CentOS
• Red Hat Linux

Caution

Red Hat Linux is a more complex scenario because some packages aren’t in the Red Hat official repositories by default.

Tip

Ubuntu is the preferred Linux choice. We run the tests against Linux distributions and build the packages for them. However, any recent Linux distribution should be usable as long as the:

• OpenJDK 17 is available.
• You can adapt the provided Linux scripts.
• Thirdparty software requirements

Windows (Known working configurations):

• For development: Windows 7, Windows 8
• For production: Windows Server 2003, 2008, 2012, 2016, 2019, 2022 and later versions

Databases

Known working configurations:

• MySQL
• Oracle
• PostgreSQL
• SQL Server

Note

The application internally uses Hibernate; in fact, you should be able to run it with any supported Hibernate dialect; for more information, read Hibernate: SQL Dialects.

JVM

Although OpenKM can run with other JDKs, we recommend using OpenJDK 17. A 64-bit architecture is highly recommended.

LDAP

• Open LDAP
• Microsoft Active Directory

Small questionnaire

Caution

The average value is particularly interesting in questions where the expected answers are numerical.

Try to give them as much detailed information as possible for a more accurate estimate using this basic set of questions:

• Estimated number of concurrent users.
• Type of users (% of readers and % of writers).
• Estimated first-year number of files.
• Estimated number of files growing per year.
• Estimated document size average.
• Number of documents in the initial import.
• Are these documents uploaded by users or automatically?
• Most common document types (Microsoft Office, LibreOffice, PDF, etc.).

The more detailed questions below are a guide to describe the document management problem to solve and may be helpful to estimate hardware requirements:

• Do you have an initial import of documents?
  • If so, how many?
  • If so, what is the size of the data in GB?
• How many records are created in a day?
• How many documents are made in a week?
• How many documents are made in a month?
• How many documents are made in a year?
• What is the expected repository size in GB for the first year (initial import not included)?
• What is the typical document size in your repository?
• How many concurrent users are expected?
• How many of the simultaneous users are readers, and how many are writers?
• Do you have some daily, weekly, or other kinds of periodic bulk uploads?
  • If so, how many documents are uploaded?
  • Can the bulk upload be done during non-working hours?
• Will you have some integration with third-party applications?
  • If so, describe the usage in terms of:
    • Will it be used to read data?
    • Will it be used to write data?
    • How many queries are expected per minute and per hour?
• What kind of documents do you manage, such as standard Office documents, PDFs, or less common documents like video and large TIFF files?
  • Describe them, especially those you know are not common in most companies.