Tego: a Node.js core for building your own low-code platform
Tego is a pluggable Node.js framework for building customizable development platforms. It enables developers to create their own no-code/low-code systems or event-driven applications, while the core focuses on stability and environment adaptability.
At a glance
- What is it?
- Tego is a TypeScript framework that supplies the backend core for a self-hosted low-code or event-driven application, with the UI and plugins shipped separately. The repository is mid-refactor, and the README says so before anything else.
- Who is it for?
- Adopt Tego if you are building an internal tool or admin dashboard and want the backend core, plugin model and workflow primitives handled for you; the Docker image and the tego-standard plugin collection are the paths the README points at for stable production use. Do not adopt it if you need to track main directly, or if you want a general-purpose HTTP framework where you control every layer.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- 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 problem Tego targets: platform builders, not app builders
Most Node.js frameworks assume you are writing an application. Tego assumes you are writing the thing other people build applications on. The README describes it as a pluggable framework for building customizable development platforms, aimed at developers who want to create their own no-code or low-code system or an event-driven application. The repository topics point the same direction: admin-dashboard, internal-tools, crm, erp, approval, workflows. That is the shape of the target workload. Someone needs a self-hosted back office with CRUD screens, an approval chain and a workflow engine, and they would rather assemble it than write it.
The audience is therefore narrower than the topic list suggests. If you want a finished low-code product to log into, Tego is not that. If you want the substrate that a finished product is built from, and you are willing to own the frontend and the plugin selection, it is aimed at you. The core is explicitly scoped to stability and environment adaptability, which is a statement about what the core does not do: it does not carry the UI.
What the core owns and what it deliberately leaves out
The split between repositories is the architecture, and it is visible in the README rather than in a diagram. The core repo holds the framework. The official frontend and plugin collection live in tegojs/tego-standard. The packaged runtime lives in the tegojs/tego-all Docker image, and the npm package tego is the published entry point. Four artifacts, four responsibilities.
That arrangement means the core's job is to define extension points and keep them stable while the surface above changes. The README frames this as the core focusing on stability and environment adaptability, which in practice is a promise about the plugin contract rather than about features. The consequence is that a question like "does Tego have a kanban view" is answered by tego-standard, not by this repository, and the answer can change on a different release cadence than the core. When you evaluate Tego, you are evaluating two version streams at once.
The framework is written in TypeScript. The README does not document the plugin interface, the lifecycle hooks, or the event model, so the mechanism by which a plugin attaches to the core cannot be confirmed from the supplied material. That is a real gap for anyone whose decision hinges on writing a plugin rather than installing one.
Getting a Tego instance up with init, start and sync
The README gives a three-command path. First, npx tego init my-app scaffolds a new application. Then cd my-app, then npx tego start --quickstart, and the application is served at http://localhost:3000. The default credentials are documented as username tachybase and password !Admin123. The default database is sqlite, and the README states it can be changed in the .env file. It does not list the environment variable names, so the exact key you set is something you will find in the generated .env rather than in the README.
The --quickstart flag is worth noting. It appears on the start command rather than being a separate setup step, which suggests the flag drives first-run provisioning such as schema creation and seeding. The README does not say that, and I am not asserting it; what is confirmed is that the flag is present in both the initial start and the upgrade start.
Upgrades follow a two-command pattern. Run npx tego sync to pull the latest packages, then npx tego start --quickstart again. The sync command is the upgrade mechanism, which means the CLI is the thing that reconciles your installed packages with upstream, not a package manager invocation you write yourself. If you are used to pinning versions through npm or pnpm directly, that is a different mental model and worth testing on a throwaway instance before you run it against anything you care about.
The refactor warning is the first thing you should read
The README opens with a caution block stating that the repository is undergoing a core refactor, that using the Git version may lead to various unexpected issues, and that problems should be reported as GitHub issues. Directly beneath it, three alternatives are listed for stable production usage: tego-standard for the frontend and plugin collection, the tego-all Docker image, and the tego npm package.
This is unusually direct for a project README, and it should govern how you read everything else. The practical reading is that the main branch is not the product. If you clone the repository and build from source, you are working on a moving target that the maintainers themselves flag. The stable surface is the published npm package and the Docker image. The release history is consistent with active work: v1.6.18 and v1.6.17 landed two days apart in August 2026, after a gap back to v1.6.16 in July. Two releases in one week followed by a month of quiet is a pattern that fits refactor work, though the README does not say the refactor is finished, and nothing in the supplied material indicates when it will be.
The honest position for an evaluator: treat the Git version as a preview channel. If your plan requires reading the source to understand behaviour, you are also accepting that the source is in flux.
Where Tego is the wrong choice
The clearest failure mode is dependency on the core repository as a source of truth. If your team's workflow is clone, patch, build, and you need those patches to survive upgrades, the refactor warning means your patches are competing with upstream changes to the same code. The README offers no compatibility guarantee for that path.
A second boundary is scope. Tego is not a general-purpose web framework. If you are writing a public API with a handful of routes and no admin surface, the plugin model, the workflow topics and the low-code framing are overhead you will carry without using. A plain Node.js HTTP server or a minimal router is a smaller thing to operate, and it will not ask you to reconcile a core and a plugin collection on separate release trains.
A third is documentation depth. The README covers installation, upgrade and licence. It does not cover the plugin API, the event model, the data layer beyond the sqlite default, or deployment beyond localhost. The contributing section asks users to describe deployment and usage background and to share cases where current interaction methods fall short, which reads as an acknowledgement that those cases are not yet collected. For a framework whose value proposition is extensibility, the extension documentation is the missing piece.
How this differs from assembling the same thing on a general server framework
The obvious alternative is building on a general-purpose Node.js server framework and wiring the admin layer yourself. The difference is where the abstraction sits. On a general framework, you write routes, you write the CRUD handlers, you choose an ORM, and you design your own extension mechanism if you want plugins at all. Tego inverts that: the extension mechanism is the product, and the CRUD, admin dashboard and workflow capabilities arrive as plugins from tego-standard rather than as code you author.
That inversion has a cost. You inherit someone else's plugin contract, someone else's release cadence for the frontend, and a CLI that manages package sync on your behalf. In exchange you skip the design work of inventing a plugin system and the maintenance of an admin UI. Whether that trade is good depends entirely on whether the plugin collection covers your requirements. If you need a CRM-shaped internal tool, the topic list suggests the coverage is there. If your domain is unusual, you will be writing plugins against an interface the README does not document, and that is the point where the general framework starts looking cheaper.
Licence, upgrade cost and what to check before you commit
Tego is licensed under Apache 2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes. It does not impose copyleft obligations on your own code. This is a description of the licence text, not legal advice; if you are redistributing Tego inside a commercial product, have counsel read the NOTICE and modification clauses rather than relying on a summary.
Upgrade cost is shaped by the two-repository split. Core upgrades go through npx tego sync followed by npx tego start --quickstart. Plugin and frontend upgrades come from tego-standard on its own schedule. There is no documented compatibility matrix in the supplied material, so the safe assumption is that core and plugin versions are expected to move together, and that you should test a sync against a staging instance before running it in production. The refactor warning makes that testing non-optional rather than a best practice.
The concrete thing to verify first is whether the tego-all Docker image tracks the v1.6.x releases. The README recommends it for stable production use, but it does not state its tagging convention or how promptly images follow npm publishes. Pull the image, check the version it reports, and compare it against the npm package before you decide which artifact your deployment pipeline consumes.
Editorial conclusion
Adopt Tego if you are building an internal tool or admin dashboard and want the backend core, plugin model and workflow primitives handled for you; the Docker image and the tego-standard plugin collection are the paths the README points at for stable production use. Do not adopt it if you need to track main directly, or if you want a general-purpose HTTP framework where you control every layer. Before committing, verify three things: that tego-all is current with the v1.6.x line, that the plugins you need exist in tego-standard rather than only in the core repo, and that the refactor warning in the README has been lifted.
Community notes