Complete Guide to Open Journal Systems (OJS) Installation & Server Architecture

Open Journal Systems (OJS), developed by the Public Knowledge Project (PKP), is the world’s leading open-access scholarly publishing platform, powering over 30,000 journals globally. While standard content management systems serve static blog posts, OJS manages a complex, multi-stage state machine encompassing submission intake, double-blind peer review, copyediting, proofreading, JATS XML production, and long-term OAI-PMH metadata harvesting.

Running OJS reliably requires an architecture that separates the web tier, application runtime, database storage, and persistent file repository. A failure in any one of these components risks manuscript corruption, reviewer deanonymization, or indexing delisting by Google Scholar and Crossref.

For mission-critical journal hosting, Ubuntu Server 22.04 LTS or 24.04 LTS provides the ideal stability balance with long-term security updates. Alternatively, enterprise Red Hat derivatives like AlmaLinux 9 or Rocky Linux 9 offer robust SELinux integration.

A standard production journal publishing 50 to 200 articles annually requires a minimum of 2 vCPUs, 4GB of RAM, and 50GB of NVMe SSD storage. High-volume university presses running multi-journal portals hosting 10+ journals should start at 4 vCPUs, 16GB RAM, and 200GB+ NVMe storage with separate object storage or NFS mounts for galleys.

While Apache with mod_php was historically common for legacy OJS 2.x, modern OJS 3.3, 3.4, and 3.5 run significantly faster under Nginx coupled with PHP-FPM. Nginx handles static asset delivery (CSS, JS, journal banners, author headshots) with minimal memory overhead while passing dynamic editorial requests to PHP-FPM Unix sockets.

For institutions requiring .htaccess flexibility or Apache-specific modules, Apache with mpm_event and php-fpm (via mod_proxy_fcgi) is strongly recommended over the outdated and memory-hungry mpm_prefork.

OJS relies heavily on relational integrity across tables like submissions, publication_settings, author_settings, and review_assignments. Using MariaDB 10.6+ or MySQL 8.0 with InnoDB is mandatory. The database must be configured with utf8mb4 character set and utf8mb4_unicode_ci collation to handle multilingual academic manuscripts containing complex mathematical symbols, Greek letters, and non-Latin character sets.

Key MySQL configuration parameters in my.cnf must include setting innodb_buffer_pool_size to 60-70% of available memory on dedicated database nodes, enabling innodb_file_per_table, and setting max_connections to handle traffic spikes during submission deadlines.

One of the most frequent security blunders in OJS deployment is setting the files_dir inside the public web directory. When files are stored inside public_html, malicious actors can execute path traversal attacks or directly download confidential pre-publication drafts.

The files repository must be created in a dedicated path such as /var/ojs_files/ with permissions set to 750 owned by the web server user (www-data or nginx). Web server configuration blocks must strictly prohibit direct HTTP access to this location.

Academic integrity hinges on data permanence. A comprehensive OJS backup strategy must perform daily dumps of the MySQL/MariaDB database, rsync replication of the outside-webroot files directory, and versioned backups of config.inc.php and custom plugins. Backups must be encrypted and pushed to offsite cloud storage (such as AWS S3 or Backblaze B2) with a 30-day retention window.