# OpenProject Community Edition: ClickUp replacement deep dive

_Current as of 24 September 2026. This assessment evaluates the self-hosted **OpenProject Community Edition** against the stated small-team replacement requirements. Primary sources are OpenProject documentation, pricing, installation guides, and its canonical repository. **Verified** means the cited current first-party material explicitly supports the claim; **not verified** means the sources reviewed do not establish it, rather than proving it absent._

---

## Decision summary

**Verdict: Top pilot.** OpenProject Community Edition is a particularly strong match for a team that prioritizes self-hosting, an actual open-source license, data control, and no recurring per-user charge. It verifies all core delivery needs: multi-user task/issue tracking, project and task hierarchy, configurable table/list-like views, status-driven Kanban, calendar, Gantt/timeline, release-oriented roadmap, a GFM-based wiki with Markdown export, role-based access, activity history, full-text search, APIs/webhooks, and at least GitHub and Nextcloud integrations.[1] [2] [3]

The qualification is practical rather than licensing-related. This is a server application, not a zero-operations service: the team must own TLS/reverse-proxy configuration, upgrades, PostgreSQL and attachment backups, monitoring, and security patch cadence. The feature set is also more project/work-package centric than ClickUp’s free-form workspace model. In particular, its “list” is a saved work-package query rather than a separately documented ClickUp-style List container, the real-time Documents module has no version history, and external URL/embed behavior and Docs-level Markdown import/export are not established by the official sources. These are pilot acceptance tests, not reasons to dismiss the product.

| Decision factor | Finding for Community Edition | Decision relevance |
|---|---|---|
| **License and cost** | GPLv3; self-hosted Community is free, with unlimited users and projects | Directly meets the core constraint |
| **Task delivery** | Work packages, parent/child hierarchy, relations, table, boards/Kanban, calendar, Gantt, roadmap | Covers the requested planning surface |
| **Knowledge work** | Project wiki uses GFM; rich CKEditor; Markdown export; page history/diffs; internal embeds | Strong wiki fit; Documents has important caveats |
| **Collaboration and control** | Project-scoped roles/permissions, comments/history, search, API/webhooks, 2FA | Suitable for a reasonably administered small team |
| **Operations** | Docker Compose is recommended for smaller instances; backups, logging, health checks documented | A manageable but real administrator responsibility |
| **Paid dependency** | None for the minimum set identified here | Avoid paid Enterprise paths unless the gated extras matter |

> **Bottom line:** Pilot the current Community release in Docker Compose before migrating production data. It is not merely a free trial or a feature-limited SaaS tier; it is an unlimited-user, self-managed GPLv3 edition. Do not treat the Enterprise trial as evidence of the free feature set.[1] [3] [4]

## Licensing, editions, and cost discipline

### Community Edition is a genuine self-hosted FOSS route

OpenProject’s canonical source repository is licensed under the **GNU General Public License version 3 (GPLv3)**. The vendor describes Community Edition as free, on-premises software with unlimited users and projects, while the official FAQ states that Community Edition is completely free and requires a Linux server for installation.[1] [2] [5] This is materially aligned with “true open-source licensing”: source is public and GPLv3 grants the usual run, study, modify, copy, and redistribute freedoms, subject to GPLv3 obligations when distributing modified works. This report is not legal advice; teams distributing a modified deployment should review the license with counsel.[2] [5]

The free option is **self-managed Community Edition**, not a continuing free OpenProject-hosted plan. OpenProject advertises a 14-day Enterprise Cloud trial and a 14-day self-hosted Enterprise trial token; neither should be budgeted as an enduring zero-cost service.[3] The official FAQ currently lists paid Enterprise Cloud and Enterprise on-premises starting at €5.95 per member/month (or $7.25), with 5-user and 25-user minimums respectively. Community has no minimum-user requirement.[3] [5]

| Edition / route | Hosting and price | Seats/projects | What it means here |
|---|---|---|---|
| **Community Edition** | Self-hosted; free | Unlimited users and projects | The evaluated production route |
| Enterprise on-premises | Self-hosted; paid subscription | 25-user minimum at entry price | Adds licensed add-ons, support, services |
| Enterprise Cloud | Vendor hosted; paid subscription | 5-user minimum at entry price | Does not satisfy the self-hosting preference |
| Enterprise trial | 14 days, cloud or self-hosted upgrade | Temporary | Evaluation only; returns to Community without a subscription for the on-premises trial |

