Open Source

The OpenProject Foundation strives to make
OpenProject a place to participate and collaborate
with open source and open mind.

OpenProject 6.0.x to OpenProject 6.1 Debian/Ubuntu Upgrade Guide

Please look at the steps in the section about the upgrade to OpenProject 6.0. OpenProject 6.x is being released under the branch stable/6.

When running with MySQL: Required changes in sql_mode

If you're upgrading to OpenProject 6.1.x with a MySQL installation, you will need to update your database.yml to reflect some necessary changes to MySQL sql_mode made as part of the migration to Rails 5. Please see the config/database.yml.example file for more information.

OpenProject 5.0.x to OpenProject 6.0 Debian/Ubuntu Upgrade Guide

Upgrading your OpenProject 5.0.x installation to 6.0 is very easy. Please upgrade your OpenProject installation first to the latest stable 6.0 path. If you checked out the OpenProject installation through Git, you can use the stable/6 branch which points to the latest stable release.

[openproject@debian]# cd /home/openproject/openproject
[openproject@debian]# git fetch && git checkout stable/6

After upgrading the installation files, you need to migrate the installation to OpenProject 6.0 with the following steps:

[openproject@debian]# cd /home/openproject/openproject
[openproject@debian]# npm install
[openproject@debian]# RAILS_ENV="production" bundle exec rake db:migrate
[openproject@debian]# RAILS_ENV="production" bundle exec rake db:seed
[openproject@debian]# RAILS_ENV="production" bundle exec rake assets:precompile
[openproject@debian]# touch tmp/restart.txt

After performing these steps, the server should be running OpenProject 6.0.x.

OpenProject 4.2 to OpenProject 5.0 Debian/Ubuntu Upgrade Guide

One of the main new features of OpenProject 5.0 is that it provides management of repositories directly within the user interface (with so-called managed repositories).

Starting with OpenProject 5.0, you can explicitly select the SCM vendor you want to associate to your project, and let OpenProject generate the repository on the filesystem on the fly.

If you haven't configured serving repositories through Apache before, you'll find the repository integration guide to guide you through the necessary steps to configure this integration.

For the other steps necessary to upgrade to OpenProject 5.0 please look at the sections below and exchange v4.1.0 with v5.0.0.

Changed Rails Path

OpenProject 5.0 employs Rails 4.2.x, which contains a number of changes regarding paths. Foremost, files previously located in the scripts directory now reside in bin (e.g., delayed_job).

Secret Token

With an update to Rails 4.1+, you now must generate a secret key base for the production environment with ./bin/rake secret and make that available through the environment variable SECRET_KEY_BASE.

You will likely set the environment variable in /etc/environment or use your server's environment mechanism (i.e., SetEnv in Apache).

Upgrading to Managed Repositories

You can create repositories explicitly on the filesystem using managed repositories. Enable managed repositories for each SCM vendor individually using the templates defined in configuration.yml. For more information, please refer to the repository integration guide.

This functionality was previously provided as a cron job reposman.rb. This script has been integrated into OpenProject. Please remove any existing cronjobs that still use this script.

Convert Repositories Created by Reposman

If you want to convert existing repositories previously created (by reposman.rb or manually) into managed repositories, use the following command:

$ ./bin/rake scm:migrate:managed[URL prefix (, URL prefix, ...)]

the URL prefix denotes a common prefix of repositories whose status should be upgraded to :managed. Example:

If you have executed reposman.rb with the following parameters:

$ reposman.rb [...] --svn-dir "/opt/svn" --url "file:///opt/svn"

Then you can pass the task a URL prefix file:///opt/svn and the rake task will migrate all repositories matching this prefix to :managed. You may pass more than one URL prefix to the task.

Listing Potential Conflicting Identifiers

As managed repositories on the filesystem are uniquely associated using the project identifier, any existing directories in the managed repositories root may cause a conflict in the future when trying to create a repository with the same name.

To help you identify these conflicts, you can run the following rake task, which will list entries in the managed repositories path with no associated project:

$ ./bin/rake scm:find_unassociated

OpenProject 4.1 to OpenProject 4.2 Debian/Ubuntu Upgrade Guide

Please look at the steps in the section about the upgrade to OpenProject 4.1. Just exchange v4.1.0 to v4.2.0 when checking out the git repository.

OpenProject 4.0 to OpenProject 4.1 Debian/Ubuntu Upgrade Guide

This guide describes the upgrade process from OpenProject 4.0 to 4.1 on Debian 7.7 and Ubuntu 14.04 LTS step by step.

Note: We strongly recommend to update your OpenProject installation to the latest available 4.0 version (currently 4.0.9), before attempting an update to 4.1.


  • Backup your current Openproject installation. Typically you should backup the attachment folder of your installation, the subversion repositories (if applicable) and your database. For more information please have a look at our backup guide

  • Before Upgrading, check that all the installed OpenProject plugins support the new OpenProject version. Remove incompatible plugins before attempting an upgrade. Stop the OpenProject Server. You may even add a maintenance page, if you feel comfortable with that.

  • If you run the worker process with a cronjob, disable the cronjob temporarily.

  • Stop the (delayed_job) worker process. In case you run the woker process through RAILS_ENV=production bundle exec script/delayed_job start, execute the following: RAILS_ENV=production bundle exec script/delayed_job stop.

