TaskView Community: a self-hosted task manager with an MCP server and a source-available licence
TaskView is a self-hosted project and task management platform focused on clarity, ownership, and control. TaskView is built for teams that want a transparent, self-hosted alternative to SaaS task managers.
At a glance
- What is it?
- TaskView is a TypeScript project management platform you deploy on your own hardware, with Kanban boards, sprints, SAML, and an MCP server for AI assistants. The interesting part is the licence, not the feature list.
- Who is it for?
- Adopt TaskView if you are a small software team that wants project data on your own hardware and you have already decided you need sprints, dependencies, and time tracking rather than a plain board. Do not adopt it if you need an OSI-approved licence, or if a single-file SQLite task list would cover your workflow.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap TaskView is aiming at: more than a board, less than Jira
The README states the target explicitly: teams that need more structure than a simple task board but do not want the administration overhead of large enterprise systems. That is a real gap. A Kanban board with columns and cards covers a two-person project. It stops covering you the moment you need task dependencies, sprints, billable hours, and a permission model that distinguishes an agency contractor from an internal engineer. At that point teams usually jump to a hosted SaaS product, and the jump is large.
TaskView's answer is to keep the deployment small and the feature surface wide. The feature list in the README includes projects, lists, tasks, nested subtasks, custom statuses, priorities, tags, deadlines, assignees, a task dependency graph, sprints, recurring tasks, task history, and Markdown content. On top of that it lists time tracking with billable and non-billable time, workload reports, and income and expense tracking with financial reports. That last group is unusual for a developer task tool and points at agencies billing client work rather than pure product teams.
The audience the README names is broad: software teams, startups, agencies, organisations that require self-hosting, and individuals managing technical or personal projects. That breadth is worth reading as a warning as much as a pitch. A tool that tries to serve a solo developer's personal backlog and an agency's client billing in the same install will have settings that neither group needs.
What actually runs: TypeScript, Docker, and a separate MCP process
The repository is primarily TypeScript, and the badge row advertises a Docker-based self-hosted deployment. The README does not include a docker-compose file, an environment variable table, or a database requirement in the excerpt available here, so the concrete deployment shape cannot be confirmed from this material. The badge says self-hosted via Docker; treat the actual compose file as something to read in the repository before you plan a rollout.
The architecture that is visible is a web application plus a server, with two published npm packages sitting alongside it. taskview-api is a TypeScript API client, and taskview-mcp is an MCP server. The README describes a public HTTP API, signed webhooks, and scoped API tokens as the integration surface. So the data flow for automation is: something calls the HTTP API with a token, or an MCP-compatible assistant talks to the MCP server, and both ultimately operate on the same projects and tasks you see in the web UI.
The MCP piece is the part most worth understanding before adoption. The README says that depending on the permissions assigned to an API token, an AI assistant can search and inspect projects, create and update tasks, manage task statuses, work with project lists, and retrieve task content. The permission scoping is the whole design. An MCP server wired to a broadly scoped token is an assistant that can rewrite your board. The same server wired to a read-only token is a search interface. TaskView does not appear to solve this for you; it gives you the token scopes and expects you to pick.
Identity is handled with SAML 2.0, OpenID Connect, and SCIM provisioning, with project-level access restrictions and fine-grained token permissions listed as separate controls. For a self-hosted tool aimed at small teams, shipping SCIM is a deliberate bet that some buyers have an identity provider already and will not run a second user directory by hand.
Getting it running: what the README gives you and what it does not
This is the weakest part of the supplied material. The README excerpt contains no installation section, no docker run or docker compose command, no environment variable names, and no port or volume configuration. It links to https://taskview.tech/docs/ for documentation and to the releases page, and that is where the setup instructions live. Anyone evaluating TaskView should read the docs before assuming the deploy is a single command.
What can be confirmed about the distribution channel: there is a web application, an iOS app on the App Store, an Android app on Google Play, and a self-hosted server deployment. There is also TaskView Cloud at app.taskview.tech, which means the self-hosted path and the hosted path share a codebase and a release cadence. That matters for upgrade planning, because self-hosted users are tracking a project that also ships a hosted product.
The release cadence visible in the metadata is roughly weekly to fortnightly: v1.51.0 on 2026-08-04, v1.52.0 on 2026-08-20, v1.53.0 on 2026-08-27. The last push to the default branch was 2026-09-06, and the repository is not archived. A cadence that tight is good for fixes and bad for operators who pin versions and upgrade quarterly, because the gap between your version and main grows quickly. There is no LTS branch mentioned in the material, and no migration guide is referenced.
The two npm packages give you a second integration path that does not require running the server yourself if you are on TaskView Cloud, but for self-hosted use they are clients pointed at your own instance. If you plan to script against TaskView, taskview-api is the typed entry point and taskview-mcp is the one to install if your tooling speaks MCP.
The licence is source-available, and that is the decision that matters most
The README badge reads Source-Available License, and the repository metadata reports NOASSERTION, which means GitHub could not map the LICENSE file to a recognised SPDX identifier. Those two facts together are the single most important thing on this page. Source-available is not open source in the OSI sense. You can read the code, and the README frames the product around data ownership and self-hosting, but the terms governing redistribution, modification, and commercial use are defined by whatever is in LICENSE, not by the badge.
I am not going to guess at those terms. The material here does not include the licence text, so any statement about whether you may fork it, offer it as a service, or embed it in a product would be invention. What I can say is that a NOASSERTION tag on a project this active is a signal to open LICENSE before you invest engineering time, particularly if your organisation has a policy against source-available dependencies. This is not legal advice; it is a pointer to the file you need to read.
The practical consequence for a self-hosted team is narrower than it sounds. If you are running TaskView internally for your own team, the licence question is mostly about your procurement rules and about what happens if the vendor changes terms later. If you are an agency that wants to host TaskView for clients, or a company that wants to build a product on top of it, the licence question moves to the front of the queue and the answer is not in this README.
Where TaskView is the wrong tool
Two cases stand out. The first is a team that genuinely only needs a board. TaskView ships sprints, dependencies, time tracking, expenses, income reports, SAML, OIDC, and SCIM. Every one of those is configuration surface you will see in the settings, in the permission model, and in the upgrade notes. If your workflow is three columns and a card per task, you are paying an administration cost for features you will not switch on, and a lighter self-hosted board will get you to the same place with less to maintain.
The second case is any organisation that requires an OSI-approved licence. The source-available badge and the NOASSERTION metadata put TaskView outside that category until you read LICENSE and confirm otherwise. That is not a criticism of the project's choice; it is a constraint that eliminates TaskView for some buyers regardless of how good the software is.
There are softer failure modes too. The permission model is granular enough that misconfiguration is a real risk: project-level access restrictions, role permissions, scoped API tokens, and fine-grained token permissions all interact. The README does not describe a default-deny posture or an audit log for permission changes, and the material does not mention one. If you hand an MCP-compatible assistant a token, the blast radius is whatever that token can reach. Teams should treat the token scope as the security boundary and verify what each scope grants rather than assuming the defaults are conservative.
Finally, the release cadence cuts against slow upgrade cycles. Weekly-to-fortnightly releases with no stated LTS branch mean self-hosted operators either upgrade often or run stale. Neither is free.
Alternatives, and how the approach actually differs
The obvious comparison is a plain self-hosted Kanban board, the kind you deploy with a single container and a SQLite file. The difference is not features, it is the data model. A simple board stores cards in columns. TaskView stores tasks with nested subtasks, a dependency graph, sprint membership, time entries, and a history record, and it layers organisations, roles, and token scopes on top. That extra structure is what lets you answer questions a board cannot, such as which task is blocking which, or how many billable hours a client project consumed. It is also what makes the install heavier and the settings deeper.
The other comparison is a hosted SaaS task manager, which is the thing the README positions against. The difference there is control, not capability. A hosted product owns the database, the uptime, and the upgrade schedule. TaskView hands you all three along with the operational work: you run the server, you run the backups, you handle the SAML configuration, and you decide when to take v1.53.0. For teams with a real reason to keep project data on their own infrastructure, that trade is the point. For teams without one, it is overhead.
A third comparison worth naming is the MCP angle. TaskView is not the only task tool with an API, but shipping a dedicated MCP server as a published npm package is a specific bet that AI assistants will be a normal way to interact with a project tracker. Whether that bet pays off depends on how the token scoping behaves in practice, which is something the README describes only at the level of what an assistant can do, not how the boundaries are enforced.
Maintenance cost and the upgrade question
The maintenance picture from the metadata is a project in steady, frequent motion: three releases in August 2026, a push to main in early September 2026, and no archive flag. For a self-hosted operator, the cost is not the initial deploy, it is the cadence. If releases land every week or two, a quarterly upgrade means reading several changelogs at once and hoping no migration step was skipped. The material does not mention database migrations, a version compatibility matrix, or a supported upgrade path, so that is a question to put to the documentation before you commit.
The licence carries its own maintenance cost in a different sense. A source-available project can change terms between versions, and the repository's NOASSERTION tag means the current terms are not machine-readable. If your organisation tracks dependency licences automatically, TaskView will show up as an unknown and someone will have to resolve it by hand. Doing that once at evaluation time is cheap. Discovering it during a procurement review after you have built on the API is not.
The integration surface adds a third cost. taskview-api and taskview-mcp are published npm packages with their own versions, and the README lists GitHub and GitLab integrations plus signed webhooks. Each of those is a thing that can break when the server changes. Teams that lean on the API heavily should plan to track the server version and the client version together rather than treating the npm packages as stable independent dependencies.
Editorial conclusion
Adopt TaskView if you are a small software team that wants project data on your own hardware and you have already decided you need sprints, dependencies, and time tracking rather than a plain board. Do not adopt it if you need an OSI-approved licence, or if a single-file SQLite task list would cover your workflow. Before committing, read LICENSE in the repository and confirm what the NOASSERTION tag on GitHub actually maps to, then check whether the MCP server's permission model matches how you intend to hand tasks to an AI assistant.
Community notes