**Limits and hidden-cost finding.** The official material documents no Community per-user, project, or software storage quota.[1] [5] Capacity is therefore constrained by the team’s own CPU, RAM, disk, PostgreSQL, attachment store, email service, and backup target rather than a vendor quota. This is a cost advantage, but it shifts hosting, storage, network, and administrative costs to the team. A 256 MB per-file maximum appears in the Documents guide specifically for Enterprise Cloud; it must **not** be assumed to be a Community self-hosted limit.[18]

### Paid gates that matter—and those that do not

The current Enterprise guide is the clearest source for post-16.0 paid gates. It says Enterprise includes all Community features plus add-ons; the plan structure applies to new customers after the May 2025 changes, while older contracts may retain different entitlements.[4] The requested baseline does **not** require an Enterprise plan: current pricing and feature documentation verify Community access to Gantt/timelines, basic and status/Kanban boards, calendar, wiki, documents/live collaboration, search, permissions, API, GitHub, GitLab, Nextcloud, LDAP authentication, and 2FA.[3] [4]

| Paid gate | Current plan | Impact on this replacement decision |
|---|---|---|
| Gantt-chart PDF export; team planner; custom branding; date alerts; configurable work-package forms; full baseline comparisons | Basic | **Not a baseline blocker.** Community still has interactive Gantt, calendar, browser printing, and baseline-to-yesterday capability |
| OIDC/SAML SSO; OneDrive/SharePoint; internal comments; external work-package sharing; MCP server | Professional | A blocker only if the team mandates corporate SSO, internal-only comment visibility, or those storage integrations |
| Portfolio management; resource management; LDAP group synchronization; shared project lists | Premium | Not needed for a small team’s core task/wiki replacement, but relevant to future scale |
| XWiki integration; SCIM; antivirus scanning; Nextcloud Hub/OIDC storage SSO | Corporate | Community’s built-in wiki and standard Nextcloud integration remain available; these advanced enterprise connections do not |

The distinguishing caveats are specific. **Standard LDAP authentication** is Community, but LDAP group synchronization is paid. OIDC and SAML single sign-on are paid, whereas internal accounts, LDAP, and Kerberos are Community routes.[4] [28] **Nextcloud file management** is Community through two-way OAuth; the smoother common-IdP OIDC SSO arrangement is Corporate-only.[23] **Internal comments** are Professional-only; normal work-package comments and history are Community.[20]

## Deployment feasibility and operating model

### Recommended production pattern for a small team

OpenProject supports Docker Compose, a single all-in-one Docker container, DEB/RPM packages, and Helm/Kubernetes. Its documentation recommends **Docker Compose for smaller instances** and Helm for larger ones.[6] For a small team, the pragmatic Community pattern is a pinned Compose deployment behind a TLS-terminating reverse proxy, with persistent PostgreSQL and attachment storage, SMTP, off-host backups, and basic health-check monitoring.

The vendor’s current server baseline for up to 200 total users is 4 CPU cores, 4 GB RAM, and 20 GB free disk, but it stresses that concurrency, attachments, and exports materially change demand. PostgreSQL 16 or newer is officially supported; PostgreSQL 13–15 are not officially supported despite possibly functioning. Container images exist for AMD64 and ARM64, while packages are AMD64 only.[7]

| Deployment choice | Verified status | Recommendation and caveat |
|---|---|---|
| Docker Compose | Officially recommended for smaller instances | **Recommended pilot and likely production path.** Use durable volumes/bind mounts, TLS, a non-default secret, and a pinned release process |
| Helm/Kubernetes | Official Helm chart | Appropriate only when the team already operates Kubernetes or needs scale/HA; needs persistent volumes or S3-compatible attachments |
| Single all-in-one container | Official quick-start option | Fine for initial evaluation; OpenProject advises against it for production because it impedes component upgradability |
| DEB/RPM packages | Supported only on listed older distributions | Avoid for a new Ubuntu 24.04 deployment: OpenProject says it will not build packages for new Linux versions, and future capabilities are Docker-based |
| Windows host | Not officially supported | Hard deployment blocker if the team cannot supply a Linux host or a supported container platform |

