# ClickUp alternatives: self-hosted, open-source, SaaS, and build-path research

_A research and decision report for Ryan · 24 September 2026 · Author: Manus AI_

---

## Abstract

ClickUp is not usefully compared to a Kanban board alone. Its differentiator is the connection between configurable work items, hierarchy, multiple task views, rich Docs/wiki, comments, structured metadata, permissions, reporting, and automation. The research therefore evaluated alternatives as **connected work systems**, not as isolated issue trackers or document tools. Official product, pricing, licensing, deployment, and repository sources were prioritized throughout.

The recommended next step is a **12-week OpenProject Community Edition pilot**, not an immediate custom build or source fork. It has the strongest verified no-seat-fee, GPLv3 package of work items, Kanban, table/list-like queries, calendar, Gantt/multi-project timeline, Markdown-based Wiki with history, role permissions, API/webhooks, and documented operations. It is not a literal ClickUp UI replacement, so the pilot must validate real workflows, wiki ergonomics, migration, mobile use, restore, and upgrade behavior. Leantime, Plane Community Edition, and Vikunja plus Docmost are the principal open-source comparators for teams that prioritize respectively an integrated project wiki, a modern task UI, or Markdown-first documentation.[1] [2] [3] [4]

**Keywords:** ClickUp, self-hosting, open source, project management, wiki, knowledge management, work management, OpenProject, Plane, Leantime

---

## 📋 TL;DR

| Decision | Recommendation | Why it leads | Non-negotiable proof before selection |
|---|---|---|---|
| **First pilot** | OpenProject Community Edition | GPLv3, unlimited Community users/projects, work packages, agile boards, calendar, Gantt, roadmap/timeline, Wiki history, roles, API | Real migration, Wiki usability, restore, upgrade, and role tests |
| **Integrated-wiki comparator** | Leantime | Strong project task views and unusually rich project Wiki in AGPL core | Markdown round-trip, search/history, and paid-plugin boundaries |
| **Modern-UX comparator** | Plane Community Edition | Modern List/Board/Calendar/Table/Timeline work-item surface | Community Pages/Wiki/permission entitlement and operations |
| **Docs-first stack** | Vikunja + Docmost | AGPL tasks/views/Gantt paired with real-time rich Docs and Markdown interchange | Two-system identity, linking, search, backup, and recovery |
| **Small proprietary benchmark** | YouTrack Server Free | Mature tracker, Gantt, Knowledge Base, permissions, and ClickUp importer | Explicit acceptance of proprietary licence and 10-user ceiling |
| **Do not start here** | Fork or greenfield rebuild | Both create a durable engineering and operational product obligation | Demonstrated failure of upstream configuration and API extension |

> **Core finding:** The most attractive “free” option is not necessarily no-cost. Self-hosting substitutes software-seat cost with operator time, backup, patching, security, storage, identity, and upgrade responsibility. Every pilot should include a clean-room restore and an upgrade rehearsal.

---

## 🎯 Scope, working assumptions, and research improvements

This work used a provisional profile: a small, collaborative team that prefers Docker or virtual-machine self-hosting, favours true open-source licensing, wants to avoid recurring per-user fees, and needs a credible combination of issues/tasks, Kanban, roadmaps, rich Docs/wiki, Markdown interoperability, tables, embeds, permissions, search, and multi-user collaboration. Hosted free tiers and GitHub-native paths were retained as exceptions rather than treated as equivalents.

The research improved the original brief in six ways. It separates true open source from source-available and merely self-hostable software; compares product licences with operational cost; distinguishes an integrated workspace from a composed stack; treats data export, backup, role control, and migration as product requirements; identifies feature gates in Community/Free tiers; and uses hands-on pilot gates instead of marketing feature lists.

Questions that would sharpen the final choice remain: expected team size in 12–24 months; acceptable hosting platform; required identity, guests, mobile, and integrations; whether a composed stack is acceptable; whether the outcome is a general work hub, a software-product system, or both; and the appetite for maintaining an upstream fork. The full working scope is recorded in [the research-scope document](research-scope.md).

---

## 📚 ClickUp baseline: what must actually be replaced

