# Taskosaur's compose defaults point CORS at the backend port, and its dist build copies .env

> A TypeScript monorepo pairing a Next.js frontend with a NestJS backend, PostgreSQL and Redis, with an assistant that executes project management tasks by driving the interface. The licence is described three ways, the published tags are ahead of the manifest, and two configuration defaults disagree with the documentation.

**Taskosaur/Taskosaur** — Open Source Project Management with Conversational AI Task Execution. Built for teams who want conversational workflow management alongside traditional PM features. Self-hostable with modular architecture.

- Repository: https://github.com/Taskosaur/Taskosaur
- Website: https://taskosaur.com
- Stars: 566 · Forks: 112
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/taskosaur-taskosaur

## The licence is named three ways and settled by one file

Nothing in the repository agrees on the terms. The feature list states the project is available under the Business Source License. `package.json` does not name a licence at all and instead puts a pointer in the field, `SEE LICENSE IN` followed by a URL to `LICENSE.md`. The repository metadata carries no licence value.

The file that settles it is `LICENSE.md` at the root, and there is no second licence file in the tree to contradict it. So the honest reading is that a source-available licence is in force and that the manifest deliberately declines to encode it, which is a normal pattern for BSL projects and also means any automated scanner reading the manifest learns nothing.

Two releases in the visible history are titled for security, v0.1.1 on 2026-07-14 and v0.1.2 on 2026-08-22, so whatever the terms are, they changed in the same window as those fixes. Read the file before drawing conclusions about either.

The rest of the tree is conventional for a self-hosted app: `SECURITY.md`, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, `ROADMAP.md`, an `AGENTS.md`, a `.husky/` directory and three compose files next to two Dockerfiles.

## Published tags sit two versions above the manifest

The manifest is `@taskosaur/platform` at version 0.1.0, marked private, with `frontend` and `backend` as npm workspaces. The published tags are v0.1.1 and v0.1.2.

So the version field in the manifest is not tracking the release line, and it is not the usual case of a lagging patch bump either: it is behind by two, while the tags themselves are two months and six weeks old respectively. Anything that resolves the version from the repository rather than from a tag will report 0.1.0.

The manifest is also where the runtime floor lives, with Node at 22 or newer and npm at 10 or newer, matching the prerequisite line in the documentation and the `.nvmrc` at the root. The last push to the branch is dated 2026-09-11, about three weeks before this, and the repository is not archived.

What the manifest does not carry is a `version` command or a release script. Bumps appear to happen outside the scripts visible in the file.

## Compose defaults CORS and the frontend URL to the backend port

The documentation is consistent about the port split: backend on 3000, frontend on 3001, API documentation on `http://localhost:3000/api/docs`, and a note that both `docker compose -f docker-compose.dev.yml up` and `npm run dev` claim those ports. The environment example agrees, with `FRONTEND_URL` and `CORS_ORIGIN` both pointing at `http://localhost:3001`.

The compose file disagrees. Its defaults are `FRONTEND_URL: ${FRONTEND_URL:-http://localhost:3000}`, `CORS_ORIGIN: ${CORS_ORIGIN:-http://localhost:3000}` and `NEXT_PUBLIC_API_BASE_URL: ${NEXT_PUBLIC_API_BASE_URL:-http://localhost:3000/api}`, so out of the box the container treats port 3000 as the frontend origin and as the allowed cross-origin source, which is the backend's own port.

In practice the env file wins, since compose reads `.env` for interpolation, so a developer who copies `.env.example` gets 3001 and never sees it. Anyone generating a compose file without an env file, or setting only some of the variables, gets the 3000 defaults instead, and the symptom would be a browser refusing the frontend's requests rather than an error at startup.

The database side has the same shape, with the `DATABASE_URL` in compose rewritten to the `postgres` service hostname and credentials taken from `POSTGRES_USER`, `POSTGRES_PASSWORD` and `POSTGRES_DB`, all three defaulting to `taskosaur`.

## The env example ships formatted secrets and an open Redis

The example file contains values that look generated rather than obviously fake. `JWT_SECRET`, `JWT_REFRESH_SECRET` and `ENCRYPTION_KEY` are all full-length strings, and the comments above them explain how to make replacements, `openssl rand -base64 32` for the JWT secrets and `openssl rand -hex 32` for the encryption key.

That is a workable setup instruction, but it is also a file where three usable-looking secrets are sitting in version control, ready to be copied into a deployment unchanged. Anyone who does copy them shares key material with everyone else who did the same.

The manual setup snippet in the documentation is blunter but safer, with placeholders that announce themselves: `your-jwt-secret-key-change-this`, `your-refresh-secret-key-change-this-too` and `your-64-character-hex-encryption-key-change-this-to-random-value`.

Redis is the other default worth naming. The compose service starts with `redis-server ${REDIS_PASSWORD:+--requirepass "$REDIS_PASSWORD"}`, so an empty password means no `requirepass` argument at all, and `REDIS_PASSWORD` defaults to empty in both the compose file and the example. The broker that backs the Bull queue therefore runs without authentication unless you set one.

## The distribution build copies .env into its own output

One script line deserves attention before anyone packages this for deployment. `start:dist` is defined as building the distribution, copying `.env` into `dist/`, changing into that directory, generating the Prisma client and starting production:

