Huly – Open-source project management platform

Overall reception

  • Many find the product visually impressive, feature-rich, and like that it’s open source and self-hostable.
  • Others are wary: project management is crowded, “everything apps” often feel unfocused, and complex stacks are hard to self-host.

All‑in‑one positioning & scope

  • The app markets itself as a replacement for Linear/Jira/Slack/Notion/Motion (and even Roam in one place).
  • Some see this breadth as a red flag: “everything” often means nothing is best‑in‑class; Slack‑replacement in particular is seen as an uphill battle.
  • Others argue an integrated stack is exactly the differentiator: “good enough” chat tightly integrated with issues/docs can be valuable, especially if chosen top‑down in companies.

Pricing and SaaS economics

  • Compared to tens of thousands per year for Jira/Confluence/Slack, Huly’s ~$3.6k/year pricing is seen as aggressive.
  • Commenters emphasize that SaaS pricing is largely value- and lock‑in‑based, not cost‑based; tools like Atlassian and Postman are cited as examples of high-margin, captive pricing.
  • Some think high per‑seat SaaS prices are acceptable for large, high‑margin companies but absurd for small businesses.

Self‑hosting & architecture

  • Major thread around self‑hosting complexity: Huly requires multiple services (Mongo, Elastic, Minio, several app services).
  • Concern: this “SaaS-style” microservice architecture is burdensome for self-hosters who must understand, tune, back up, and scale each component.
  • Some suspect complex, under‑documented setups are a deliberate moat to push users to the hosted offering; others say it’s just the “nature of the beast” for feature‑rich apps.
  • Counterexamples are discussed: single-binary backends (often Go + SQLite + local disk) seen as much friendlier for self-hosting and small orgs, with debate over SQLite’s real scaling limits and HA trade‑offs.
  • There’s tension between configurability (being able to plug in existing corporate infrastructure) and minimizing dependencies for small users.

Deployment tooling (Docker, Kubernetes, etc.)

  • Many want “at most a docker-compose.yml and .env” for a basic install; Kubernetes manifests are seen as verbose and overkill for the typical self‑hoster.
  • Some appreciate the provided k8s configs, others call raw manifests a poor upgrade story and too complex for the likely audience.
  • Debate over Docker: some see it as a “boat anchor,” others as the only practical way to make complex apps reasonably installable.

Search, performance & resource use

  • Minimum 4GB RAM requirement raises eyebrows for a largely text‑oriented app.
  • One explanation: ElasticSearch and Mongo are resource‑hungry components.
  • Alternative search engines (including Postgres full‑text and various OSS projects) are suggested; it’s unclear what, if anything, Huly will adopt.

Design & marketing

  • The landing and pricing pages, especially laser/fiery animations and a clock, are widely praised and saved as design inspiration.
  • These effects are implemented as videos, not pure CSS.
  • The website reportedly cost ~$90k+ in design/motion work, which some find “crazy,” others see as strong branding.

Naming & language

  • “Huly” closely matches a Russian vulgar interjection; some Russian speakers find the name hilarious or off‑putting and struggle to take it seriously.
  • Others note that mildly rude names (e.g., other software examples) haven’t hurt adoption and argue name connotations don’t determine quality.
  • Opinions split: some love the irreverence; others see it as a sign of unprofessionalism or disrespect.

Use cases, integrations & gaps

  • Some teams would love to consolidate numerous tools (Linear, Slack, Google Docs/Calendar, Monday, GitHub, Discord) into one platform—if Huly executes well.
  • Others prefer a modular self-hosted stack (e.g., OpenProject + Outline + Matrix + CRM + git forge) and see one huge monolith as undesirable.
  • Video calls are implemented via an open‑source media server (LiveKit).
  • Questions are raised—but not clearly answered in the thread—about mobile support (some report issues), running demos, API documentation, data export, and performance at scale.