The Compose guide starts with a `stable/17` repository branch, a unique `SECRET_KEY_BASE`, and persistent assets. It warns that disabling HTTPS is only for initial local startup, recommends TLS termination at a reverse proxy for production, and notes that the default port is publicly bound unless changed. The collaboration server is enabled by default; its `COLLABORATIVE_SERVER_SECRET` must be changed.[8] This is meaningful for the requested Docs experience because real-time Documents collaboration is automatic in containerized installs, while packaged installs need extra setup.[18]

### Dependencies and operational workload

OpenProject comprises a Ruby/Puma web application, PostgreSQL, background workers, cache-related services, SMTP for notifications, persistent attachment storage, and—when using real-time Documents—its collaboration server. In clustered use, instances need shared database, cache, and attachment storage; Kubernetes filesystem attachments need ReadWriteMany storage unless S3-compatible object storage is configured.[7] [8] This is comfortably within a competent small team’s reach, but it is more involved than installing a single static application.

Operations must include scheduled backups, tested restores, maintenance windows, image/package upgrades, and security subscription. OpenProject says to back up the database, configuration, uploaded attachments, and any Git/SVN repositories; package installs offer `openproject run backup`, while Compose users must manage Docker volumes and database dumps. Restore documentation covers the database, attachments, migrations, and permissions for both package and Compose installs.[26] [31] Before each upgrade, take and verify an off-host backup; current major-version migration guidance can be stepwise, so do not leap over multiple major releases without following the documented process.[31]

The monitoring surface is adequate but not a substitute for infrastructure observability. OpenProject emits parseable logs, exposes Prometheus metrics when enabled, and publishes health checks for web, database, mail, Puma, workers, and worker backlog. It explicitly leaves OS, network, host, file-integrity, and infrastructure audit events to the operator/platform.[27]

## Work management and planning fit

### Tasks, issues, hierarchy, and views

OpenProject calls its task/issue objects **work packages**. They can represent tasks, features, risks, user stories, bugs, change requests, phases, or milestones; types are configurable and work packages carry ID, subject, status, assignee, priority, dates, and other attributes.[9] This is a credible ClickUp task/issue replacement rather than a simple checklist system.

There are two verified hierarchy layers. Projects can have parent projects and subprojects. Work packages can have parent/child relationships and deeper descendants, and can also have semantic, blocking, predecessor/successor, includes, duplicates, and requires relations. The table can display hierarchy and parent information; as of 17.8, relation columns in the work-package table are available in Community.[10] [32]

| Requested surface | Community finding | Important interpretation |
|---|---|---|
| Multi-user tasks/issues | **Verified** | Configurable work packages cover task, bug, feature, milestone, phase, etc.; assignees and project roles apply |
| Hierarchy | **Verified** | Parent/subproject plus parent/child work packages and descendant filtering |
| List/table | **Verified, with terminology caveat** | A work-package “view” is a filtered list; its Table view supports columns, filters, grouping, saved public/private views, and hierarchy. A distinct ClickUp-style List container is **not verified** |
| Kanban | **Verified** | Status action board moves a card and updates work-package status; basic boards and other action-board types exist |
| Calendar | **Verified** | Week/month, filters, public/private saved calendars, direct task creation and drag-rescheduling; iCalendar subscription is available |
| Gantt/timeline | **Verified** | Interactive project and multi-project Gantt with dates, drag/drop, hierarchy, dependencies, saved views |
| Roadmap | **Verified, narrower model** | Release/version-oriented overview of assigned work packages and completion, not a free-form strategy timeline |

Boards are not cosmetic cards detached from delivery data: board cards are work packages. A status/Kanban board automatically updates a card’s status when moved; basic boards deliberately do not alter work-package attributes. The documentation also describes assignee, version, subproject, and parent-child action boards.[11] The pilot should confirm that the team is comfortable configuring statuses and work-package types before treating Kanban as its primary daily view.

