15+
customizable ClickUp layouts documented on the product feature page
Research dossier · September 2026
Escape the per-seat gravity well.
An evidence-led map of self-hosted, open-source, SaaS, GitHub-native, forked, and built-from-scratch paths away from ClickUp—without pretending a Kanban clone is a work hub.
01 / The actual replacement target
ClickUp is a connected work system, not a board.
The research began by documenting ClickUp’s capability model before naming any alternative. The practical baseline is the connection between work hierarchy, flexible task data, daily views, rich Docs/wiki, comments, permissions, reporting, and search. Breaking that connection is a workflow downgrade even if a replacement has attractive individual screens.
60 MB
shared ClickUp Free workspace storage, illustrating that “unlimited users” is not unlimited collaboration
1 graph
the required design principle: views are projections of one authorized work model
Docs are a work surfaceNested pages, rich media, task linkage, comments, history, sharing, and export are visible parity requirements.
The comparison contract
Every finalist was tested against seven dimensions: tasks/issues, Kanban and other views, roadmap, rich knowledge/Docs, multi-user permissions, licence/cost, and operating burden.
Work graphGate
Docs/wikiGate
Daily viewsGate
PermissionsGate
RoadmapPriority
Dashboards / AILater
Free-plan trap: ClickUp Free permits unlimited tasks and members, but gates shared storage, dashboards, Forms, structured fields, capacity views, external automation, Chat volume, and granular guest permissions.
02 / Validation result
One top pilot. Several honest trade-offs.
The table does not award points for a feature name alone. It records only validated capability, and it leaves gaps visible. “Conditional” means the product deserves a controlled pilot, not a production commitment.
| Candidate | Licence / cost | Views and roadmap | Knowledge fit | Operational posture | Decision |
|---|---|---|---|---|---|
| OpenProject CE | GPLv3 · unlimited users/projects · no Community seat fee | Kanban, query-backed lists/tables, Calendar, Gantt, multi-project timeline | GFM Wiki, tables, history/diffs, Markdown export | Moderate: PostgreSQL, TLS, backups, upgrades | Top pilot |
| Leantime | AGPLv3 core · paid proprietary plugins | Kanban, Table, List, Calendar, project Gantt | Rich Wiki; Markdown round trip/history gaps | Moderate: Docker/PHP, DB, cron, plugins | Conditional |
| Plane CE | AGPLv3 · no stated CE seat cap | List, Board, Calendar, Table, Timeline | Project Pages; workspace Wiki / advanced features gated | Moderate: multi-service Compose stack | Conditional |
| Vikunja + Docmost | AGPLv3 + AGPLv3 · no identified Community cap | List, Table, Kanban, Gantt | Real-time rich Docs, tables, embeds, history, Markdown interchange | Medium-high: two identities, two backups, bridge work | Conditional |
| Nextcloud Deck + Collectives | AGPLv3 stack · host-defined capacity | Kanban and Gantt; task List/Table gap | File-backed Markdown Wiki, versions, search, import | Material: Nextcloud app/version operations | Conditional |
| YouTrack Server Free | Proprietary · ≤10 Users / 3 Agents | Table/list/tree, Kanban, calendar widget, Gantt | Knowledge Base, history, Markdown export/importer | Moderate: Docker and data volumes | Conditional |
| GitLab SM Free | Open-core · self-managed Free | Issues/lists/boards; Free roadmap/Gantt gap | Git Wiki; general live Docs gap | High: capacity, releases, backup exclusions | Reference |
| GitHub Projects | Proprietary SaaS / commercial GHES | Table, Board, Roadmap; no Calendar | Portable Git Wiki, but private wiki is paid | Low cloud / high GHES | Reference |
| AppFlowy self-host | Commercial multi-user server; Free one seat | Rich database views; no verified Gantt | Strong rich Docs and Markdown support | Moderate-high; licence blocks free team use | Exclude now |
OpenProject CE first
It has the broadest verified foundation compatible with the stated self-hosted, open-source, no-seat-fee preference. The risk is not missing module count; it is whether a more formal work-package/query model and Wiki feel intuitive enough for daily knowledge work.
Compare only one secondary candidate
Use Leantime if an integrated project Wiki matters most, Plane for modern work-item UI, Vikunja + Docmost for Markdown-first Docs, or Nextcloud for a files/identity-centric stack. A broad simultaneous bake-off produces shallow evidence.
03 / Proof, not product theatre
Run one workload through every contender.
A pilot must be an operating test. It should use representative ClickUp hierarchy, custom fields, attachments, comments, permissions, Docs, and planning—not a blank demo board. Restore and upgrade are first-class product tests because self-hosting makes them your responsibility.
Rendered Mermaid Gantt: a 12-week evidence sequence before a fork or custom product is authorized.
Migration gate
Map 25–50 real work items across hierarchy, dates, fields, comments, dependencies, files, Docs, and access. Use a loss register, not an anecdotal impression.
Permission gate
Run a role matrix for admin, manager, contributor, reader, and guest. Confirm least privilege across tasks, Docs, files, search, dashboards, and exports.
Recovery gate
Restore database, files, configuration, and representative content into clean staging. Rehearse the upstream upgrade before production approval.
04 / Build versus fork
Adopt upstream. Extend outside it. Fork last.
Forking exchanges initial speed for maintenance debt. A greenfield rebuild trades vendor dependence for a full product and operations obligation. The evidence-led default is an upstream OpenProject CE pilot, then a narrowly scoped API/webhook companion, then a minimal maintained fork only for a proven durable gap.
Rendered Mermaid decision path. Companion services must use supported APIs and signed webhooks rather than direct writes to the upstream database.
Custom MVP is a platform commitment
Release 1 needs a workspace-scoped task graph, List/Board/Table/Calendar projections over one query contract, permission enforcement across HTTP/WebSockets/search/files, audit/outbox durability, secure attachments, rich Docs with recovery, and tested backups. Advanced roadmaps, workload, marketplace integrations, AI, and ClickUp-level UX parity are later product programs.
Read the staged implementation plan →Architecture commitments
Use PostgreSQL as source of truth; one canonical authorized work model; an append-only activity/outbox record; private S3-compatible objects; an API/worker modular monolith; and a separately deployed collaboration runtime only after live-document Stage 0 tests. Rich-text JSON is canonical; Markdown is compatibility interchange, not the persistence model.
Read the build strategy blueprint →05 / Visual mock-up
Nebula Work Hub: the intended daily-work feeling.
This is a static interface concept—not a built application. It shows the product principle behind the implementation plan: a canonical task can be viewed, moved, scheduled, and documented without changing tools or losing context.
Product systems / Q4 release
Launch control
All systemsAssignee: anyone+ Filter
INBOUND02
Map migration fields◷ Oct 13 · ◉ Ryan
Rehearse clean restore◷ Oct 17 · ◉ Ops
IN FLIGHT02
Validate Wiki workflow◷ Oct 15 · ◉ Docs
Build webhook bridge◷ Oct 16 · ◉ Platform
VERIFIED01
Deploy staging orbit✓ Recorded in audit log
Design principle: do not make navigation, a board, a document, and a roadmap four disconnected products. They are four views over shared, authorized work and knowledge.
Evidence navigation
Trace each conclusion back to its research.
The static site is a visual briefing layer. The Markdown report contains citations, decision logic, pilot gates, and links to every detailed evidence record.