Update your system

[root@debian]# apt-get update
[root@debian]# apt-get upgrade

Get the new OpenProject Source Code

Change into the directory where OpenProject is installed and switch to the operating-system-user the OpenProject operates as. We assume that OpenProject is installed in /home/openproject/openproject by the openproject user.

[root@debian]# su - openproject -c "bash -l"
[openproject@debian]# cd ~/openproject/openproject

Remove manual changes and modifications (If you have modified OpenProject source files and want to preserve those changes, back up your changes, and re-apply them later):

[openproject@debian]# git reset --hard
[openproject@debian]# git fetch
[openproject@debian]# git checkout v4.1.0

Upgrade Ruby

OpenProject 4.1 requires Ruby to be installed in version 2.1.x. Assuming you have installed Ruby via RVM, do the following to upgrade your Ruby installation:

[openproject@debian]# rvm get stable
[openproject@debian]# export -f rvm_debug
[openproject@debian]# rvm install 2.1.5
[openproject@debian]# rvm use --default 2.1.5
[openproject@debian]# gem install bundler
[openproject@debian]# bundle install

Update application server configuration

This sections only applies to you, if you serve OpenProject via Apache and Passenger. If you serve OpenProject in a different way, be sure to check that it still works.

During the upgrade of the Ruby version, we have potentially installed a new Ruby and Passenger version. The versions of Ruby and Passenger appear in the Apache configuration like this:

LoadModule passenger_module /home/openproject/.rvm/gems/ruby-2.1.4/gems/passenger-4.0.53/buildout/apache2/
<IfModule mod_passenger.c>
  PassengerRoot /home/openproject/.rvm/gems/ruby-2.1.4/gems/passenger-4.0.53
  PassengerDefaultRuby /home/openproject/.rvm/gems/ruby-2.1.4/wrappers/ruby

Please run the following commands to upgrade passenger and re-install the Apache module:

[openproject@debian]# gem update passenger
[openproject@debian]# gem cleanup passenger
[openproject@debian]# passenger-install-apache2-module

The output of passenger-install-apache2-module2 tells you how to configure Apache. It is basically the same as what is already installed, except for the updated version numbers.

Don’t forget to restart apache after the configuration change:

[root@debian]# service apache2 reload

Node.js installation

Node.js is necessary to precompile the assets (JavaScript and CSS). We will install the latest 0.12.x version of Node.js via nodeenv:

[openproject@debian]# exit
[root@debian]# apt-get install python python-pip
[root@debian]# pip install nodeenv
[root@debian]# su - openproject -c "bash -l"
[openproject@debian]# cd /home/openproject
[openproject@debian]# nodeenv nodeenv
[openproject@debian]# source ./nodeenv/bin/activate
[openproject@debian]# npm -g install bower

As a reference, the following Node.js and NPM versions have been installed on our system:

[openproject@debian]# node --version
[openproject@debian]# npm --version
[openproject@debian]# bower --version

The Upgrade

Now that the sources and dependencies are in place, you can migrate the Database and do the upgrade.

Before actually migrating the database, please remove all temporary files from the previous installation (caches, sessions) by running the following command.

[openproject@debian]# cd /home/openproject/openproject
[openproject@debian]# RAILS_ENV="production" bundle exec rake tmp:clear

If you do not clear the temporary files, you may encounter an error of the form NoMethodError: undefined method map' for # in the config/initializers/30-patches.rb` files. The actual upgrade commands are as follows:

[openproject@debian]# cd /home/openproject/openproject
[openproject@debian]# npm install
[openproject@debian]# RAILS_ENV="production" bundle exec rake db:migrate
[openproject@debian]# RAILS_ENV="production" bundle exec rake db:seed
[openproject@debian]# RAILS_ENV="production" bundle exec rake assets:precompile
[openproject@debian]# touch tmp/restart.txt

Side note: If you are using RAILS_ENV="development" the task bundle exec rake assets:webpack needs to be run. This step is not necessary for production because it is part of the asset:precompile tasks.

NOTE db:seed can also be invoked with a 'LOCALE' environment variable defined, specifying the language in which to seed. Note however, that specifying different locales for calls to db:seed might lead to a mixture of languages in your data. It is therefore advisable to use the same language for all calls to db:seed.

The Aftermath

  • Re-enable the delayed_job cron job that was disabled in the first step.
  • If you have put up a maintenance page, remove it.
  • Start the OpenProject server again
  • Watch for further OpenProject updates in our news, or on twitter.

Questions, Comments, and Feedback

If you have any further questions, comments, feedback, or an idea to enhance this guide, please tell us at the appropriate forum.

Also, please take a look at the Frequently Asked Questions.


You can find the master document in GitHub. You can propose a change to this guide by creating a pull request on GitHub.