Huly Platform: a TypeScript framework for building business apps, not just a Jira replacement

What Huly Platform actually is, and who ends up using it

The repository describes itself as a framework for accelerating business applications, with Chat, Project Management, CRM, HRM and ATS shipped inside it. That framing matters. Teams looking for a hosted Linear or Jira substitute will find the README telling them the hosted Huly service has been discontinued because its hosting is no longer funded. What remains is the code: a TypeScript monorepo you build and run on your own infrastructure, or through the separate huly-selfhost repository, which the README points to for people who want to host Huly with Docker without modifying it.

The intended audience is therefore split. One group runs the applications as an end user product on their own servers. The other builds on the framework: the README names Huly itself and TraceX as products built on the Platform, and the topic list covers applicant tracking, issue management, QMS and support. If your team writes TypeScript and wants a CRM or ATS whose data model it controls, this is the relevant layer. If you want someone else to operate the service, this repository is not that.

The monorepo layout and the services behind the apps

The top level is broad: packages/, plugins/, pods/, server/, server-plugins/, services/, models/, foundations/, dev/, templates/, tests/ and ws-tests/ all sit side by side, with rush.json at the root driving the build. Models and foundations are separated from the application packages, which is the arrangement you would expect from a platform that wants several products to share one schema layer. The README defers the details to ARCHITECTURE_OVERVIEW.md rather than summarising them, so anyone evaluating the runtime topology has to open that file.

Two version streams are documented. Production tags start with v, for example v0.7.310 and v0.6.501, and the README calls these recommended for production deployments and suitable for self-hosted installations. Development tags start with s, for example s0.7.313, and are described as pre-release builds that may contain experimental features and are not recommended for production. Branching follows the same idea: develop is the default branch for contributions, staging is for pre-release testing, and main is what production deployments use, with changes reaching main only after a build passes in the pre-release deployment. That is a conventional promotion pipeline, and it means the tip of develop is not what you should deploy.

Installing Huly Platform and running it for the first time

The README lists three requirements: Node.js v20.11.0, Docker, and Docker Compose. If you use nvm, run the repository's version alignment command after entering the repo.

nvm use

The README then suggests confirming that Docker is reachable before going further.

docker --version
docker compose version

Dependencies come from GitHub Packages, so an unauthenticated npm will fail. You generate a GitHub personal access token with at least read:packages, then log in against the GitHub registry; when prompted, the token goes in as the password.

npm login --registry=https://npm.pkg.github.com

The build itself is driven by Microsoft Rush. Install it globally, then install and build from the repository root.

npm install -g @microsoft/rush
rush install
rush build

The README also offers a shortcut that performs the Rush setup for you, and a fast-start script for the whole environment.

sh ./scripts/presetup-rush.sh
sh ./scripts/fast-start.sh

One step precedes all of this: the communication layer is a git submodule, so initialise it first, and update it when it changes.

git submodule init
git submodule update

What you should see is Rush resolving the workspace and building the packages in order. The README notes that development environment setup requires Docker, and that both amd64 and arm64 containers are supported. For a plain self-hosted install rather than a development checkout, the README directs you to huly-selfhost instead of this repository.

Where the setup bites: tokens, submodules and the missing hosted tier

The GitHub Packages dependency is the first real obstacle. A fresh clone built without an authenticated npm session will not resolve dependencies, and the failure surfaces during rush install rather than at clone time. The required scope is documented as at least read:packages, so a token minted for a different purpose will not do.

The submodule is the second. Forgetting git submodule init and git submodule update leaves the communication layer absent, and the README treats this as a setup step rather than an optional one. Combined with a pinned Node.js v20.11.0, the environment is stricter than a typical npm project.

The largest constraint is not technical. Hosted Huly has shut down, and the README attributes that to hosting no longer being funded. There is no fallback managed tier inside this repository. The README's own answer to that is the backup and restore guide in docs/guides/backup-restore.en.md and the community Slack for migration questions. If you were evaluating Huly as a service, that evaluation is over; what is left to evaluate is the software and your willingness to operate it.

Huly Platform is also the wrong tool when you want a single application rather than a framework. The repository carries ATS, HRM, QMS and CRM topics alongside issue tracking, and the build spans server, pods, plugins and services. A small team that only needs an issue tracker inherits all of that surface area, plus the Rush toolchain, to get one module.

How Huly Platform differs from Linear and Jira

Linear is a hosted product: you sign up, and the data model is the vendor's. Jira is available as a managed cloud service or as Data Center that you install, but the extension surface is plugins and Forge apps against Atlassian's platform rather than a TypeScript monorepo you fork. Huly Platform sits in a third position. It is EPL-2.0 source you can modify, and the README explicitly frames it as a framework for building business applications, which is why CRM, HRM and ATS live in the same repository as issue management.

The practical difference shows up in the API story. The README points to an API client in the huly.core repository, described as a typed interface for all Huly operations, with usage examples in the huly-examples repository. That is a different integration model from writing against a vendor's REST endpoints: the client is typed against the same operations the applications use. It also means the client lives outside this repository, so version alignment between the two is something you check rather than assume.

Licence and the cost of keeping up

The repository is EPL-2.0. That is a copyleft licence with a reciprocal obligation: if you distribute modified versions, the licence terms travel with them. What that means for a specific commercial deployment depends on facts a review should establish, and nothing here is legal advice. The relevant point for planning is that this is not a permissive licence you can ignore if you fork the platform into a product.

Upgrade cost is shaped by the release cadence and the branch model. Production releases are tagged v*, and the most recent listed are v0.7.426 on 2026-07-05, v0.7.423 on 2026-05-10 and v0.7.413 on 2026-04-14. The changelog file at the repository root is where the README says per-version changes, improvements and bug fixes are documented, so a self-hoster tracking production tags reads that file between upgrades. The last push to the repository was on 2026-09-17, so development is ongoing; the question for an operator is how far develop has moved past the last v* tag you deployed. Because the build is a Rush monorepo with a pinned Node version, an upgrade can require a toolchain change as well as a dependency bump.

Editorial conclusion

Adopt Huly Platform if you want a TypeScript codebase you can extend into CRM, ATS or HRM modules rather than a product you only configure, and if you are willing to run Docker, Node.js 20.11.0 and a Rush monorepo build yourself. Do not adopt it if you need a managed service: the README states the hosted Huly service has been discontinued because its hosting is no longer funded, and the supported path is huly-selfhost with Docker. Before committing, verify that the npm authentication against GitHub Packages works with a token carrying at least read:packages, and check the changelog for the v0.7.426 release on 2026-07-05 to see whether the modules you need moved.

Frequently asked questions

Official sources

1. hcengineering/platform on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases