tego: the README tells you not to use this repository

The page opens by telling you to use something other than this repository

The first paragraph of the README is a caution rather than an introduction. It states that the repository is currently undergoing a core refactor, that using the Git version may lead to various unexpected issues, and that problems should be reported as issues on GitHub.

Then it names three things to use instead:

- an official frontend and plugin collection at `tegojs/tego-standard` - an official Docker image at `tegojs/tego-all` - an official npm package named `tego`

This is an unusual thing for a project README to say. The document you are reading describes a repository whose own recommendation is that you do not build from it, and the three substitutes are a separate frontend repository, a container image and a registry package. The plugin collection in particular is where a real user would spend most of their time, and it is not this repository.

The framing is consistent with the project's stated purpose, which is to be a pluggable framework rather than a finished product. It also means the boundary between this code and a usable system is not drawn in the source tree but in three links near the top of the page.

The last push to the repository is dated 2026-09-24, and the three most recent tags are v1.6.22, v1.6.23 and v1.6.24, published across four days. So the refactor is recent rather than historical, and the caution is current.

The default login is tachybase with the password printed on the page

The quick start ends with the credentials, and they are published credentials:

# Create a new Tego application
npx tego init my-app
# Change directory to the new application
cd my-app
# Start the application
npx tego start --quickstart
# Visit the application
http://localhost:3000

Default username `tachybase`, password `!Admin123.` The default database is `sqlite`, and the page says you can change it in the `.env` file. The application listens on port 3000.

Two things follow. The first installation is reachable on the local network with a password that appears in any search result for this project, so the first action after `npx tego start` should be changing it. Second, the default store is a SQLite file rather than a server, which is a sensible starting point for an evaluation and a poor one for the multi-user platform this framework is meant to grow into.

The username is the more interesting half. The project is called tego, the command is `tego`, and the package is `tego`, yet the default administrator is `tachybase`. Whatever that account is renamed to later, every existing installation carries the earlier name as its first user.

Upgrades run through a second pair of commands:

# Sync latest packages
npx tego sync
# Start the application
npx tego start --quickstart

so `sync` pulls the packages and `start` brings the application up again, which is the whole documented upgrade path.

The root package is private and pnpm-only, yet the quick start runs npx

Three package fields say one thing and the quick start says another.

  "name": "tego",
  "version": "1.6.24",
  "private": true,

The workspace root is private, so it is never published to a registry. There is also a `preinstall` hook:

    "preinstall": "npx only-allow pnpm",

which fails any install attempted with npm inside the repository. The tree confirms the constraint with `pnpm-workspace.yaml`, a `pnpm-lock.yaml` and a `packages/` directory, and the internal dependencies are declared as `workspace:*`, which npm cannot resolve at all.

So a clone of this repository must be installed with pnpm, and the root is not the artifact anyone consumes. Yet the documented path to a working application is `npx tego init my-app`, and `npx` resolves from the public registry.

Both statements can be true, and they are: `npx tego` is a different thing from installing this repository. The registry package is the published wrapper, the checkout is the source of the wrapper, and the source requires a different package manager from the one `npx` implies.

That is worth understanding before you debug a failed install, because an `npm install` inside a clone fails by design rather than by misconfiguration, and the error you get will be about the package manager rather than about what went wrong.

Six command aliases resolve to two binaries

The manifest declares six names for the same tooling.

    "tego": "tego",
    "tegod": "tegod",
    "tg": "tegod",
    "tgi": "tegod install",
    "tgu": "tegod upgrade",
    "ui": "tegod ui"

Two of those are the actual executables, `tego` for the application and `tegod` for the developer tooling. The other four are conveniences: `tg` is another name for `tegod`, `tgi` is `tegod install`, `tgu` is `tegod upgrade`, and `ui` is `tegod ui`.