The Gantt module covers the team’s preferred timeline/roadmap requirement more strongly than a visual-only roadmap: it supports dates, drag/drop duration changes, predecessor/follower relationships, hierarchy, filters, saved views, and multi-project timelines.[13] Gantt **PDF** export is Basic-only, but Community can print via the browser and export work-package data; the interactive planning capability itself is not gated.[13] The separate Roadmap is a version/release planning page that groups assigned work packages and shows progress; it should be evaluated as a release roadmap, not assumed to replace a portfolio-roadmapping product.[14]

## Wiki, documents, Markdown, and collaboration fit

### The wiki is the Markdown-native knowledge base

OpenProject’s project Wiki is a built-in collaborative documentation module based on GitHub-flavored CommonMark (GFM). It must be enabled globally and per project, which is a useful governance control. Wiki pages use the CKEditor 5-based rich editor with formatting, images, tables, links, macros, and project/wiki navigation elements.[15] [16]

The Markdown interoperability claim is strong but must be scoped precisely. The underlying format is GFM with additional HTML for features such as mentions and image sizing. Wiki pages can be exported as Markdown; the official FAQ describes copying a wiki/page by exporting to Markdown (or Atom) and pasting it into Markdown mode in another project. The same FAQ says pictures do **not** copy in that workflow and need to be manually added.[15] [17] This provides meaningful Markdown portability, but it is not an evidence-backed promise of lossless round-tripping for all rich widgets/macros or a bulk-repository sync workflow.

| Knowledge requirement | Community evidence | Boundary to test |
|---|---|---|
| Collaborative wiki/Docs | **Verified** | Wiki is collaborative documentation; Documents allow concurrent real-time editing in container installs |
| Markdown interoperability | **Verified for Wiki** | GFM underlying format and Markdown export; image copying is manual in the documented copy workflow |
| Rich editing | **Verified** | CKEditor supports headings, inline code, quotes, lists, images, links and tables |
| Tables | **Verified** | GFM tables with header rows; tables without headers output HTML |
| Embeds | **Verified for internal OpenProject content** | Wiki macros can include wiki pages and dynamically embed filtered work-package tables and Gantt views; arbitrary third-party URL embeds are **not verified** |
| Comments/history | **Verified, split by surface** | Wiki has page history, difference comparison and change comments; work packages have comment/change activity. Documents explicitly have no versioning |
| Docs Markdown import/export | **Not verified** | Do not assume the real-time Documents module is a Markdown-native source format |

Wiki history is a material advantage: a user can see author, timestamp, change comment, and compare two page versions. Pages can be watched, locked, arranged into parent/child navigation, and exported as Markdown.[16] The rich-text editor also provides dynamic internal embeds: included wiki pages and permission-aware, embedded work-package tables/Gantt views. It does **not** verify arbitrary external embeds, so test the actual URLs/media the team relies on.[15]

### Documents add real-time coediting, with a history trade-off

Since 17.0, the Documents module offers direct authored documents or attachments; in containerized and cloud installs, real-time collaboration is automatically available. Multiple members can edit simultaneously, view who is active, add headings, blocks, media elements and linked work packages with a slash menu. Documents can be linked to work packages and carry attachments.[18]

The key limitation is documented plainly: **Documents have no versioning; edits are visible to permitted project members.**[18] The team should therefore use the GFM Wiki for durable, reviewable policies and specifications, and use real-time Documents where fast coediting matters more than revision history. The source does not establish document comments, Markdown import/export, a full export format, or arbitrary external embeds. Treat those as unanswered pilot tests rather than procurement promises.

## Collaboration, permissions, search, integrations, and mobile

### Collaboration and reasonable permissions

OpenProject has configurable roles at three practical scopes: full administrators, delegable global roles, and project roles. Roles bundle permissions, can differ per project, and operate alongside configurable non-member/anonymous permissions for public projects.[19] This satisfies the request for reasonable permissions for an internal small team. It also means the administrator must deliberately set roles and module permissions during setup; a module can remain invisible even when a user has a relevant permission if it is disabled in the project.[19]

Work-package Activity retains changes and regular conversations in a sortable timeline. Users can write formatted comments, quote or edit their own comments, @mention project members, react with emoji, and receive near-real-time updates when a work package changes. The project activity feed can include work packages, wiki edits, documents, meetings, time, and other module updates; its retrospective is not limited, although pagination/display settings affect day-to-day browsing.[20]