That middle step puts the environment file, database URL, JWT secrets and encryption key inside the build output directory. A `dist` tree is the thing most likely to be archived, copied between hosts or mounted into a container image, so the secrets travel with it.

The rest of the script family is worth knowing as well. `build:dist` runs a Node script at `scripts/build-dist.js`, and there are matching frontend and backend builds plus a clean set for both workspaces. The backend commands are all wrapped in `dotenv`, so each one loads the env file before running, and `test:e2e` is the exception that loads a different one, `dotenv -e .env.test`.

Two compose files sit beside the development one, `docker-compose.prod.yml`, with a production Dockerfile beside the development one, so there are three deployment shapes in the tree and the documentation shown covers the development path.

## The assistant drives the interface instead of calling an endpoint

The distinguishing feature is described as in-app browser automation: the AI navigates the interface and performs actions directly within the application. The framing is conversational task execution, so a request like creating a sprint with high-priority bugs from last week is carried out rather than answered.

Working through the user interface rather than a service API is an unusual choice for a self-hosted tool, and it has two consequences. The same conversation surface works regardless of what the underlying API can do, because the assistant is operating the app the way a person would. And the blast radius of a mistaken instruction is a UI action rather than a rejected request, which is why the rest of the page leans on traditional project management features as the underlying model: Kanban boards, sprints, task dependencies and time tracking.

Models are brought by the user, with OpenAI, Anthropic, OpenRouter or local models supported through your own key. Combined with the self-hosting claim, that keeps inference outside the deployment, and it also means the quality of the assistant depends on a key the operator supplies.

## Six test entry points, one destructive seed command

The command surface is wide and mostly conventional for a workspace monorepo. Development runs both halves at once through `concurrently` with cyan and magenta labels, or one at a time. Tests split into all, frontend, backend unit, watch, coverage and end-to-end. Linting covers all workspaces and formatting is backend-only with Prettier.

The database commands are the ones to read carefully:

```bash
npm run db:migrate         # Run database migrations
npm run db:seed            # Seed database with sample data
npm run db:reset           # Reset database (deletes all data!)
```

The seeds are documented as idempotent and safe to run more than once, which is what makes them usable in a setup script, and there is a separate admin-only seed for people who do not want sample data. Migrations have a deploy variant for production, alongside `db:generate` for the Prisma client, `db:studio` for the database GUI and a `prisma` script that passes through to the Prisma CLI.

The Docker path automates the same sequence on first start: it starts PostgreSQL and Redis, installs dependencies, generates the Prisma client, runs migrations, seeds with sample data and starts both services. So a default development deployment comes up with sample records already in the database.

## Conclusion

Use it if you want project management with a conversational layer and are willing to run PostgreSQL and Redis yourself. Before any deployment, set the licence question aside by reading LICENSE.md, because the feature list, the manifest and the repository metadata name three different terms, and fix the environment yourself: replace the example JWT secrets and encryption key, set a Redis password or accept an unauthenticated broker, and correct the frontend and CORS URLs, whose compose defaults point at the backend port rather than 3001. Pin a tag over the manifest, since the published releases sit two versions above the version field.

## FAQ

### What license is Taskosaur under?

The sources disagree and the page does not resolve it. The feature list says Business Source License, package.json puts a SEE LICENSE IN pointer to LICENSE.md in the license field instead of a name, and the repository metadata carries no value. Read LICENSE.md at the root.

### What does Taskosaur need to run?

Node.js 22 or newer with npm 10 or newer, PostgreSQL 16 or newer, and Redis 7 or newer, or Docker. The documented defaults put the backend on port 3000 and the frontend on 3001, with API documentation at http://localhost:3000/api/docs.

### How does the Taskosaur AI assistant execute tasks?

Through in-app browser automation: the assistant navigates the interface and performs actions inside the application rather than calling an endpoint, so a request like creating a sprint with high-priority bugs from last week is carried out. Models are brought by the user through OpenAI, Anthropic, OpenRouter or local models.

### Does Taskosaur come with default secrets?

The env example contains full-length JWT_SECRET, JWT_REFRESH_SECRET and ENCRYPTION_KEY values plus instructions for generating replacements with openssl. Redis has no password by default, since the compose service only adds requirepass when REDIS_PASSWORD is set, and it defaults to empty.

### Which version of Taskosaur is current?

The published tags are v0.1.2 on 2026-08-22 and v0.1.1 on 2026-07-14, both titled for security, while package.json reports version 0.1.0. The last push to the branch is dated 2026-09-11 and the repository is not archived.

### How do you start Taskosaur with Docker?

Clone the repository, copy `.env.example` to `.env`, then run `docker compose -f docker-compose.dev.yml up`. That starts PostgreSQL and Redis, installs dependencies, generates the Prisma client, runs migrations, seeds sample data and starts the backend and frontend.

## Sources

- [Issues](https://github.com/Taskosaur/Taskosaur/issues)
- [Project website](https://taskosaur.com)
- [README](https://github.com/Taskosaur/Taskosaur/blob/main/README.md)
- [Releases](https://github.com/Taskosaur/Taskosaur/releases)
- [Taskosaur/Taskosaur on GitHub](https://github.com/Taskosaur/Taskosaur)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/taskosaur-taskosaur