ClickUp’s connected-workspace model combines a hierarchy of Workspace, Space, optional Folder/Subfolder, List, and task; task records with metadata, subtasks, comments, relationships, dependencies, and activity; a Docs model that can be linked to work; and multiple views over the same operational work. Its Docs support pages/subpages, comments, rich text, tables, embeds, permissions, history, task creation, and Markdown/PDF/HTML export. Its view catalogue includes List, Board, Calendar, Gantt, Timeline, Workload, Table, Whiteboard, Dashboard, Doc, Embed, Form, and more.[5] [6] [7]

```mermaid
flowchart LR
    accTitle: ClickUp connected work model
    accDescr: ClickUp connects one work hierarchy to task records, reusable views, rich documents, and collaboration or reporting layers. A viable replacement must preserve the connections that matter to the team, not merely copy a board.

    hierarchy[🗂️ Work hierarchy] --> tasks[📋 Configurable tasks]
    tasks --> views[🔍 List Board Calendar Table]
    tasks --> planning[📊 Gantt Timeline Goals]
    tasks --> docs[📚 Docs and wiki]
    docs --> comments[💬 Comments and activity]
    tasks --> comments
    tasks --> reporting[📈 Dashboards and automation]
    docs --> search[🔎 Permission-aware search]
    tasks --> search

    classDef core fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    classDef knowledge fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
    classDef outcome fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d

    class hierarchy,tasks,views,planning core
    class docs,comments knowledge
    class reporting,search outcome
```

### Capability baseline

| Capability to preserve | ClickUp behaviour relevant to this decision | Evaluation implication |
|---|---|---|
| Work graph | Generic tasks model issues, projects, bugs, deliverables, and recurring work; fields, status, assignees, dates, subtasks, dependencies, and comments are connected | An alternative needs structured, queryable work items, not only cards |
| Multiple views | List, Board, Calendar, Table, Gantt, Timeline, and Workload express different workflows over task data | Verify daily views, not a feature-page inventory |
| Knowledge | Docs/wiki include nested pages, collaborative rich editing, tables, embeds, comments, history, links to tasks, and Markdown export | A standalone README or basic wiki is a visible downgrade |
| Permissions | Workspace/location/task/Doc sharing and view/comment/edit/full-edit controls support internal and guest work | Test least privilege separately from membership invitations |
| Reporting and automation | Dashboards, goals, portfolio cues, automations, integrations, and search help turn tasks into an operating system | Treat these as later requirements unless they are already daily habits |

*The ClickUp baseline is documented in detail in [the capabilities report](clickup/clickup-capabilities.md) and [the plan-gating report](clickup/clickup-plans-and-gating.md).*

### Visual documentation of ClickUp’s public product surface

![ClickUp product homepage showing an all-in-one workspace positioning and product interface](assets/clickup-homepage.png)

*Figure 1: ClickUp homepage capture, recorded during this research. The page frames the product as an integrated work environment rather than a single task view.*

![ClickUp product feature index showing the breadth of capability areas](assets/clickup-features.png)

*Figure 2: ClickUp feature-index capture. The long capability catalogue illustrates why a direct feature-count comparison would be misleading without prioritization.*

![ClickUp Docs feature page showing collaborative document positioning](assets/clickup-docs.png)

*Figure 3: ClickUp Docs feature-page capture. The replacement question is about linked, collaborative knowledge work—not just Markdown storage.*

![ClickUp pricing page showing Free Forever, Unlimited, Business, and Enterprise tiers](assets/clickup-pricing.png)

*Figure 4: ClickUp pricing capture. Free seats do not make the operational collaboration experience unrestricted.*

### Why Free Forever alone is not the parity bar

ClickUp Free Forever supports unlimited tasks and members, Collaborative Docs, Kanban, Calendar, and basic task features. It also imposes shared limits that matter to a small working team: 60 MB workspace storage, five Spaces, 60 Custom Field uses, 60 Dashboard uses, one Form, five active Automations with 100 monthly Actions, and guest access that grants full permissions rather than a choice of view/comment/edit levels. Gantt, Timeline, and Workload have use caps; many feature uses do not reset.[8] [9]

The relevant comparison point depends on the existing ClickUp habit. Unlimited is the practical small-team capacity upgrade, while Business unlocks the more durable operational features: unlimited Dashboards and Timeline/Activity use, private views, custom exports, and webhook/integration automation. ClickUp’s pricing and Help Center use somewhat inconsistent Business Plus terminology, so any purchase-dependent conclusion should be checked in the destination Workspace’s billing flow.[9] [10]

---