### Search

Search is a real strength for a self-hosted tool. The global bar and advanced search cover work packages, documents, projects, and other categories the user can access; partial-text and multi-term search are supported. The official documentation states that full-text search includes wiki pages, work-package descriptions, attachment filenames, and attachment content, while archived-project content is not searchable until unarchived.[21] Attachment-content extraction is a deployment dependency: package documentation says some distributions need `catdoc`, `unrtf`, `poppler-utils`, and `tesseract-ocr` installed manually.[33]

### Integrations and automation

The baseline has a modern API and webhook path. APIv3 is a documented HATEOAS REST API with an OpenAPI 3.1 specification available locally; it supports API tokens, OAuth 2.0, permission-contextual actions, and interactive API docs. Webhooks can cover create/update events for projects, work packages, work-package comments, time entries, and attachments, and can use a signature secret.[24] [35]

GitHub integration is documented without an Enterprise gate and is marked Community in the official plan comparison. It links pull requests to work packages, displays PR/action status, and records PR activity; setup requires an OpenProject API token and a GitHub webhook. OpenProject explicitly recommends a webhook secret, because unsigned webhook requests could be forged.[3] [22] Nextcloud integration is also Community: it links folders/files to work packages, lets users browse linked items, and shows linked work packages from the file side. Two-way OAuth works with all deployments; only shared-IdP OIDC SSO is Enterprise Corporate.[23]

| Integration need | Community status | Caveat |
|---|---|---|
| APIv3 / API tokens / OAuth server | **Verified** | Scope API tokens and CORS carefully; actions remain permission-bound |
| Outbound webhooks | **Verified** | Protect receiving endpoints; configure a signature secret |
| GitHub PR linkage | **Verified** | Limited documented incoming event set; configure token and webhook secret |
| Nextcloud file management | **Verified** | Standard OAuth entails consent flows; OIDC storage SSO is paid |
| OneDrive / SharePoint | **Paid** | Professional or above |
| GitLab | **Community in pricing** | Validate the specific desired GitLab workflow during pilot; it was not feature-tested in this desk research |
| XWiki | **Paid** | Corporate-only; not required because the built-in wiki is Community |

The Mobile app is a **Beta** companion available for iOS and Android. Its current documented scope includes work packages, notifications, time tracking, meetings, search, projects/spaces and settings; wiki and Documents are specifically named as future focus areas. It is not a complete web replacement, offline operation is forthcoming, and the documentation does not explicitly state Community-edition compatibility. Test connection to the self-hosted pilot instance before treating mobile as a committed requirement.[25]

## Migration, portability, security, and maturity

### Migration and data portability

No first-party ClickUp importer was identified in the primary sources reviewed. This is not proof one cannot be built; it means the team should not plan on a vendor-supported one-click ClickUp migration. The viable verified primitives are: work-package export to CSV/XLS/PDF (plus single-work-package Atom), Wiki Markdown export, a documented APIv3, and full self-hosted backups/restores of the database, configuration, attachments, and repositories.[17] [24] [26] [30]

There are meaningful export caveats. CSV export follows the current table view but flattens hierarchy, and descriptions can be raw HTML. Wiki Markdown export requires manual image handling in the documented copy workflow.[17] [34] A migration should therefore map ClickUp Spaces/Folders/Lists to projects/subprojects and saved work-package queries, convert tasks to work packages, reconstruct parent/child relations and dependencies through API/import tooling, preserve original IDs/URLs in custom fields or descriptions, and attach files separately. This mapping is a recommendation, not an official importer claim.

**Practical migration gate:** do a reversible sample migration of one representative ClickUp space. Validate hierarchy, custom fields, statuses, assignees, comments, attachments, rich descriptions, wiki images, links, permission mapping, and report/calendar/Gantt views before committing. Keep ClickUp read-only until exports, backups, and restore testing pass.

### Security and resilience

Community has useful core security controls: project-scoped RBAC, salted-bcrypt internal passwords, configurable password/session policy, LDAP/Kerberos options, and enforceable 2FA using TOTP or WebAuthn. OpenProject publishes security advisories and a security mailing list; its policy says generally only the latest major release is supported, with defined efforts for serious security fixes.[19] [28] [29]