So there are two real commands, one shorthand, two initialisms and one subcommand promoted to a top-level name. Two of them collide with generic names, since `ui` is a common noun in any JavaScript project and `tg` is short enough to be ambiguous in a shell history.

The developer tooling underneath them is substantial. `build`, `clean`, `dev` and `e2e` each hand off to `tegod`, `pm` and `ui` are `tegod` subcommands, and the package also runs itself through `start` and `tego`. Two meta scripts reach outside: `metadata:sync` runs a script that synchronises package metadata across the workspace, and `settings:update` runs a script that updates settings.

The result is a command surface sized for a monorepo that ships a CLI, a plugin collection and a container image, which is consistent with the project positioning rather than accidental.

Tachybase survives in the workspace dependencies, the website and the Gitee mirror

The previous name is not confined to the default username. It appears in three more places, and each one is somewhere a reader will land.

The internal test package is still scoped to the old name:

    "@tachybase/test": "workspace:*",
    "@tego/devkit": "workspace:*",

Two workspace dependencies, one under `@tachybase/` and one under `@tego/`, in the same list. The rename reached the public package, the command and the newer tooling, and stopped there.

The website is the same. The page links to `tachybase.org` for further reading, and the logo block at the top of the README points at `https://www.tachybase.com`. The `homepage` field in the manifest is different again, set to the GitHub repository readme rather than to either domain.

The mirror is a third identity. Alongside the GitHub and the two README language variants, the link row points at `gitee.com/tachybase/tachybase`, which is the older name in both the owner and the repository.

None of this is a defect that stops anything running. It does mean that searching for the tool by any of its names leads somewhere slightly different, and that documentation written today will sit next to a mirror and a site carrying the other one.

Two smaller editing artefacts in the same file point the same way. The caution paragraph runs `core refactor.Using the Git version` without a space, the licence line ends with a full-width period, and the default credentials line separates the label from the value with a full-width colon. The contributing section also reads `We are welcome to directly contribute code` where it means you are.

Lint on oxlint, tests on vitest, end to end on playwright

The development stack is worth listing because it is unusually current and unusually opinionated.

Linting is `oxlint`, configured through `.oxlintrc.json`, and the lint-staged configuration runs it with `--fix` on TypeScript and TSX files. Formatting is prettier with six plugins loaded at once: sorted imports, package JSON key ordering, JSON key sorting, SQL formatting, plus pretty-quick for staged runs. There is no ESLint anywhere in the manifest.

Tests are split across three tools. Unit and integration coverage runs on vitest with the v8 coverage provider pinned to 3.2.4, end-to-end coverage runs through `@playwright/test`, and the configuration lives in `vitest.config.ts` and `playwright.config.ts`. TypeScript is configured twice, in `tsconfig.json` and `tsconfig.server.json`, which is the server and client split made visible.

Hooks are handled by husky, and commit messages go through commitlint with the conventional configuration and an interactive prompt package. React is pinned to the 18.3 line rather than 19, and the Node type definitions sit at 20.17.10 while the runtime target is decided elsewhere.

Two things in the tree are about tooling rather than the product: `.coderabbit.yaml` with `.cursor/` and `.cursorignore` and a `.codegraph/` directory, so several code navigation and review assistants are configured in the repository. There is also a `SECURITY.md` and a `CODEOWNERS`-style presence through `.github/`, and the repository keeps its Chinese README alongside the English one.

Editorial conclusion

tego suits someone who wants to stand up a no-code or low-code platform and then own it, with a plugin collection and a Docker image that are the sensible starting points. Three things to decide first. The repository is mid-refactor by its own admission, so take the Docker image or the npm package rather than a clone. The default administrator account is published in the documentation, so change it before anything else, and note that the default store is a local SQLite file. And the naming is unsettled: the package is tego, the default user is tachybase, an internal workspace dependency is still @tachybase/test, and the website and Gitee mirror are both tachybase. Expect to spend an afternoon on that.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tegojs/tego on GitHub