## 🔬 Research method and evaluation logic

The work began with ClickUp first-party feature, Help Center, and pricing review plus public-site captures. Parallel discovery then surveyed three independent markets: unified self-hosted workspaces, self-hosted developer/composable stacks, and SaaS/GitHub paths. Sixteen finalists received dedicated product validation covering deployment, licence/cost, tasks and views, roadmap, Docs/editor behaviour, permissions, migration, portability, backups, and operating burden. The detailed market discovery and one-product reports remain available in the `landscape/` and `deep-dives/` folders.

The prioritization weights are deliberately qualitative. True open-source/self-hosted viability and no mandatory recurring per-user Community fee are gates. After that, the decisive factors are daily-work views, knowledge-work quality, permission fit, roadmap adequacy, and the operating model a small team can genuinely own. “Not verified” means the research did not establish a capability; it does not prove the capability is absent.

---

## 📊 Market result: which options deserve a pilot

### Decision-ready shortlist

| Candidate | Licence and cost position | Work-view coverage | Knowledge fit | Decision |
|---|---|---|---|---|
| **OpenProject CE** | GPLv3; unlimited users/projects; no Community seat fee | Kanban, saved table/list-like views, calendar, Gantt, multi-project timeline | GFM Wiki with history/diffs and Markdown export; Documents lack versioning | **Top pilot** |
| **Leantime** | AGPLv3 core; parity plugins proprietary | Kanban, Table, List, Calendar, project Gantt | Rich project Wiki; Markdown round trip and durable versions unverified | Conditional pilot |
| **Plane CE** | AGPLv3; no stated CE seat cap | List, Board, Calendar, Table, Timeline | Project Pages; workspace Wiki and several features paid | Conditional pilot |
| **Huly self-hosted** | EPL-2.0; no stated self-host fee | List and Kanban; stable grid/calendar/Gantt unverified | Strong live Docs; raw Markdown round trip unverified | Conditional pilot |
| **Vikunja + Docmost** | Both AGPLv3; no identified Community cap | List, Table, Kanban, Gantt | Real-time rich Docs, history, Mermaid, embeds, Markdown interchange | Conditional pilot |
| **Nextcloud Deck + Collectives** | AGPLv3 stack; no identified Community cap | Kanban and Gantt; no task List/Table | File-backed Markdown wiki with versions/search/import | Conditional pilot |
| **YouTrack Server Free** | Proprietary; free up to 10 Users/3 Agents | Table/list/tree, Kanban, dashboard calendar, Gantt | Strong Knowledge Base and ClickUp importer | Conditional only if proprietary is acceptable |

### Why OpenProject Community Edition leads

OpenProject CE is the only validated candidate that puts a genuine GPLv3, unlimited-user Community edition together with configurable work packages, project and parent-child hierarchy, Kanban, saved filtered queries, calendar, interactive Gantt, multi-project timeline, a versioned Markdown-based Wiki, role permissions, API/webhooks, and documented backup/operations material. It is likely more formal and project-centric than ClickUp, so the live pilot should test its work-package/query mental model rather than presume it will feel intuitive.[1] [11] [12]

The Wiki is the correct OpenProject knowledge surface to test first. It supports GFM, rich editing, tables, images, macros, internal embeds, history/diffs, locking, and Markdown export. Its separate real-time Documents module does not have version history. The POC must explicitly test imports/exports with images and tables, representative permissions, self-hosted mobile use, and whether the team prefers project Wiki pages or Documents for each knowledge workflow.[12] [13]

### Conditional pilots, selected by the team’s dominant priority

**Choose Leantime** if an integrated project Wiki with tables, images, embeds, Mermaid, math, comments, and project-oriented task planning matters most. Its core covers To-Dos, hierarchy, dependencies, Kanban/Table/List/Calendar, milestones, sprints, and project Gantt/timeline. Program roadmaps, custom fields, recurrence, Whiteboards, and MCP are paid proprietary plugins, and its Wiki is HTML-persistent rather than established as a Markdown-native round-trip system.[2]

**Choose Plane CE** if modern work-item UI is the leading concern. It has a credible task model and the sought List, Board, Calendar, Table, and Timeline layouts. Its Community Edition is not a full free ClickUp clone: the workspace Wiki, advanced planning, several permissions, and some collaboration/export/search capabilities are paid or disputed by first-party documentation. Treat a time-boxed local deployment as the authority.[3]