The limits of self-hosting must be stated plainly. OpenProject’s cloud encryption-at-rest claims do **not** automatically apply to Community; the Community operator must arrange disk/database/object-storage encryption, TLS, firewalling, secret management, backup encryption and retention, OS/container patching, and infrastructure audit logs. OpenProject itself documents that host/network/file-integrity logging is outside its application-log scope.[27] [29] Use TLS termination, do not expose Compose’s default public port without an ingress design, replace default and collaboration secrets, restrict database access, and test restoration.

### Maturity and governance

This is a mature, actively developed project rather than a new community fork. The canonical `opf/openproject` repository was created in 2012, uses GPL-3.0, has a public issue/PR/contribution workflow, and its public repository snapshot showed over 16,000 stars and 3,500 forks on the research date.[2] The latest official release at review was 17.8.0, published 2 September 2026; the release added Community relation columns in work-package tables and maintained a current stable release track.[32] The project also has public documentation, a community forum, public roadmap, security disclosure process, and vendor stewardship by OpenProject GmbH.[1] [2] [29]

This governance model lowers abandonment risk but does not eliminate dependence on the vendor-led roadmap. The Community edition receives core development, while some advanced features are deliberately paid add-ons; teams should judge what is verified in their intended Community release, not extrapolate from Enterprise screenshots or trials.

## Hard blockers, gaps, and pilot acceptance tests

### Hard blockers only if these are non-negotiable

1. **No Linux/container-capable hosting and no willingness to operate it.** Community requires self-hosting; Windows is not officially supported, and the team owns availability and security operations.[5] [7]
2. **Mandatory OIDC/SAML SSO, SCIM, OneDrive/SharePoint, portfolio/resource management, or internal-only comments without a paid subscription.** These are current Enterprise gates.[4] [28]
3. **A required ClickUp-style, free-form workspace hierarchy or a supported one-click ClickUp importer.** The verified model is projects/subprojects plus work packages/relations/saved query views, not ClickUp’s exact container vocabulary; no primary-source ClickUp importer was found.
4. **Document-level version history and Markdown portability for real-time Documents.** The Docs module says it has no versioning, and the required Markdown export/import behavior is not verified. Use Wiki instead, or accept the split workflow.[18]

### Pilot plan and pass criteria

Run the pilot against the current stable Community Docker Compose release, not an Enterprise trial. A two-week pilot should use real work and real external services:

1. Deploy behind TLS with a non-default `SECRET_KEY_BASE` and collaboration secret. Configure SMTP, 2FA, role templates, off-host encrypted backup, and `/health_checks` monitoring.[8] [27]
2. Create a project/subproject structure and a representative task hierarchy. Verify status workflow, saved work-package table/query, Kanban, calendar/iCalendar, Gantt dependencies, release roadmap, search, and role boundaries.
3. Import a small ClickUp export through the selected mapping/API process. Reconcile counts, parents, dates, assignees, custom fields, comments, attachments, and links.
4. Create an operational Wiki sample with tables, images, included pages, embedded work-package table/Gantt, history comparison, and Markdown export/re-import. Separately create a simultaneous-edit Documents sample and explicitly accept its no-versioning behavior.
5. Connect GitHub and, if relevant, Nextcloud. Confirm webhook signatures, PR linkage, expected permission boundaries, and attachment behavior.
6. Restore the pilot into an isolated instance from the actual backup procedure. The pilot passes only when work packages, attachments, wiki content, and permissions survive and the team accepts the administrative runbook.

## Final fit verdict

**Top pilot.** OpenProject Community Edition is one of the clearest matches for the stated decision criteria because its zero-per-user-fee, unlimited-user self-hosted path is itself GPLv3 open source—not a time-limited SaaS free tier—and its verified Community capabilities cover the core task, hierarchy, Kanban, table/list-like, calendar, Gantt, roadmap, wiki, collaboration, search, and automation requirements.[1] [2] [3]

