Huly (hcengineering/platform) is an open-source all-in-one work platform — a single self-hostable alternative to Linear, Jira, Slack, Notion, and Motion. It bundles project management, CRM, and chat with two modules that put it in the HR value chain: an ATS (applicant tracking) for recruiting and an HRM module for the team. EPL-2.0, TypeScript + Svelte, deployable in minutes with huly-selfhost. It's filed here for those HR modules — but be honest with yourself: Huly is a horizontal platform first, not an HR-first product.
Huly describes itself as "a robust framework designed to accelerate the development of business applications" — and ships a polished suite of those applications on top. The pitch is consolidation: instead of Jira for tickets, Slack for chat, Notion for docs, and a separate ATS for hiring, you run one platform, self-hosted, with one identity model and one data store. The headline framing is a Linear / Jira / Slack / Notion / Motion alternative.
It's built by Huly / hcengineering as the open-source hcengineering/platform repo, licensed EPL-2.0 (Eclipse Public License). The codebase is predominantly TypeScript (~61%) and Svelte (~34%), with JavaScript, SCSS, Rust, and Go for supporting services. Development and deployment expect Node.js 20.11+, Docker, and Docker Compose. A hosted SaaS exists at huly.io, but the 2nth angle is the self-hostable open-source build — the version you can keep on SA infrastructure.
The reason it earns a place in biz/hr is narrow and specific: of its built-in applications, two are HR. The ATS handles the recruiting front of the value chain — candidates, applications, pipelines. The HRM module handles the team side — people records and management. Everything else Huly does (project management, CRM, chat, virtual office) is adjacent, not HR. We surface it here because, for a small team that wants an open-source surface for both their delivery work and their hiring, Huly answers both with one deployment.
Huly's ATS + HRM are team-and-hiring tools, not a payroll-and-statutory HRMS. There is no payroll engine, no leave-accrual ledger, no tax-slab machinery. If you need to actually run South African payroll — PAYE, UIF, SDL, payslips — that's Frappe HR's job, not Huly's. Think of Huly as the front of the chain (attract, track, hire, manage the team) and Frappe HR as the system-of-record spine behind it.
Huly's value is the bundle. Each module replaces a category-leading SaaS tool; together they share one workspace, one search, one notification stream. The two highlighted below are the reason this leaf lives under biz/hr.
Applicant tracking — candidates, applications, vacancies, pipeline stages. The recruiting front of the HR value chain, in the same workspace as the work.
Human-resource management — team members, departments, the people side of the org. Lightweight people management, not payroll.
Issues, sprints, roadmaps — the Linear/Jira replacement. The core of Huly and its strongest module.
Leads, contacts, deals — a built-in customer graph. Where a candidate who's also a customer can be reasoned about in one place.
Team messaging — the Slack replacement, threaded against projects, issues, and documents rather than a separate silo.
Documents (the Notion side) plus virtual-office / team-planning surfaces (the Motion side) — the connective tissue of the suite.
Read through the HR value chain, Huly covers the first stage cleanly and the second lightly. The hand-off — from a hired candidate in the ATS to an employee record in a real HRMS — is the integration seam to design for.
people/.The clean architecture: Huly for attract-track-hire-collaborate, Frappe HR for the payroll-bearing employee record, wired at the offer-accepted boundary. The candidate's identity flows from the ATS into the HRMS; payroll and statutory reporting never touch Huly.
Because Huly bundles a CRM next to the ATS, it's unusually good at the case the CHRO agent (Grace) cares about: when a candidate is also a customer. Same workspace, same contact graph — you can see that the person you're interviewing is also an account you sell to, without stitching two systems together. That overlap is exactly the biz/hr ↔ biz/crm cross-cut the tree calls out.
Huly is not competing with Frappe HR; they cover different ends of the chain. It is competing with the proprietary PM/collab incumbents — and there it has no HRM/ATS rival, because those tools don't ship hiring at all.
| System | Strongest for | HR coverage | Watch out for |
|---|---|---|---|
| Huly | One OSS surface for PM + chat + docs + CRM + hiring; small teams consolidating tools | ATS (strong) + HRM (light); no payroll | Horizontal, not HR-first; younger project; self-host ops on you |
| Frappe HR | The HRMS spine — payroll, leave, the employee system-of-record; pairs with ERPNext | Full HRMS incl. payroll; recruitment module too | No first-party SA statutory pack; needs Frappe skills |
| Linear / Jira | Project management at scale; mature ecosystems | None — no ATS, no HRM | Proprietary; per-seat pricing; no hiring story |
| Notion / Slack | Docs + knowledge; team chat | None natively (templates only) | Proprietary; data leaves your infrastructure |
If you'd otherwise pay for Linear and Slack and Notion and an ATS, Huly collapses all four into one self-hostable platform — and the hiring module comes free with the consolidation. If you need to run payroll, that's a separate system, every time.
Huly is built to self-host. For deployments without modification intent, the project ships huly-selfhost — "a convenient method to host Huly using Docker, designed for ease of use and quick setup."
# Self-host via the official compose setup git clone https://github.com/hcengineering/huly-selfhost cd huly-selfhost # configure HOST_ADDRESS, then bring it up docker compose up -d # → Huly workspace on your own infrastructure
Huly is EPL-2.0 (Eclipse Public License); Frappe HR is GPL-3.0. Both are OSI-approved open source, but the copyleft reach differs. GPL-3.0 is strong copyleft: distribute a modified version and you must release your source under GPL. EPL-2.0 is weak/file-level copyleft: you must share changes to EPL-licensed files, but you can combine them with proprietary modules more freely, and there's an explicit patent grant. For most SA studios self-hosting internally (not distributing a modified binary), neither obligation bites day-to-day — but if you plan to ship a modified fork to clients, the EPL's lighter touch is the easier of the two to live with.
The 2nth selection filter for any system: can an agent read and write its data model? Huly's answer is a qualified yes — there's a real API, but the first-party agent surface is less settled than Frappe's REST-per-DocType story.
Huly is API-driven internally — the Svelte front end talks to platform services, and those services are reachable programmatically. What it does not ship today is a first-party MCP server presenting the ATS/HRM/CRM as agent tools. Treat MCP support as unconfirmed — verify against the repo before designing an agent around it; the project moves quickly and this may change.
The honest builder's read, same discipline as the Frappe HR leaf: treat Huly's API as the integration surface and gate any agent access narrowly. The ATS holds candidate personal information; the HRM holds employee data. Both are POPIA-relevant. An agent that drafts job descriptions, screens applications, or summarises a pipeline is high-value and low-risk; an agent with blanket write access to people records is neither. Scope it, audit it, keep mutations human-approved.
As with several fast-moving open-source platforms in the tree, read Huly's agent story as a capability signal: the data is addressable, the platform is self-hostable, and the modules an agent would want to drive (ATS, CRM) exist. What's not yet a settled, documented, first-party contract is the MCP/tool surface. Don't write a client deliverable that assumes a programmatic Huly agent endpoint without checking the repo first.
Because Huly is self-hostable, an SA team can keep candidate and employee data in-country — on a VM in africa-south1 / af-south-1, or on-prem — rather than in a foreign SaaS region. For POPIA-conscious clients, "the hiring and people data never leaves South Africa" is a real, demonstrable posture, not a contractual promise about someone else's cloud. The ATS and HRM both hold personal information; document the lawful basis and keep access scoped.
Huly has no SA statutory layer — no PAYE/UIF/SDL, no EMP201/EMP501/IRP5, no payslips. That's not a gap in Huly; it's out of scope by design. For SA payroll you pair it with Frappe HR (build the statutory layer yourself) or a commercial SA payroll product (SimplePay, PaySpace, Sage) that ships SARS compliance turnkey. Huly's job stops at the offer.
For an early-stage SA software studio, Huly is a genuinely attractive default: one self-hosted platform for the delivery work and the hiring, no per-seat SaaS bill stacking up across Linear + Slack + Notion + an ATS, and data that stays on your infrastructure. Bring in a dedicated HRMS only when payroll and statutory reporting become real — which is exactly the point at which Frappe HR (or a commercial SA payroll tool) enters the stack.