**Choose Vikunja plus Docmost** if Markdown-first Docs, rich tables, embeds, diagrams, real-time collaboration, and document history are non-negotiable. Vikunja handles shared tasks, nested projects, dependencies, List/Table/Kanban/Gantt, search, API, and signed webhooks. Docmost Community adds the richer doc system. The price is architectural: no verified shared identity, unified permissions, unified search, or native cross-linking bridge.[4]

**Choose Nextcloud Deck plus Collectives** if file-backed Markdown knowledge, a unified identity/files layer, Calendar, and low-vendor dependence matter most. Deck brings shared cards, dependencies, Kanban, Gantt, and Calendar integration. Collectives and Text bring collaborative Markdown pages, tables, comments, history, WebDAV/downloads, full-text search, and bulk Markdown import. This stack is not a replacement for ClickUp task List/Table, deep hierarchy, custom work-item types, or portfolio planning.[14]

### Useful reference products rather than selected pilots

GitLab Self-Managed Free and GitHub Projects provide strong engineering issues, APIs, Git-backed Markdown wikis, and code-adjacent automation. They are weaker general work hubs: GitLab Free lacks native table/calendar planning and free roadmap/Gantt; GitHub is not self-hosted/open source, its free wikis are public, and its roadmap is not a full dependency-aware Gantt.[15] [16]

Notion Free is a strong managed editor/database but is proprietary, has no self-host route, and limits a multi-owner free workspace to 1,000 lifetime-created blocks. Jira Free plus Confluence Free is capable but cloud-only/proprietary and its Free permissions are too broad for ordinary multi-role collaboration. Linear Free and current multi-user AppFlowy self-hosting are excluded for licensing, access-control, capacity, or team-licence blockers.[17] [18]

<details>
<summary><strong>📋 Full validated candidate classification</strong></summary>

| Group | Candidates | Decision condition |
|---|---|---|
| **Top pilot** | OpenProject Community Edition | Pass migration, Wiki/Docs, roles, restore, upgrade, and usability gates |
| **Conditional pilots** | Leantime; Plane CE; Huly; YouTrack Server Free; Taiga; Vikunja + Docmost; Forgejo + Docmost; Nextcloud Deck + Collectives | Address the product-specific gaps described in the deep dives |
| **Reference only** | GitLab Self-Managed Free; GitHub Projects; Notion Free | Accept an engineering-only, managed-cloud, or constrained-free model |
| **Excluded now** | AFFiNE CE; Jira + Confluence Free; Linear Free; AppFlowy self-hosted | Licensing, permission, scale, or core-fit blocker |

</details>

---

## 🧪 Evidence-led proof of concept

Run OpenProject CE first and compare one conditional candidate selected by the team’s largest risk: Leantime for a unified rich project Wiki, Plane for UI modernity, Vikunja plus Docmost for Markdown-first documentation, or Nextcloud Deck plus Collectives for an identity/files/knowledge layer. Use the same representative workload; do not run a generic vendor tour.

```mermaid
gantt
    title 12-week evidence-led replacement pilot
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Setup
    Define workflows and role matrix :crit, setup, 2026-10-01, 5d
    License and operating review :legal, 2026-10-01, 10d

    section Comparison spikes
    Custom core spike :custom, 2026-10-06, 5d
    Plane CE acceptance spike :plane, 2026-10-06, 5d

    section OpenProject CE pilot
    Deploy reproducible staging :deploy, 2026-10-06, 5d
    Migrate representative workload :migrate, 2026-10-13, 10d
    Validate work and docs flows :flows, 2026-10-27, 15d
    Prove permissions and recovery :recovery, 2026-11-17, 10d
    Rehearse upgrade and evaluate :upgrade, 2026-12-01, 10d
    Go no-go decision :milestone, gate, 2026-12-15, 1d
```