Approval should be conditional only at the implementation level: confirm the team can operate Docker/PostgreSQL/TLS/backups; accept a work-package/project model instead of ClickUp’s exact hierarchy; and establish the desired Wiki-versus-real-time-Documents workflow. If those pass, there is no material paid gate in the stated minimum needs. If document revision history, arbitrary external embeds, or corporate SSO are mandatory, retain OpenProject as a strong reference but budget Enterprise or a complementary knowledge/identity component.

## References

[1]: https://www.openproject.org/community-edition/ "OpenProject Community Edition"
[2]: https://github.com/opf/openproject "opf/openproject canonical repository"
[3]: https://www.openproject.org/pricing/ "OpenProject pricing and feature comparison"
[4]: https://www.openproject.org/docs/enterprise-guide/ "OpenProject Enterprise guide and add-on overview"
[5]: https://www.openproject.org/docs/faq/ "OpenProject FAQ: pricing, licensing, users, and projects"
[6]: https://www.openproject.org/docs/installation-and-operations/installation/ "Installing OpenProject"
[7]: https://www.openproject.org/docs/installation-and-operations/system-requirements/ "OpenProject system requirements"
[8]: https://www.openproject.org/docs/installation-and-operations/installation/docker-compose/ "OpenProject Docker Compose installation"
[9]: https://www.openproject.org/docs/user-guide/work-packages/ "OpenProject work packages"
[10]: https://www.openproject.org/docs/user-guide/work-packages/work-package-relations-hierarchies/ "OpenProject work package relations and hierarchies"
[11]: https://www.openproject.org/docs/user-guide/agile-boards/ "OpenProject agile boards"
[12]: https://www.openproject.org/docs/user-guide/calendar/ "OpenProject Calendar"
[13]: https://www.openproject.org/docs/user-guide/gantt-chart/ "OpenProject Gantt charts"
[14]: https://www.openproject.org/docs/user-guide/roadmap/ "OpenProject product roadmap release planning"
[15]: https://www.openproject.org/docs/user-guide/wiki/ "OpenProject Wiki"
[16]: https://www.openproject.org/docs/user-guide/wiki/create-edit-wiki/ "Create and edit a wiki page in OpenProject"
[17]: https://www.openproject.org/docs/user-guide/wiki/wiki-faq/ "OpenProject Wiki FAQ"
[18]: https://www.openproject.org/docs/user-guide/documents/ "OpenProject Documents"
[19]: https://www.openproject.org/docs/system-admin-guide/users-permissions/roles-permissions/ "OpenProject roles and permissions"
[20]: https://www.openproject.org/docs/user-guide/activity/ "OpenProject project and work package activity"
[21]: https://www.openproject.org/docs/user-guide/search/ "OpenProject search features"
[22]: https://www.openproject.org/docs/system-admin-guide/integrations/github-integration/ "OpenProject GitHub integration"
[23]: https://www.openproject.org/docs/system-admin-guide/integrations/nextcloud/ "OpenProject Nextcloud integration setup"
[24]: https://www.openproject.org/docs/api/introduction/ "OpenProject APIv3 introduction"
[25]: https://www.openproject.org/docs/mobile-app-guide/ "OpenProject Mobile app guide (Beta)"
[26]: https://www.openproject.org/docs/installation-and-operations/operation/backing-up/ "Backing up your OpenProject installation"
[27]: https://www.openproject.org/docs/installation-and-operations/operation/monitoring/ "Monitoring your OpenProject installation"
[28]: https://www.openproject.org/docs/system-admin-guide/authentication/ "OpenProject authentication"
[29]: https://www.openproject.org/docs/security-and-privacy/statement-on-security/ "OpenProject statement on security"
[30]: https://www.openproject.org/docs/user-guide/work-packages/exporting/ "Export work packages"
[31]: https://www.openproject.org/docs/installation-and-operations/operation/restoring/ "Restoring an OpenProject backup"
[32]: https://www.openproject.org/docs/release-notes/17-8-0/ "OpenProject 17.8.0 release notes"
[33]: https://www.openproject.org/docs/installation-and-operations/installation/packaged/ "Install OpenProject with DEB/RPM packages"
[34]: https://www.openproject.org/docs/user-guide/work-packages/exporting/csv/ "OpenProject CSV export"
[35]: https://www.openproject.org/docs/system-admin-guide/api-and-webhooks/ "OpenProject API and webhooks"