Taskosaur: conversational AI task execution on a self-hosted project management stack

What Taskosaur solves, and for whom

Most project management tools make you translate intent into forms. You know you want a sprint seeded with last week's high-priority bugs, but you still open a sprint dialog, set dates, filter the backlog, tick boxes and assign owners. Taskosaur's premise is that the translation step is removable. Its README describes the assistant as handling project management tasks "through natural conversation, from creating tasks to managing workflows directly within the application", with the example command "Create sprint with high-priority bugs from last week".

The audience is narrower than the feature list suggests. This is for teams willing to run their own PostgreSQL and Redis, hold their own LLM API key, and accept a young codebase. The README lists self-hosting and bring-your-own-LLM as headline features, which tells you the target reader is an engineer or a small platform team, not a department buying seats. If nobody on your side can debug a failing container or rotate a JWT secret, the install path will be the deciding factor, not the assistant.

The mechanism: a NestJS API, a Next.js client and a queue in between

The repository is an npm workspace with two members, frontend and backend, declared in the root package.json. The badges pin the stack: Node.js 22 or later, TypeScript 5, NestJS 11, Next.js 15.2.2, PostgreSQL 16 or later, Redis 7 or later. The backend runs on port 3000 and exposes OpenAPI documentation at /api/docs; the frontend runs on port 3001. That split matters because the AI assistant operates inside the application rather than through a separate chat product.

Redis is not decorative. Both the .env.example and the compose file describe it as being "for Bull Queue", and the environment includes MAX_CONCURRENT_JOBS and JOB_RETRY_ATTEMPTS. So the assistant's actions are queued jobs with a concurrency ceiling and a retry count, not synchronous request handlers. That is a sensible design for long-running agent work, and it also means a stuck job occupies one of your five default slots until it retries or fails.

The README also mentions "In-App Browser Automation", stating that the AI "navigates the interface and performs actions directly within the application". That is a different execution model from calling a REST endpoint per action. It implies the assistant drives the UI layer, which couples assistant behaviour to frontend structure. The README does not explain how that automation is sandboxed or what happens when a page changes shape.

Installing Taskosaur with Docker Compose and running a first sprint

The README calls Docker the fastest path and marks it recommended. Clone the repository, then copy the environment template. The .env.example file carries placeholder secrets and a comment telling you to generate real ones with openssl rand -base64 32 for the JWT secrets and openssl rand -hex 32 for the encryption key.

git clone https://github.com/Taskosaur/Taskosaur.git taskosaur
cd taskosaur
cp .env.example .env

Start the development compose file. According to the README, this single command starts PostgreSQL and Redis, installs dependencies, generates the Prisma client, runs migrations, seeds sample data, and boots both services.

docker compose -f docker-compose.dev.yml up

When it settles, three URLs should answer: the frontend at http://localhost:3001, the API at http://localhost:3000, and the API docs at http://localhost:3000/api/docs. If port 3000 or 3001 is already taken, the README's note says to free them first.

For a manual run instead, the README gives a two-step database setup after npm install. The seed script is described as idempotent and safe to run repeatedly, and a second variant creates an admin user only.

npm run db:migrate
npm run db:seed
npm run dev

Once inside, the first real use is the assistant itself. The README's own example is a single sentence, "Create sprint with high-priority bugs from last week", which it says executes automatically. Expect the result to appear as a sprint in the board view rather than as a chat transcript you then copy by hand. Before that works, the assistant needs a model provider: the README names OpenAI, Anthropic, OpenRouter and local models, with your own API key. The README does not document where that key is entered, so treat the first assistant call as the real configuration test.

Where Taskosaur is the wrong tool

The licence is the first constraint, and it is not a small one. The README states the project is "Available under Business Source License (BSL)". The root package.json does not carry an SPDX identifier; it points to LICENSE.md, and the repository metadata reports the licence as NOASSERTION. For anyone whose procurement or redistribution rules require an OSI-approved licence, that ambiguity alone may end the evaluation. BSL terms vary by project, so the file itself is the only reliable source.

Release history is the second. The most recent release in the repository is v0.1.2, dated 2026-08-22 and labelled "security". Before it, v0.1.1 on 2026-07-14, also labelled "security". Two patch releases at 0.1.x, both security-flavoured, is a young project by any reading. The last push to main was on 2026-09-11, so work is happening, but a version number below 0.2 tells you the API and schema are still moving.

The AI path is the third. Conversational execution depends on an external model, and the README does not describe an offline fallback, a deterministic command grammar, or what the assistant does when the provider is unreachable. If your environment forbids outbound calls to model providers, the headline feature is unavailable and you are left with an ordinary board and sprint tracker. Finally, browser automation that drives the interface is fragile by construction: small UI changes can break assistant actions in ways a plain API client would not notice.

Taskosaur against Vikunja and Taskcafe

The obvious comparisons are the self-hosted trackers people already run. Vikunja and Taskcafe both occupy that space, and the difference is not the board. It is the execution layer.

A tool like Vikunja is a conventional self-hosted task manager: you get lists, boards and an API, and any automation is something you build on top of that API. Taskcafe follows the same shape, a Kanban-centric application you host yourself. Neither is described as shipping an in-app assistant that interprets a sentence and performs the work. With Taskosaur, the natural-language layer and the queue that executes it are part of the product, which is the whole reason to pick it over the alternatives.

That cuts both ways. With a conventional tracker, your automation is code you control and can test. With Taskosaur, the assistant is a component you operate but do not author, and its behaviour depends on a model you do not host. If your team's actual pain is hosting and permissions, a plainer tool is less machinery for the same board. If the pain is the form-filling overhead itself, Taskosaur is addressing the thing the others leave to you.

Licence, upgrade cost and what running it actually asks of you

Taskosaur is not a single container. The compose file defines PostgreSQL 16, Redis 7 and the application, with the app image published as taskosaur/taskosaur:latest. Production deployments therefore inherit three moving parts, and the app's database URL and Redis host are overridden inside the compose network to postgres and redis respectively. Backups, Postgres major-version upgrades and Redis persistence are yours to plan.

Upgrades are the recurring cost. The repository provides npm run db:migrate for schema changes, and Prisma migrations are applied automatically in the Docker path. Since the project is at 0.1.x with security-labelled patches, expect schema churn between versions and read the release notes before pulling a new image. The .env.example also warns that JWT secrets and the encryption key are placeholders; the file itself shows generated-looking values, so do not copy them into anything real. ENCRYPTION_KEY protects sensitive fields such as email passwords, which means losing or rotating it carelessly has data consequences beyond a restart.

On licensing, the README's BSL statement and the package.json pointer to LICENSE.md are the two facts available here. BSL projects typically grant broad use with restrictions on offering the software as a competing hosted service, but the exact grant, the change date and the change licence live in that file. Read it before you build a product on top, and treat this article as a pointer rather than an interpretation.

Editorial conclusion

Adopt Taskosaur if you want a self-hosted board and sprint tracker where an assistant can create and assign work from a sentence, and you are comfortable running PostgreSQL 16, Redis 7 and an LLM API key yourself. Do not adopt it if you need a standard OSI licence, a long release history, or a PM tool with no external model dependency. Before committing, read LICENSE.md in full, confirm your provider is among the supported ones, and check whether the AI path needs an in-app browser session in your deployment.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Taskosaur/Taskosaur on GitHub