| Gate | Required evidence | Fail condition |
|---|---|---|
| Work migration | Map 25–50 representative items: hierarchy, statuses, assignees, comments, dependencies, fields, files, and permissions | Required information or workflow meaning is lost without an acceptable mapping |
| Daily views | Recreate active Kanban, list/table, calendar, and roadmap/Gantt behaviour | A required view is absent, paid-gated, or needs unacceptable manual work |
| Knowledge | Migrate nested pages, tables, images, code, diagrams, links, comments, and history; export/re-import where claimed | No acceptable portability, recovery, search, or authoring model |
| Permissions | Test admin, manager, contributor, reader, and guest accounts | Least privilege cannot be enforced without a prohibited paid tier or external system |
| Resilience | Restore database, files, configuration, and representative content to clean staging | Attachments/configuration disappear or agreed recovery target is missed |
| Operations | Measure components, host capacity, TLS, SMTP, monitoring, backups, and upgrades | No named owner or feasible operating cadence exists |
| Usability | Five intended users execute ten everyday workflows | Pre-agreed time/error thresholds fail or a critical usability failure occurs |

---

## ⚖️ Build, fork, or adopt: what a homemade solution actually entails

### Recommended path: adopt first, earn the right to fork or build

Do **not** start with a ClickUp-parity rewrite. Run a configuration-led OpenProject CE pilot with no source changes and an isolated, idempotent API/webhook bridge. In parallel, run two five-day comparison spikes: a narrow custom-core test and a Plane CE acceptance test. This produces evidence without committing to a lasting fork or multi-quarter rebuild.[19]

![Rendered Mermaid decision flow for selecting upstream operation, a companion extension, a small fork, or a custom MVP](assets/decision-path.png)

*Figure 5: Decision path. The default extension mechanism is a companion service using supported APIs and signed webhooks, not direct database writes.*

### What a credible custom Release 1 must include

A visual prototype is easy. A multi-user work hub that remains correct after concurrent edits, permission changes, retries, and recovery is not. Release 1 should be deliberately smaller than ClickUp and must include these foundations before advanced planning, dashboards, marketplace integrations, or AI.

| Domain | Release 1 capability | Intentionally deferred |
|---|---|---|
| Work model | Workspace/project hierarchy, task/subtask, status, assignee, priority, dates, labels, fields, comments, attachments, activity | Multiple task locations, recurrence, templates, goals, arbitrary hierarchy |
| Daily views | List, Board, Table, Calendar from one query model; saved filters/sorts | Formula engine, pivots, capacity/workload, every display option |
| Docs | Per-project Wiki/Docs, rich text, tables, file links, comments, history, Markdown import/export with loss warnings | Full live-cursor parity, whiteboards, public publishing, arbitrary embeds, AI authoring |
| Access/discovery | Roles, inheritance, permission-filtered search, secure files, audit | Custom roles, enterprise discovery, unrestricted public sharing |
| Automation | Transactional outbox, signed webhooks, one source-control or notification integration | General no-code automation studio and marketplace |
| Operations | TLS, encrypted off-host backups, restore drill, monitoring, staging, upgrade procedure, secret rotation | Multi-region availability and formal enterprise compliance claims |

### Non-negotiable architecture boundaries

The recommended custom fallback is a **workspace-scoped modular monolith**: PostgreSQL as the system of record, private S3-compatible object storage for files, a transactional outbox and worker for effects, and a separately deployable collaboration runtime once live Docs are justified. The single canonical work-item graph must feed List, Board, Table, Calendar, Timeline, Roadmap, and Gantt views; saved views should store a validated filter/layout AST rather than untrusted query fragments. Use central application authorization with PostgreSQL Row-Level Security as defence in depth; enforce policy over HTTP, WebSockets, search, files, counts, exports, workers, and integrations.[20] [21]

For rich Docs, use schema-controlled Tiptap/ProseMirror JSON as canonical data and Yjs for concurrent document state. Persist update streams and snapshots, keep comments and permissions in relational tables, and treat Markdown as lossy import/export compatibility. Tiptap documents limitations around comments and tables in its Markdown support; that is a reason to publish conversion warnings rather than silently corrupt work.[22] [23]

### Fork only when all conditions hold

A fork is justified only for a demonstrated, durable gap that cannot be addressed through configuration, API/webhook companion work, or an upstream contribution. The change must remain isolated from core identity, authorization, persistence, and migration semantics; licence obligations must be accepted; a maintainer must own release intake and security updates; and a rebase/upgrade rehearsal must pass before feature work expands. Maintain a small patch ledger against a tagged upstream, not a long-lived untracked divergence.

A greenfield build should be funded only when essential workflow, retention, authorization, or collaboration needs cannot be represented by the adopted foundation. The architecture workstream uses **6–9 months with 4–6 dedicated engineers for a narrow MVP** as a planning assumption, not a commitment or vendor estimate. A full ClickUp-equivalent suite is an ongoing product program, not a finite feature sprint.[19]

