OpenProject's docker-compose.yml is a development harness that refuses to install

The compose file in this repository stops on purpose and names its replacement

Anyone who finds docker-compose.yml first will not get an installation. The file declares a required environment variable whose error message is the whole point:

    LOCAL_DEV_CHECK: "${LOCAL_DEV_CHECK:?The docker-compose file for OpenProject has moved to https://github.com/opf/openproject-docker-compose}"

Set the variable and the compose file runs. Leave it out and the stack stops with a message naming the repository that does handle automated installs. The bundled .env.example sets LOCAL_DEV_CHECK=1 with the comment that it exists to prevent people from using this compose file for automated installs.

So the file you are reading is a development harness, and its contents confirm that. Build arguments carry DEV_UID and DEV_GID, the backend build target is develop, the image is openproject/dev:latest, the Rails cache store is file_store and memcache is reached at cache:11211. Nothing in it is shaped like a production deployment, and the cost of guessing wrong is that you spend an afternoon on a file that was never going to install anything.

The dev stack disables SSRF protection so local integrations work

One line in that development environment is worth reading twice before anything is copied out of it:

    OPENPROJECT_SSRF_PROTECTION_IP_ALLOWLIST: 0.0.0.0/0,::0/0 # disabling SSRF in dev to not interfere with local integrations (Nextcloud etc.)

The allowlist is opened to every address, and the comment says why: local integrations would otherwise be blocked. OpenProject's feature list names Nextcloud, XWiki, GitHub and GitLab as integrations, so outbound requests to other services are part of normal operation rather than an edge case.

The consequence follows directly. If this value reaches a deployment that has integrations enabled, the protection that stops the server being used to fetch internal addresses is off, while the features that needed it in development are still there. That is a setting to verify in your own environment after installing, not a default to inherit, and it is one of several reasons the repository steers installers to the separate compose project.

Configuration is Rails-style environment variables with the defaults written inline

OpenProject's settings are environment variables with a double underscore standing in for a Rails namespace. The compose file sets OPENPROJECT_CACHE__MEMCACHE__SERVER to cache:11211, OPENPROJECT_RAILS__CACHE__STORE to file_store, OPENPROJECT_EDITION to standard as a fallback, and OPENPROJECT_COLLABORATIVE__EDITING__HOCUSPOCUS__URL for collaborative editing. Database access runs through DATABASE_URL, a PostgreSQL URL built from DB_USERNAME, DB_PASSWORD, DB_HOST, DB_PORT and DB_DATABASE with a pool of 100.

The .env.example shows the same pattern for a local machine, and its first lines are worth reading twice:

LOCAL_DEV_CHECK=1
CKEDITOR_BUILD_DIR=./frontend/src/vendor/ckeditor/
HOST=localhost
PORT=3000
FE_HOST=localhost
FE_PORT=4200

Two development servers, on two ports, with the frontend on 4200 and the backend on 3000. A reader expecting one port for the application will end up at the wrong one.

The comment above them says a .env file in the root directory overrides some default settings that overmind will use to start OpenProject.

The root package.json reads 0.1.0, and that is not what you deploy

The Node manifest at the repository root looks like a published package and is not one:

  "name": "openproject",
  "version": "0.1.0",
  "private": true,
  "engines": {
    "node": "^24.22.1",
    "npm": "^11.12.0"
  },
  "scripts": {
    "postinstall": "npm -C frontend install",
    "serve:public": "npm -C frontend exec -- ng serve --host 0.0.0.0"
  },

That version field is 0.1.0 while the releases are numbered 17.9.x, so pinning by the npm-style version gives you nothing. Pin a release tag. The private flag means the manifest was never meant for a registry, and the postinstall hook is there to install the frontend's own dependencies.

The serve:public script is the other detail. It binds the Angular dev server to 0.0.0.0 rather than to loopback, which is convenient for containers and wrong for a laptop on shared wifi. Contributors also need a second toolchain: the repository carries .ruby-version, Gemfile, Gemfile.lock, Gemfile.modules, Rakefile, Procfile and config.ru beside the Node files.

A fork of ChiliProject, which is a fork of Redmine, and the copyright says so

The header comment at the top of .env.example states the lineage before it states anything about configuration: OpenProject is a fork of ChiliProject, which is a fork of Redmine. The notices that follow are Copyright (C) 2006-2013 Jean-Philippe Lang and Copyright (C) 2010-2013 the ChiliProject Team.

That matters for anyone extending the system rather than deploying it. The repository keeps COPYRIGHT and COPYRIGHT_short at the root so both origins stay visible.

The practical advice is narrow and concrete: before writing an extension or planning a data migration, read COPYRIGHT rather than assuming one licence applies uniformly to every file, because the project is carrying two upstream notices and does not flatten them into one.

The Community Edition is the repository; the Enterprise add-ons are not

Three purchasing paths are set out in the README and they are not the same product. A free 14-day trial runs on the hosted service. The Community Edition is free of charge, downloaded and self-hosted, with installation guides linked from the download and installation pages. The Enterprise Edition is a paid sign-up that comes in cloud or on-premises form and adds comprehensive support plus Enterprise add-ons.

What that leaves unanswered is the interesting part for an evaluator. The README does not enumerate the Enterprise add-ons, so a team comparing tiers cannot tell from it which dashboards, reporting or planning features live in the GPL tree and which are sold. OpenProject presents itself as an alternative to Jira, MS Project, Monday, Asana and YouTrack for organisations that want control over their own data, and the distinction between the tiers is exactly where that promise gets priced.

One more signal sits in the repository rather than the README: a crowdin.yml at the root means interface translations run through Crowdin.

Three releases in two days, on a branch called dev

The release record is dense. OpenProject 17.9.4 was published on 2026-10-26, and 17.9.5 and 17.9.6 both followed on 2026-10-30. The last push to the repository was on 2026-11-02, and the default branch is dev rather than a release branch.

A cadence that tight is good news for security response and awkward for a self-hosted instance. CHANGELOG.md at the root is where the deltas are recorded, since the README does not summarise what changed, and an instance pinned a few months ago is several patches behind with the upgrade work on your side. Decide in advance which branch you track: dev for evaluation, a release tag for production.

The disclosure process is spelled out. Security issues are to be reported privately so users have time to upgrade, and the README states they take precedence over anything else in the pipeline. SECURITY.md sits at the root and the procedure is at docs/security-and-privacy/statement-on-security/README.md, while ordinary bugs go to the OpenProject Community instance rather than the issue tracker.

Editorial conclusion

OpenProject fits an organisation that has to keep project data inside its own infrastructure and wants issue tracking, Gantt planning, agile boards and time tracking in one place rather than assembling them from separate tools, and the Community Edition is GPL-3.0 and self-hosted for exactly that reason. It does not fit a team that expects a two-click install, because the compose file in this repository refuses to run on purpose and the one meant for installs lives in a separate project, and it does not fit a team assuming the Enterprise add-ons sit in the open tree. Before adopting, install from the download and installation guides rather than from this repository, pin a release tag rather than the dev branch, and confirm in your own deployment that SSRF protection is on, since the development stack sets OPENPROJECT_SSRF_PROTECTION_IP_ALLOWLIST to 0.0.0.0/0,::0/0.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. opf/openproject on GitHub
3. Project website
4. README
5. Releases