# Leantime — ClickUp Alternative Deep Dive

**Research cut:** 24 September 2026  
**Product assessed:** [Leantime](https://leantime.io/)  
**Decision context:** Small team seeking a self-hosted, genuinely open-source ClickUp replacement without a recurring per-user fee.  
**Verdict:** **Conditional pilot**

> **Bottom line.** Leantime is a credible self-hosted option when the team can accept a project-management-first system rather than a full ClickUp-equivalent workspace. Its **AGPL-3.0 core**, self-hosted Community Edition, multi-user project work, Kanban/Table/List/Calendar, project Gantt/timeline, dependencies, hierarchical subtasks, rich project wiki, project-scoped roles, backups, and API meet much of the baseline without a recurring per-user licence charge. [1][2][3]
>
> It is **not yet a Top pilot** for this brief. The decisive gaps are not cosmetic: **Markdown import/export for wiki documents is not verified**, wiki history is an activity/audit trail rather than verified restorable content versions, full-text/global wiki search is not verified, and cross-project program roadmaps/custom fields/recurrence/whiteboards are proprietary, paid, user-tiered plugins rather than AGPL core. The free SaaS option does not exist; the free path is self-hosting. [3][4][5][6]

---

## 1. Scope, method, and evidence discipline

This assessment examines **Leantime only**. It prioritizes Leantime’s official documentation, pricing and marketplace pages, official `Leantime/leantime` source repository, release notes, and official support material. Product marketing statements are treated as vendor claims unless corroborated by documentation or source. The source inspection was conducted against the public repository’s current `master` branch as observed on 24 September 2026; those findings are explicitly marked because `master` can be newer than the most recent tagged release. The last stable tagged release identified was **v3.9.8**, published 8 July 2026. [1][7]

### Availability labels used in this report

| Label | Meaning |
|---|---|
| **Verified core / Community** | Supported by official pricing/docs as Community Edition or present in the official AGPL core source. It should be tested in the exact deployed release. |
| **Verified paid / proprietary** | Official pricing, marketplace, or plugin terms identify a paid cloud capability or commercial plugin. It is not part of the AGPL core entitlement. |
| **Verified, but ambiguous entitlement** | Official sources conflict or leave an edition boundary unclear. Do not budget or architect around it until the vendor or pilot resolves it. |
| **Not verified** | A requested capability was not established by first-party material. This is **not** proof of absence, but it must be treated as a requirement gap. |

### Capability map

```mermaid
flowchart LR
  A[AGPL Community Edition\nself-hosted] --> B[Projects, tasks, Wiki\nKanban / Table / List / Calendar]
  A --> C[Project milestone\nGantt / timeline]
  A --> D[Roles, local/OIDC/LDAP\nbackups, JSON-RPC API]
  B --> E[Conditional-pilot strengths]
  C --> E
  D --> E
  F[Commercial user-tier plugins\nProgram Plans / Custom Fields / Recurring / Whiteboards / MCP] --> G[Not AGPL-core path]
  H[Unverified Docs Markdown interchange\nand restorable document versions] --> I[Primary pilot gate]
  E --> J[Conditional pilot]
  G --> J
  I --> J
```

---

## 2. Decision snapshot

| Decision dimension | Assessment | Evidence-led conclusion |
|---|---|---|
| **Licence and ownership** | **Strong** | Core is AGPL-3.0 and self-hostable. Data can remain on infrastructure the team controls. Modified network deployments carry AGPL source-offer obligations. [1][2] |
| **No recurring per-user fee** | **Strong for core; conditional for extensions** | Community Edition has no Leantime seat subscription. Hosting, administration, and optional proprietary plugin/update-pass costs remain. Cloud Pro is recurring per user and no free cloud plan is offered. [3][4] |
| **Tasks, issues, hierarchy and views** | **Strong at project level** | Verified multi-user tasks, subtasks, dependencies, Kanban, Table, List, Calendar, milestones, sprints, and project timeline/Gantt. [3][8][9] |
| **Roadmap / portfolio** | **Mixed** | Project Gantt/timeline is core. A cross-project program plan/roadmap is a paid commercial plugin, not a free core capability. [3][4][10] |
| **Docs / wiki surface** | **Good rich HTML wiki; weak portability evidence** | Wiki tree, rich editing, tables, images, embeds, Mermaid/math, comments, mentions and activity are evidenced. Native Markdown import/export is **not verified**. [5][6][11] |
| **Permissions and collaboration** | **Good for a small team** | Six role classes, project assignments and project-specific role overrides are documented. Fine-grained field/document ACLs are not evidenced. [12][13] |
| **Search** | **Adequate task filtering; conditional knowledge search** | Task table/Kanban filters and text search are verified. Global/full-text wiki search is not verified. [9][14] |
| **Integrations and API** | **Adequate, not broad native-suite parity** | Webhook-style channel notifications, iCal subscription/export and a JSON-RPC API are documented. No built-in outbound webhooks and several integrations are plugin/API work. [15][16][17] |
| **Mobile** | **Responsive web verified; app availability unverified** | Responsive CSS is verified. First-party core source contains mobile-client APIs/push references, but no official native-store app or PWA distribution was verified in the core repository. [18] |
| **Migration/portability** | **Reasonable data custody; limited ClickUp migration** | CSV import/update covers several object types, table exports cover tasks/milestones, and a complete self-host backup can preserve DB/files/config/plugins. No official ClickUp importer or full docs/comments/attachment mapping is verified. [19][20] |
| **Operating burden** | **Moderate** | Team must run Compose/PHP/database, persistent volumes, cron, SMTP, HTTPS, upgrades, plugin compatibility, monitoring and restore tests. [21][22][23][24] |
| **Maturity/governance** | **Active but concentrate risk** | Active releases and CI/security workflows are visible. The security support table is stale and contributor concentration/open issues introduce operational diligence requirements. [7][25][26] |

---

## 3. Licence, edition boundaries, and actual cost

### 3.1 Core licensing: genuinely open source, with AGPL obligations

Leantime’s public repository declares **AGPL-3.0** and ships the GNU Affero General Public License v3 text. This is a genuine OSI-recognized copyleft licence, not source-available “open core” branding for the core application. The self-hosted Community Edition is described by Leantime as self-hosted, community-supported, AGPLv3 and including core functionality. [1][2][3]

The AGPL distinction matters operationally. If the team modifies Leantime and lets users interact with that modified version over a network, AGPL section 13 requires it to offer those users the corresponding source of the modified version. This is usually compatible with internal self-hosting, but it should be accepted by legal/procurement before the team develops private extensions or offers the instance to external clients. [2]

**Important boundary:** the product is not uniformly AGPL once optional marketplace plugins enter the design. The marketplace’s commercial-plugin agreement grants a **non-exclusive, non-transferable, limited internal-business licence**, is tied to a maximum purchased user tier, and prohibits modification, reverse engineering and derivative works. Therefore the base system satisfies the requested true-open-source preference; a workflow dependent on marketplace plugins does not satisfy it end-to-end. [4]

### 3.2 Community/self-managed versus hosted plans

Leantime’s current pricing page says it has **no free cloud/SaaS version**. Its hosted Pro plan is **$10 per user/month when paid monthly** or **$8 per user/month when paid annually**, with a 14-day free trial. The plan page associates Pro with unlimited To-Dos/projects and 500 AI credits per month, among other features. For this decision context, Pro is admissible only as a trial/reference route, not as the preferred enduring deployment model because it is a recurring per-user fee. [3]

The self-managed Community path avoids that licence fee for the core, with no Community seat/storage/usage caps stated on the current pricing page. That is an absence of an advertised cap, **not a guarantee of unlimited capacity**: the actual ceiling is server resources, database/file-storage sizing, PHP execution settings, and operational design. The team must separately budget hosting, backups, outbound email, optional object storage, labour, and any proprietary plugins. [3][21][22]

### 3.3 Paid gates and plugin economics

The following table separates core claims from actual paid gates. Prices are current marketplace list prices observed on the research date; verify the checkout page before approval because tiers and promotions can change.

| Capability / cost | Community self-managed status | Hosted / paid-plugin status | Consequence for this decision |
|---|---|---|---|
| Core projects, tasks, Kanban/Table/List/Calendar, milestones/Gantt/timeline, docs/wiki, templates, dependencies, custom statuses/columns, sprints/backlog | **Verified core** | Also in Pro | Meets baseline without recurring per-user licence. [3] |
| Hosted Pro | Not required for self-host | **$10/user/month monthly or $8/user/month annually**; 14-day trial; no free SaaS | Does not meet “no recurring per-user fee.” [3] |
| Program management / cross-project plan | **Not core** | **Program Plans** commercial plugin; selected-user tiers from 1–3 through 101–250; listed at $39 base tier | Hard decision point if “roadmap” means cross-project portfolio planning. [4][10] |
| Custom fields | **Not core** | Commercial **Custom Fields** plugin; listed at $39 base tier | A material ClickUp parity gap if the team relies on arbitrary field schemas. [3][4] |
| Recurring tasks | **Not core** | Commercial plugin; listed at $39 base tier | Hard workflow gap for routine recurring work unless paid. [3][4] |
| Whiteboards | **Not core** | Commercial plugin; listed at $39 base tier | Do not count it as a free wiki/ideation surface. [3][4] |
| AI | **Not core / cloud plan feature** | Pro includes 500 monthly AI credits; marketplace AI/related modules may vary | Not relevant to core fit; avoid a dependency on it. [3][4] |
| MCP integration | **Not core** | Marketplace “MCP” listed as beta at $29 base tier and requires a Node bridge/client | Not a free integration mechanism. [4][17] |
| Plugin bundle | N/A | Marketplace lists **$99 for 1–3 users**, **$149 up to 10**, **$319 up to 25** | A one-time bundle can be economical for a small team, but is proprietary and user-capped. [4] |
| Plugin updates | N/A | Marketplace says selected-user licence is perpetual and includes one year of updates; it keeps working after that, but updates require a renewed update pass | Not a recurring per-user subscription, but continuing maintenance can cost money. [4] |

The marketplace calls its commercial licences perpetual for the selected user tier and includes one year of update access. That is economically favourable relative to SaaS, but it must not be mischaracterized as open source, unlimited-seat, or lifetime updates. It also creates a version-lock decision: running an outdated plugin to avoid update-pass cost increases security/compatibility risk. [4]

### 3.4 Ambiguous API and SSO entitlement statements

Two official-source inconsistencies warrant a pre-pilot clarification rather than an assumption:

1. The pricing matrix says **“API Access (With Paid Plans)”**, while the official API usage guide documents JSON-RPC API-key creation and calls without clearly limiting it to hosted paid plans. The public core source and docs expose API namespaces. Treat API availability on the exact Community release as **verified technical surface but ambiguous commercial entitlement** until tested or confirmed in writing. [3][16]
2. The installation docs describe local, LDAP and OIDC configuration, whereas the FAQ and pricing material indicate some advanced authentication/SSO arrangements may need an AdvancedAuth plugin or enterprise arrangement. Treat basic local auth as core and federated SSO as **pilot-gated**, not an unconditional Community promise. [3][12][22]

---

## 4. Self-host feasibility, architecture, and operating burden

### 4.1 Deployment feasibility: yes, with normal web-application operations

Leantime has an official Docker image and Compose documentation, plus package-based installation instructions. The current repository README specifies a recent baseline of PHP 8.2+, MySQL 8 or MariaDB 10.6+, and Apache or Nginx with PHP extensions; the general system-requirements page has an older/lower baseline of PHP 8 and MySQL 5.7+, and says its instructions are tested on Ubuntu 20.04+ and Docker Compose. The safer pilot assumption is the current README baseline—not the older minimum—until Leantime publishes reconciled requirements. [1][21]

Official Docker guidance describes a service topology of the Leantime application plus MySQL, with persistent database, user-file and configuration volumes. It also warns that plugin installations need a persistent plugin-folder mount. This is straightforward for a team that already runs Docker/Compose, but it is not “zero-ops.” The team needs an owner for Linux patching, image upgrades, secrets, TLS termination, database recovery, capacity, email delivery and monitoring. [21][22]

| Operational component | What is verified | Minimum pilot decision |
|---|---|---|
| Application runtime | Official Docker image/Compose or PHP/web-server deployment | Prefer official Compose on a maintained VM; pin a released version rather than `master`. [1][21] |
| Database | MySQL/MariaDB in current README; Compose includes MySQL | Use a persistent DB volume or managed DB; schedule logical and restore-tested backups. [1][21][23] |
| File storage | Local userfiles or S3-compatible storage configurable | Decide local volume vs object store before importing attachments. [22] |
| Scheduled work | Cron required at least every 15 minutes; docs show five-minute example | Create and monitor cron before inviting users. [22] |
| Email | SMTP needed for invitations, password reset and notifications | Use an authenticated relay and test deliverability. [22] |
| HTTPS/session security | HTTPS is operationally necessary; config includes secure-cookie control | Put behind a maintained reverse proxy/TLS; disable debug in production. [22][25] |
| Plugins | Folder mount, updates and compatibility need management | Do not install paid plugins until core acceptance is passed; stage upgrades. [21][24] |

### 4.2 Upgrades, support and dependency risk

Leantime’s upgrade guidance requires backups and release-note review, advises disabling plugins for major upgrades, and documents known version-specific upgrade issues. Its Docker guide describes updates as manual. This is tolerable for a small self-hosting team with release discipline, but it is a material cost compared with SaaS. Production should have a staging clone and a documented rollback/restore runbook. [21][24]

The public security policy advises HTTPS, current dependencies, strong passwords, 2FA and backups, and provides a disclosure route. However, its supported-version table says **only 3.4.x** is security-supported despite v3.9.8 being the current observed stable release. This is a documentation-maintenance red flag, not evidence that current releases are unsupported; it must be clarified with Leantime before handling sensitive client or regulated data. The pilot should treat it as a hard governance gate: obtain the supported-security-version policy and patch commitment in writing. [7][25]

### 4.3 Backups and recovery

The official backup guide identifies the relevant recovery boundary: database dump, uploaded user files, configuration/`.env`, and plugins. It recommends the 3-2-1 pattern and restore testing. That is a strong data-ownership story if implemented, but the team owns every failed backup and all recovery time. [23]

A practical production pattern is a nightly encrypted DB dump plus file/config/plugin backup to a separate location, daily retention monitoring, and a quarterly restore into an isolated environment. Backup credentials and encryption keys should be outside the Leantime host. The application itself does not remove the need to retain third-party linked artefacts (for example, externally embedded Google/Microsoft documents) independently.

---

## 5. Work management fit: tasks, hierarchy, views, and roadmap

### 5.1 Core task and issue model

Leantime is centred on project “To-Dos” rather than a separate engineering issue tracker. The official README and pricing matrix verify project task management, multi-user assignment, sprints/backlog, milestones, subtasks, dependencies, time tracking, custom statuses/columns, and project-level views. The FAQ explicitly explains that subtasks are child tasks whose effort/progress roll up to the parent. [1][3][9]

For a small mixed team, this is enough to model ordinary work items, bugs, requests and project tasks. It is **not verified** as a GitHub/Jira-style software issue system with native repository sync, pull-request linkage, release management or developer workflow semantics. If “issues” means work records rather than deep code-host integration, it fits; if it means an engineering tracker, validate integration/API workflow in the pilot.

| Requirement | Status | Evidence and caveat |
|---|---|---|
| Multi-user tasks | **Verified core** | Users, project assignment, task assignment and role model are documented. [1][12] |
| Hierarchy | **Verified core** | Subtasks/parents, task dependencies and project hierarchy are documented/source-evidenced. [1][9][14] |
| Kanban | **Verified core** | Per-project board and statuses are documented. Limitation: the FAQ states one Kanban board/status set per project. [3][9] |
| List/Table | **Verified core** | Table and List To-Do views are in the pricing/features material. [3][8] |
| Calendar | **Verified core** | Calendar view is in the core comparison; iCal subscriptions are documented separately. [3][9] |
| Filters and task search | **Verified core** | Table/Kanban filtering by user, milestone, type and priority plus text search is documented. [9] |
| Custom fields | **Paid, proprietary** | Not part of Community core; a marketplace plugin supplies it. [3][4] |
| Recurrence | **Paid, proprietary** | Not part of Community core; a marketplace plugin supplies it. [3][4] |

### 5.2 Gantt, timeline, and roadmap interpretation

Leantime has a real **project-level** roadmap capability: milestones group date-ranged tasks and appear in Gantt/timeline views. The FAQ says tasks have to be placed in a milestone to appear in Gantt. Dependencies, timing and progress are consequently useful for a project plan but demand consistent milestone assignment. [1][3][8][9]

This should not be conflated with portfolio management. The marketplace’s **Program Plans** plugin adds cross-project program timelines, documentation, risks and dependencies. It is commercial, user-tiered and licensed separately. If the team’s “preferably roadmap/Gantt/Timeline” means a roadmap inside each project, core is sufficient. If it means a ClickUp-style, cross-project portfolio/program roadmap, the requirement is only met via a non-AGPL paid plugin or external reporting. [3][4][10]

| Roadmap need | Community result | Recommendation |
|---|---|---|
| Project milestones and Gantt/timeline | **Verified core** | Include one representative project plan in pilot. [3][9] |
| Dependencies within planned work | **Verified core** | Test dependency display and schedule changes with real work. [1][3] |
| Cross-project roadmap/program plan | **Verified paid plugin** | Budget/license Program Plans only if it is a hard requirement; otherwise keep portfolio roll-up outside Leantime. [4][10] |
| Resource planning | **Paid plugin claim / not core** | Do not assume capacity planning in Community Edition. [10] |

---

## 6. Knowledge, Docs/wiki, rich editing, and Markdown interoperability

### 6.1 What is verified: a substantial project wiki, not plain-text Markdown files

Leantime’s wiki is a project-scoped document system with multiple wikis/notebooks and a hierarchical article tree. Official current source implements article parent relationships, title, tags, draft/published status, author and timestamps; draft articles are visible to their author, and project-scoped permissions guard read/create/edit/delete operations. [5][13]

The current wiki UI source shows a left-hand article tree, editable title/tags/status/parent/milestone properties, a rich Tiptap editor, debounced save, a discussion/comments section, and an activity panel. The discussion capability meets the requirement for document-level collaboration better than a task-only description field would. [5]

The current Tiptap implementation is richly capable. It explicitly enables headings, links, resizable images and uploads, bullet/ordered/task lists, tables with rows/header/cells, code blocks, colors/fonts/alignment, mentions, image/link/table toolbar actions, undo/redo, URL embeds, Mermaid diagrams, math, collapsible details, emoji, table of contents and columns. This is **source-level verification of current `master`**, so the pilot must verify that the selected released Docker image includes the same capabilities. [6][11]

| Knowledge requirement | Assessment | Basis / limitation |
|---|---|---|
| Collaborative wiki / Docs surface | **Verified core** | Project wikis, article tree, create/edit controls, comments and rich editor are in core source and feature/pricing material. [3][5] |
| Rich editing | **Verified in current source** | Tiptap rich editor has major formatting, tables, images, embeds and code options. [6][11] |
| Tables | **Verified in current source** | Tiptap table extensions and toolbar insert command. [6][11] |
| Images / files | **Verified core/source** | Image upload/resizing in editor; attachment/file support in README. [1][6] |
| Embeds | **Verified, bounded** | Google/Microsoft embeds are marketed core; source has URL embed support. Allowed providers and behaviour should be tested, particularly under a restrictive CSP. [3][6][8] |
| Comments / mentions | **Verified core/source** | Wiki comments UI and Tiptap mention extension. [1][5][6] |
| Activity/history | **Verified activity trail, not revision restore** | Audit records field changes and “article.edit”; no content-version/diff/restore model found in the inspected source. [5][13] |
| Wiki page hierarchy | **Verified core** | Parent-child article tree is in source. [5][13] |
| Markdown import | **Not verified** | No first-party user flow or parser/import mapping was identified for Wiki Markdown import. |
| Markdown export | **Not verified** | A `Download as Markdown` language label and HTML-to-Markdown dependency exist, but no verified user-facing wiki export implementation was found. [11] |
| Markdown as canonical storage | **Not verified / likely no** | Current source saves Tiptap `getHTML()` into article description; Markdown is not the verified stored document representation. [5][6][13] |
| Document-level granular ACLs | **Not verified** | Permissions are project/role scoped; no per-page ACL model was established. [12][13] |

### 6.2 Markdown is the principal knowledge-management blocker

The requested solution specifically prefers **Markdown interoperability**. Leantime’s source contains `league/html-to-markdown`, a `Download as Markdown` translation label and generic Markdown formatting helpers, but that is not sufficient evidence of a supported Docs/wiki export or import feature. The editor serializes HTML (`getHTML()`), and source inspection did not establish a user-facing Markdown editor, a Markdown import flow, a wiki Markdown download controller, deterministic round-tripping, or attachment/link rewriting. [6][11]

This report therefore makes the conservative finding: **Markdown interoperability is not verified.** It should not be inferred from its dependencies, labels, source-code view, or Mermaid capability. This is especially important if the team expects Markdown documents to be versioned in Git, moved between tools, or round-tripped without HTML conversion loss.

The pilot must execute an acceptance test with real representative content: headings, tables, task lists, internal links, images/attachments, Mermaid, code, embeds and comments. Test both import and export—not just copy/paste—and inspect fidelity. If no native workflow exists, choose explicitly between: (a) accepting database/HTML-backed docs, (b) building/maintaining an AGPL-compatible exporter/importer, or (c) keeping canonical Markdown in a separate knowledge system. Do not defer this choice until after migrating documentation.

### 6.3 Version history: usable audit evidence, not a confirmed restore mechanism

The wiki service records audit events for article creation, deletion, title/status/parent/milestone/icon/tag changes and content edits; the UI exposes an activity feed. For content edits, however, the inspected source records that an edit happened, not a stored before/after content body or diff. No source/docs evidence of browsing historical versions or restoring a previous version was found. [5][13]

Accordingly, **activity history is verified; document revision history with restoration is not**. Team backups protect against disaster, not routine “restore paragraph from last Tuesday” use cases. The team should test this directly and, if necessary, use periodic export/database snapshot practices or retain canonical material in Git.

---

## 7. Collaboration, permissions, search, and integrations

### 7.1 Permissions are reasonable for a small team, but coarse compared with ClickUp

Leantime documents six system roles: **Owner, Admin, Company Manager, Editor, Commenter and Read-Only**. It allows project-specific roles/assignments, except that Owner and Admin are global. Commenters can comment and upload files while being excluded from project/company settings; read-only users can view but not edit. The official wiki service additionally applies project-scoped authorization to its article operations. [12][13]

This is adequate for ordinary internal teams, invited clients and reviewers. It is not verified as arbitrary custom role construction, field-level permissions, per-page wiki ACLs, granular guest-sharing rules, or complex enterprise approval controls. The official FAQ also flags a known commenter-role issue in some versions, reinforcing the need to test the exact deployed release with least-privilege accounts. [9][12]

### 7.2 Search: do not assume a ClickUp-style global knowledge search

Task discovery is well evidenced: the FAQ documents text search and filters in Kanban/Table views, while API/source documentation includes task search criteria and project search. [9][14]

What is **not** established is global full-text search across wiki body content, files, comments and tasks, or a single workspace search across projects. The wiki source examined focuses on hierarchical navigation and article retrieval; no official wiki full-text search UX was found. Therefore search meets basic work-list discovery but is **conditional** for a knowledge-heavy team. A pilot should load several hundred tasks and a realistic wiki corpus, then test search relevance, permissions filtering, performance and attachment search.

### 7.3 Integrations: practical primitives, not extensive native ecosystem parity

The official integration material documents webhook-style updates for Slack, Mattermost and Zulip for work changes, comments and files; pricing/README also list Discord, producing a first-party source discrepancy. Treat Slack/Mattermost as confirmed and verify Discord in the chosen release before promising it. [1][3][15]

For calendars, Leantime supplies a per-user iCal URL that can be subscribed to in Google Calendar, Outlook and Apple Calendar. The official FAQ describes this as a one-way subscription; direct two-way CalDAV sync needs a plugin. Current marketplace search did not establish a current CalDAV listing or price, so its present purchase availability should be confirmed before committing to it. [9]

The JSON-RPC API is documented with API keys scoped by project/role, and its namespace covers Calendar, Comments, Files, Projects, Tickets, Wiki and related modules. The FAQ says Leantime does not provide built-in webhooks; integrations needing outbound event triggers require a plugin or API work. This makes the API a credible integration escape hatch, but not a turnkey Zapier/ClickUp automation substitute. [14][16]

| Integration need | Assessment | Caveat |
|---|---|---|
| Slack / Mattermost notifications | **Verified** | Webhook-style outbound updates documented. [15] |
| Discord | **Ambiguous** | Listed in pricing/README but absent from the current integrations documentation reviewed. Test first. [1][3][15] |
| Calendar subscription / ICS | **Verified core** | One-way iCal subscription is documented. [3][9] |
| Two-way calendar sync | **Paid plugin / current purchase availability unverified** | Needs CalDAV plugin per FAQ. [9] |
| API | **Technically documented; commercial entitlement ambiguous** | JSON-RPC and API keys documented; pricing matrix is inconsistent. [3][16] |
| Native webhooks | **Not built in** | API/plugin route required. [9] |
| Marketplace MCP | **Paid proprietary beta** | Requires a Node bridge/client; not necessary for baseline. [4][17] |
| GitHub-native project/issue sync | **Not verified** | Use API/custom integration only after testing. |

### 7.4 Mobile

Leantime’s responsive stylesheet supports phone-size breakpoints, responsive navigation, tables and calendar controls. That verifies usable responsive web intent. The core source also contains mobile-oriented API, push-notification and mobile SSO code references. [18]

However, the official core repository inspection did not verify a first-party native Android/iOS package, app-store listing, or PWA manifest/service-worker distribution. Those source references may serve a separate client, but the client was not established by first-party product documentation in this research. Therefore the defensible current conclusion is **responsive web verified; native mobile availability, cost and support status unverified**. Mobile-first users should test the responsive web UI and obtain a vendor answer before migration.

---

## 8. Migration, data portability, and exit posture

### 8.1 Entering Leantime

Leantime officially supports CSV import/update for To-Dos, Milestones, Users, Projects, Ideas and Goals. The importer is present in the AGPL core source and accepts a CSV with a header row; official support material describes mapping/templates. [19][20]

That is useful for initial migration of projects and work items, but it is **generic CSV**, not a verified ClickUp migration tool. No first-party evidence was found for importing ClickUp Spaces/Folders/Lists exactly, custom fields, task relationships, comments, attached binaries, rich Docs, page versions, automations, dashboards or permission models. Plan an explicit mapping and accept that some structures must be flattened or rebuilt.

| ClickUp-origin data class | Leantime migration status | Pilot action |
|---|---|---|
| Projects / task lists | **CSV import plausible/verified object family** | Map to projects and use a sample import. [19] |
| Tasks / assignees / milestones | **CSV import/update verified at high level** | Test field mapping, status and dates with production-like samples. [19][20] |
| Nested tasks | **Destination supports hierarchy** | Validate CSV mapping/order; do not assume recursive hierarchy mapping without a test. [1][9] |
| Custom fields | **Destination is paid plugin** | Inventory fields; eliminate, map into tags/description, or license plugin. [3][4] |
| Docs/wiki content | **Not verified** | Build a manual/content conversion plan; Markdown fidelity is not established. |
| Comments/attachments/history | **Not verified** | Archive the source export separately; do not promise a full migration. |
| Dashboards/automations/relationships | **Not verified** | Rebuild selectively using API or external automation. |

### 8.2 Exiting Leantime and disaster recovery

Self-hosting provides a strong fundamental exit posture: the team controls the database, uploaded files, `.env`/configuration and installed plugin files, and official backup/restore guidance covers those assets. Task/milestone table exports and API access provide additional operational extracts. [16][19][23]

That is better described as **data custody** than frictionless data interchange. Because wiki content is stored as rich HTML in the inspected source and official Markdown export is unverified, the team should maintain its own periodic structured exports/database snapshots and document conversion strategy. Commercial plugin content may also have proprietary schemas/licence restrictions; include plugins in backup and exit testing. [4][5][6][23]

---

## 9. Security, reliability, maturity, and governance

### 9.1 Security controls and operational responsibilities

Leantime documents local auth, LDAP/OIDC configurations, 2FA in its core feature list, role-based access, TLS-oriented cookie configuration, SMTP, S3-compatible files, telemetry controls and backups. Current source shows project-scoped authorization on wiki operations and recent release notes include fixes for access/legacy-role regressions. [1][5][7][12][22]

These are useful controls, but self-hosting transfers the responsibility for network exposure, reverse proxy headers, TLS, secrets, authentication configuration, database patching, filesystem permissions, anti-malware policy for uploads, backup encryption, log retention and incident response to the team. The configuration guide specifically warns that debug mode can expose sensitive detail. [22]

The pilot security baseline should include HTTPS-only access, private database network, secrets outside source control, secure backups, 2FA testing, least-privilege roles, external vulnerability scanning, a pinned release image, and a rollback-tested upgrade process. Do not enable marketplace plugins with administrator accounts until plugin vetting and upgrade responsibility are agreed.

### 9.2 Active project, but evidence of rapid change and concentrated stewardship

The project is active: stable releases v3.9.0 through v3.9.8 appeared during June–July 2026, with v3.9.8 addressing milestone/timeline defects, file-browser memory issues, role-related 403 regressions and MCP issues. The repository also exposes active acceptance, unit, API, static-analysis, CodeQL and security workflows. These are positive indicators of active maintenance and automated quality practices. [7][26]

The counterweight is maturity risk. The latest release itself contains multiple regression fixes; current public issues include active product and security-related reports; and GitHub contribution data show very high concentration in the top maintainer relative to other contributors. This does not establish poor quality, but it is a valid **bus-factor and release-validation risk** for a business-critical system. The current repository has public issue templates, contribution guidance, a CLA requirement and a code of conduct, which are positive governance signals. [1][26][27]

**Governance conclusion:** Leantime is not an abandoned hobby project, but it should be operated as a fast-moving, founder/lead-maintainer-concentrated open-source product. Pin releases, test upgrades, keep an exit-ready backup, and obtain support/security-policy clarification rather than assuming enterprise-grade lifecycle guarantees.

---

## 10. Hard blockers, conditional gaps, and non-blocking caveats

### Hard blockers if the requirement is strict

1. **Canonical Markdown Docs interchange:** Exclude Leantime for this role unless the pilot proves a supported Markdown import/export path with acceptable fidelity, or the team accepts a separate canonical Markdown system. HTML-backed rich docs are verified; native Markdown workflow is not. [5][6][11]
2. **Free native mobile app requirement:** No official first-party mobile app availability/cost was verified. Responsive web is not the same thing. [18]
3. **Cross-project roadmap must be AGPL/free:** Program Plans is commercial and user-tiered. Core project Gantt is not a substitute for every portfolio requirement. [4][10]
4. **Highly granular Docs/field permissions:** Only role/project-level controls were verified. Do not assume ClickUp-like custom granular permissions. [12][13]

### Conditional gaps that can be accepted or bought around

- **Custom fields and recurring tasks** require commercial plugins. [3][4]
- **Two-way CalDAV** is plugin-dependent and current commercial availability/pricing was not verified. [9]
- **API/SSO licensing statements conflict** across official pages; confirm Community entitlement before building integrations or identity architecture. [3][12][16]
- **History is activity, not confirmed restorable versions**, so document recovery expectations need a backup/Git strategy. [5][13]
- **Global wiki search has not been established**, so content-heavy users must test it. [9][14]
- **Discord integration evidence conflicts**; verify on the exact version. [1][3][15]

### Non-blocking caveats

- The Community Edition provides community support rather than an included enterprise SLA. [3]
- Docker makes deployment practical but does not make it maintenance-free. [21][22]
- Commercial plugin licences are perpetual for the bought tier with one year of updates, not recurring subscriptions; nevertheless, they are proprietary and update-pass dependent. [4]

---

## 11. Recommended pilot design and acceptance criteria

Approve a **time-boxed Conditional pilot**, not a broad migration. Run it on an isolated self-hosted released image and do not start with paid plugins. The pilot should be passed only if the following gates are met.

| Gate | Acceptance test | Pass condition |
|---|---|---|
| **Deployment/recovery** | Deploy official Compose/released image, configure HTTPS/SMTP/cron, perform backup and restore to a clean host. | All data, files and role access recover; no secrets/debug exposure; documented runbook. [21][22][23] |
| **Core work management** | Two real projects with 5–10 users, nested tasks, dependencies, multiple statuses, Kanban/Table/List/Calendar, milestone Gantt. | Team can plan/execute/report without spreadsheets; task hierarchy and timeline behave as expected. [3][8][9] |
| **Permissions** | Owner/Admin/Editor/Commenter/Read-Only accounts across two projects and a client/reviewer account. | No cross-project data leakage; commenter/read-only behaviour meets policy; exact version has no role blocker. [12][13] |
| **Knowledge** | Create a representative handbook/decision record with tables, images, attachments, embeds, Mermaid, comments, mentions and edits by two people. | Editing, comments, audit/activity and rendering are usable in daily work. [5][6] |
| **Markdown gate** | Attempt supported import/export or document an alternative using the exact sample corpus. | Either verified acceptable round-trip exists, or decision-makers explicitly accept HTML/database docs or a separate canonical Markdown repository. |
| **Search** | Search realistic task/wiki corpus with different role accounts. | Task discovery is adequate and document retrieval meets team expectation; otherwise list it as a known limitation. [9][14] |
| **Integration** | Test selected chat notifications, iCal subscription and JSON-RPC API key restrictions. | Required integrations work with documented failure handling; API entitlement is confirmed in the self-hosted edition. [15][16] |
| **Migration** | CSV-import a representative ClickUp export and compare record counts, dates, assignments, hierarchy, attachments and comments. | Mapping and manual-rebuild effort are quantified before production cutover. [19][20] |
| **Upgrade/security** | Apply one staged release upgrade with backups and run vulnerability/config review. | Upgrade, plugin compatibility and rollback are operationally acceptable; vendor clarifies supported-version security policy. [7][24][25] |
| **Roadmap economics** | Decide whether project Gantt is enough; if not, license and test Program Plans. | Paid proprietary plugin is an explicit exception, not accidental scope creep. [4][10] |

### Suggested adoption boundary

Use Community core for project/task execution, project milestones, basic schedule views and project wikis. Keep canonical long-lived Markdown documentation elsewhere until compatibility is proven. Do not buy Program Plans, Custom Fields, Recurring Tasks, Whiteboards or MCP until the core workflow is adopted and the team has decided that each plugin’s proprietary licence, user tier and update discipline are acceptable.

---

## 12. Final fit verdict: **Conditional pilot**

Leantime is a **Conditional pilot** rather than a reference-only product because it clears the central ownership test: the core application is genuinely AGPL-3.0, self-hostable and not subject to a mandatory per-user subscription. It also delivers a meaningful amount of the requested work-management surface in core—multi-user tasks, hierarchy, dependencies, Kanban, Table/List/Calendar, project Gantt/timeline, comments, roles, rich project wiki, backups and API. [1][2][3]

It cannot be elevated to **Top pilot** until the team resolves its knowledge-management requirements. In particular, Markdown interchange and restorable document versions are not proven; wiki search depth is unclear; roadmap breadth beyond a project is commercial/proprietary; mobile client status is unverified; security-support documentation is stale; and operation/upgrade responsibility is real. The correct next move is a two-to-four-week self-hosted pilot with the gates above—not a production migration or paid-plugin purchase.

---

## Sources

[1]: https://github.com/Leantime/leantime "Leantime official GitHub repository"
[2]: https://raw.githubusercontent.com/Leantime/leantime/master/LICENSE "Leantime AGPL-3.0 licence"
[3]: https://leantime.io/pricing/ "Leantime official pricing and Community Edition comparison"
[4]: https://marketplace.leantime.io/ "Leantime official marketplace pricing and plugin licence/update-pass statements"
[5]: https://raw.githubusercontent.com/Leantime/leantime/master/app/Domain/Wiki/Templates/show.blade.php "Leantime official Wiki UI source"
[6]: https://raw.githubusercontent.com/Leantime/leantime/master/public/assets/js/app/core/tiptap/index.js "Leantime official Tiptap editor implementation"
[7]: https://github.com/Leantime/leantime/releases/tag/v3.9.8 "Leantime v3.9.8 official release notes"
[8]: https://leantime.io/features/ "Leantime official feature descriptions"
[9]: https://docs.leantime.io/installation/frequently-asked-questions "Leantime official FAQ: tasks, views, calendar, permissions and integrations"
[10]: https://marketplace.leantime.io/product/leantime-program-plans/ "Leantime Program Plans official marketplace listing"
[11]: https://raw.githubusercontent.com/Leantime/leantime/master/public/assets/js/app/core/tiptap/extensions/toolbar.js "Leantime official Tiptap toolbar source"
[12]: https://support.leantime.io/en/article/leantimes-user-access-rights-breakdown-2fq3s4/ "Leantime official role and access-rights guide"
[13]: https://raw.githubusercontent.com/Leantime/leantime/master/app/Domain/Wiki/Services/Wiki.php "Leantime official Wiki service source"
[14]: https://raw.githubusercontent.com/Leantime/docs/master/api/classes/Leantime/Domain/Projects/Services/Projects.md "Leantime official Projects API reference"
[15]: https://raw.githubusercontent.com/Leantime/docs/master/using-leantime/integrations.md "Leantime official integrations documentation"
[16]: https://docs.leantime.io/api/usage "Leantime official JSON-RPC API usage guide"
[17]: https://docs.leantime.io/installation/leantime-mcp "Leantime official MCP installation guide"
[18]: https://raw.githubusercontent.com/Leantime/leantime/master/public/assets/css/components/mobile.css "Leantime official responsive mobile stylesheet"
[19]: https://support.leantime.io/en/article/importing-data-via-csv-1v941gy/ "Leantime official CSV import guide"
[20]: https://raw.githubusercontent.com/Leantime/leantime/master/app/Domain/CsvImport/Services/CsvImport.php "Leantime official CSV import source"
[21]: https://docs.leantime.io/installation/docker "Leantime official Docker installation guide"
[22]: https://docs.leantime.io/installation/configuration "Leantime official configuration guide"
[23]: https://docs.leantime.io/installation/backup-restore "Leantime official backup and restore guide"
[24]: https://docs.leantime.io/installation/upgrade-guide "Leantime official upgrade guide"
[25]: https://raw.githubusercontent.com/Leantime/leantime/master/SECURITY.md "Leantime official security policy"
[26]: https://api.github.com/repos/Leantime/leantime "Leantime GitHub repository metadata"
[27]: https://raw.githubusercontent.com/Leantime/leantime/master/CONTRIBUTING.md "Leantime official contribution guidance"

### Source caveat

Several important editor/mobile observations come from the official repository’s current `master` source, not a release-tagged copy. They are deliberately reported as **source-verified but pilot-required**. Pricing, plugin gates and security policy can change; confirm them at procurement and before deployment.