![Rendered Mermaid pilot roadmap showing the evidence-gated staging sequence](assets/pilot-roadmap.png)

*Figure 6: The recommended 12-week pilot sequence. A source fork or a broad custom program should not be authorized before these gates generate evidence.*

### Build concept mock-up

The requested visual concept is available in the accompanying [cyberpunk-styled static research site](site/index.html). Its mock-up illustrates a deliberately scoped “Nebula Work Hub” daily-work experience: one canonical task shown as a Kanban card, a roadmap rail, and a rich context panel. It is an information-architecture sketch, not a claim that the full product has been built.

The implementation-level plan is available as [the self-hosted work-hub implementation plan](build-option/docs/superpowers/plans/2026-09-24-work-hub-mvp.md). It defines the file structure, interface contracts, testing sequence, permission model, task/query contract, document recovery, outbox/webhooks, backups, and Release 1 acceptance gates.

---

## 🎯 Final recommendation

Adopt a **two-level decision**. First, conduct the OpenProject Community Edition proof of concept as the likely production foundation. Second, choose one comparison candidate based on the team’s dominant concern: Leantime for a richer all-in-one project Wiki, Plane CE for modern task UI, Vikunja plus Docmost for Markdown-first collaborative documentation, or Nextcloud Deck plus Collectives for a cohesive file-backed knowledge stack.

Treat the POC as a production decision, not a demo. It should include real permissions, representative ClickUp data, backup/restore, upgrade rehearsal, and observed usability. If OpenProject passes these tests, operate it upstream and use configuration or a small API/webhook companion before considering a fork. Only fund a custom core when evidence establishes that the required work model or collaboration behaviour cannot be safely represented or extended.

---

## 🔗 References

[1]: https://www.openproject.org/community-edition/ "OpenProject Community Edition"

[2]: https://github.com/Leantime/leantime "Leantime source repository"

[3]: https://developers.plane.so/self-hosting/editions-and-versions "Plane self-hosted editions and versions"

[4]: https://vikunja.io/features/ "Vikunja features"

[5]: https://help.clickup.com/hc/en-us/articles/13856392825367-Intro-to-the-Hierarchy "ClickUp Help: Intro to the Hierarchy"

[6]: https://help.clickup.com/hc/en-us/articles/6328174371351-Intro-to-Docs "ClickUp Help: Intro to Docs"

[7]: https://help.clickup.com/hc/en-us/articles/6329880717719-Intro-to-views "ClickUp Help: Intro to views"

[8]: https://clickup.com/pricing "ClickUp pricing and plans"

[9]: https://help.clickup.com/hc/en-us/articles/32274881672599-Views-feature-availability-and-limits "ClickUp Help: Views feature availability and limits"

[10]: https://help.clickup.com/hc/en-us/articles/23477062949911-Automations-feature-availability-and-limits "ClickUp Help: Automations feature availability and limits"

[11]: https://www.openproject.org/docs/user-guide/work-packages/ "OpenProject work packages"

[12]: https://www.openproject.org/docs/user-guide/wiki/ "OpenProject Wiki"

[13]: https://www.openproject.org/docs/user-guide/documents/ "OpenProject Documents"

[14]: https://docs.nextcloud.com/server/stable/admin_manual/collectives/index.html "Nextcloud Collectives administration"

[15]: https://about.gitlab.com/pricing/ "GitLab pricing"

[16]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects "GitHub Projects"

[17]: https://www.notion.com/pricing "Notion pricing"

[18]: https://appflowy.com/docs/Self-hosted-Plans-and-Pricing "AppFlowy self-host plans and pricing"

[19]: https://www.openproject.org/docs/system-admin-guide/api-and-webhooks/ "OpenProject API and webhooks"

[20]: https://www.postgresql.org/docs/current/ddl-rowsecurity.html "PostgreSQL row security policies"

[21]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html "OWASP Authorization Cheat Sheet"

[22]: https://docs.yjs.dev/ "Yjs documentation"

[23]: https://tiptap.dev/docs/editor/markdown "Tiptap Markdown documentation"

---

_Last updated: 24 September 2026. This is a research report, not legal, security, or procurement advice. Product plans and entitlements change; confirm licensing and feature gates in the selected release and contract before migration._