namviek is an Nx monorepo whose manifest is still named kampuni, and its compose health check curls a port that only exists on the host

The manifest is named kampuni at version 0.0.0

The root package.json does not describe namviek. It carries `"name": "kampuni"` and `"version": "0.0.0"`, is marked private, and declares `"license": "MIT"` while the project metadata records GPL-3.0 for the repository. Two names for one codebase and two licences in two places is the first thing worth resolving. The rest of the file is a monorepo control surface: Nx serves and builds for three projects, a frontend, a backend and a task-runner, with production scripts pointing at the build output under `dist/`. Prisma appears twice over, with a seed command under a top level prisma block running `ts-node` against the database package, and separate generate, push and seed scripts for two different schema paths. The version being 0.0.0 means nothing in the package metadata can tell you which release of the product you are looking at.

Three schema scripts use Windows path separators and will not run in a POSIX shell

Six Prisma scripts point at two schema locations, and the split is not cosmetic. Three of them take the schema path with backslashes:

"generate": "prisma generate --schema=.\\packages\\shared-models\\src\\prisma\\schema.prisma"

The other three, named generate2, pushdb2 and seed2, use forward slashes and a different package, `packages/database`. The one-click Vercel deploy button invokes `npm run generate2`, so the deployment path selects the second schema while the developer path uses the first. Neither script set says which schema is current, and there is no comment saying either. On a Linux or macOS shell the backslash forms will not resolve, so on the platforms the repository targets for contributors, three of the six database scripts fail before Prisma starts.

The compose health check tests a host port from inside the container

The backend service maps `3333:3000`, so the process inside the container listens on 3000 and 3333 is the host side of the mapping. Its health check is:

healthcheck:
  test: curl --fail http://localhost:3333 || exit 1

From inside that container, port 3333 is not the application, so the check succeeds only if something else happens to answer there, and fails otherwise. The obvious correction is the port the container actually serves on, which is the second half of the mapping. Two more entries in the same service point the same way. The object storage endpoint is set to `http://localhost:9000`, which is the host address rather than the compose service name, and the container is told to run `node ./main.js` directly while the commented-out line above it would have run an entrypoint script and the backend command.

The example environment file ships a password and two signing secrets

The documented first step of a local install is to copy the example file, and the example file contains `DEFAULT_PWD=123123123`, `JWT_SECRET_KEY=12GUY3N76U21d4IJ` and `JWT_REFRESH_KEY=7us9s88o121ieeuo`. Alongside those it sets `DEV_MODE=1` and `EMAIL_VERIFICATION_ENABLED=1`, with `NEXT_PUBLIC_DISABLE_REGISTRATION=1` sitting right next to them. Copying that file to `.env.local` is convenient and is exactly the wrong thing to deploy unchanged, since both signing keys are committed in a public repository and a default password is one a script could rely on. The rest of the file is a list of integrations rather than configuration: PostHog, Resend, Pusher, LiveKit, Firebase, Google Analytics, and two logging backends at once, with Axiom dataset and token variables alongside a Logtail client in the dependencies.

Four hosting targets and one install path that uses a different package manager

Deployment is configured for Vercel, Render, Fly and Netlify, with `render.yaml`, `netlify.toml`, `fly.toml` and two regional Fly files, Singapore and Virginia, matching the two demo instances the README lists. Only Vercel gets a button with its parameters spelled out: build command `npm run generate2 && npm run build:fe`, install command `npm install`, output directory `dist/apps/frontend/.next`, and two environment variables, `NEXT_PUBLIC_BE_GATEWAY` and `NEXT_PUBLIC_APP_NAME`. Note that the button uses npm while the repository ships a `yarn.lock`, a `.yarnrc.yml` and yarn-based install scripts, so the one-click path and the documented local path use different package managers for the same tree. The Render button passes only a repository URL and leaves the rest to Render's own defaults.

The compose scripts always include the developer services file

The two compose scripts are defined as:

"compose-build": "docker compose -f docker-compose.yml -f docker-compose.services.yml build"
"compose-up": "docker compose -f docker-compose.yml -f docker-compose.services.yml up"

The README describes `docker-compose.services.yml` as something provided for contributors who want to work without setting up cloud services, since it runs Redis, MongoDB and Minio locally. But both scripts pass it unconditionally, with no profile flag or environment check, so following the documented setup gives a developer with local Minio and a self-hoster with local Minio, identically. The main compose file declares named volumes for MongoDB data, Minio data and MongoDB config and a bridge network, and references mongodb and redis in its depends_on lists without defining either service, which is only consistent with the second file being present.

The features section has a heading and nothing under it

The README is decorated throughout with emoji, down to a flag beside each demo region, and one of its section headings has no content at all. The features heading is followed immediately by the getting started heading, so the single strongest argument for the product is the section that is empty. What is documented instead is cost. A table compares four commercial tools for a team of thirteen: Jira at 12.80 dollars per user per month, 1996.80 dollars a year, Trello at 10 dollars, 1560 dollars, Monday at 9 dollars, 1404 dollars, ClickUp at 10 dollars, 1560 dollars. Against that, self-hosting is quoted at a fixed 10 to 15 dollars a month, or 120 to 180 a year, with the claim of savings up to 90 percent that grow with team size.

The cost table does not count the services the product needs

That table is arithmetically correct in its own columns and silent about one thing: what the fixed hosting figure is supposed to cover. The product needs MongoDB with a replica set, Redis, and object storage, either Minio in the compose file or S3 through the AWS SDK pinned in the dependencies, and the environment file also expects LiveKit, Pusher, Firebase, PostHog, Resend and an error reporting endpoint, each of which has its own bill outside the four tools being compared. The claim that the cost stays the same as the team grows holds for the licence line and stops holding at the point where a growing team needs larger instances. The argument is still a fair one for a thirteen person team with an existing infrastructure budget; it is not a total cost of ownership.

Editorial conclusion

Use it if your team wants a self-hosted tracker with no per-seat cost and you are prepared to assemble the backing services yourself, since MongoDB, Redis and object storage are prerequisites rather than extras. Do not copy the example environment file into production without changing it, because the defaults it ships include a fixed user password and two hardcoded JWT signing secrets, and dev mode is switched on. Read the compose file before your first `compose-up`, because the backend health check curls port 3333 while the container listens on 3000, and because the object storage endpoint is set to localhost from inside a container. And settle the licensing question for yourself before distributing anything: the project metadata records GPL-3.0 while the package manifest declares MIT, and the two cannot both be right.

Frequently asked questions

Official sources

1. hudy9x/namviek on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README