Internal teams may self-host it, but clients may not share it
TaskView's license permits self-hosting for employees and contractors, but it excludes customer logins without a separate commercial agreement. The product itself puts a substantial slice of software-team operations in one application. Projects contain lists, tasks, nested subtasks, dependencies, recurring work, sprints, time entries, and financial records. The web app has task, Kanban, graph, and sprint views, while mobile clients cover iOS and Android. Release v1.56.0 added invoices and OAuth 2.1.
The licensing boundary matters more than the 1,077 GitHub stars. TaskView calls itself source-available and explicitly says it is not OSI-approved open source. Individuals, families, employees, and contractors may use a self-hosted instance internally. Customers and other third parties are excluded from the license's permitted users. Running it for a client, giving a client access to your instance, selling hosted access, or building a competing task product requires a separate commercial license.
The API and MCP server can act on real project data
The README documents GitHub, GitLab, Gitea, signed webhooks, scoped API tokens, and a TypeScript client. Teams can limit access by project and permission. That makes TaskView plausible as an internal work hub when commits, automation, and task state need to meet in the same place.
The MCP server runs through npx -y taskview-mcp and needs 2 values: the TaskView server URL and a tvk_ API token. Claude Code, Claude Desktop, Cursor, and Windsurf use the same stdio setup. An assistant can inspect projects, create tasks, update them, change statuses, and work with lists only within the token's scope. That is useful power, and it is also a reason to issue a narrow token instead of reusing an administrator credential.
What happened when we ran it
Our fresh Debian sandbox checkout at commit 46b3d1e failed during installation after 1 second. The run used 3 CPUs, 8 GB of RAM, an unprivileged container with no secrets, and the lab-node:22 image. The repository itself contained 1,917 files, about 128,903 lines of source, and occupied 44.2 MB before dependencies. No packages were installed, so there is no dependency or installed-disk figure to report.
The final log says Node could not load /work/home/.corepack/v1/pnpm/12.6.0/bin/pnpm.cjs. It also prints Node.js v18.20.8. That is all the failure proves: the pnpm program expected at that path was absent in the process that ran. We did not reach a build or a test command. Our scan found one CI workflow, no Dockerfile, and no tests directory in the measured checkout.
Production needs four containers and secrets you must replace
The hosted documentation describes 4 containers: PostgreSQL, a migration runner, the API, and the web app. It presents Docker Compose as the production path, while the contributor route asks for Docker, PostgreSQL, Bun, and pnpm. Those are different jobs. A buyer evaluating the product should use the deployment guide; a contributor investigating our failed install will need to trace the Corepack and pnpm setup first.
Configuration is not a single database password. The API example includes database coordinates, JWT_SIGN, a 32-byte encryption key, public application and API URLs, and optional SMTP settings. GitHub, GitLab, and Gitea integrations each need OAuth credentials. OAuth 2.1 dynamic client registration is off by default, and the comments say cloud AI clients cannot connect through that route until an operator enables it. HTTPS, persistent volumes, backups, and secret replacement remain operator work.
OAuth 2.1 shipped in v1.56.0; attachments are still open work
The September 22, 2026 release added OAuth 2.1 authorization, an invoice module, cloud MCP sign-in, and tighter permissions for API tokens and OAuth apps. It also blocked outgoing webhooks to private and internal address ranges by default. Self-hosters whose receivers sit on the same network can override that behavior, but the environment file warns against doing so on a public multi-tenant instance.
File attachments had not reached a release. Issue 113 opened on September 8 to discuss the architecture, and pull request 121 was still open on September 27. Issue 119 also records a smaller workflow limit: the dependency panel can select an existing task but cannot create a new one there. These are specific absences in an otherwise broad feature list, and either can decide a migration before UI polish does.
The September push record is healthy, while the checkout needs work
GitHub recorded the last push on September 27, 2026, 5 days after v1.56.0. It listed 5 open issues and pull requests when fetched. Recent history also shows maintainers closing authentication, role, navigation, and database-connection reports, then folding fixes into releases. That combination is better evidence of current maintenance than the star count by itself.
TaskView makes the most sense for an internal software group that wants one owner-operated system and will test the Docker deployment against its own identity, email, backup, and automation requirements. Our 1-second install failure blocks any claim that source setup is smooth. The license blocks an equally important path: if customers need to log in, settle the commercial terms before migrating a single project.