HedgeDoc is an open-source, self-hostable collaborative markdown notes application, written in TypeScript and licensed under AGPL-3.0, for teams and individuals who need several people editing the same document in a browser at the same time.

What it is

HedgeDoc is a real-time collaborative markdown notes application. Its topic list places it in the collaboration, editor, markdown, notes and real-time space, with diagram support listed alongside. The project is written in TypeScript, carries 7,424 stars, 596 forks and 275 open issues, and is published under AGPL-3.0, with the licence explicitly excluding the HedgeDoc logo, whose terms sit in a separate repository. The topics list also retains the codimd tag, reflecting the project's earlier identity in the same collaborative-notes ecosystem, and names hackmd as a neighbouring tool in that space.

The concrete problem it addresses is shared markdown authoring. Instead of one person holding the document and others waiting for a hand-off, HedgeDoc lets multiple people create and edit the same markdown note at once. Because it is installable on your own infrastructure through the published install guide rather than being tied to a vendor-hosted account, the instance, the notes and the server stay under the control of whoever runs it. That combination — simultaneous editing plus self-hosting — is what the project is built around.

Key capabilities

• Real-time collaborative editing of markdown notes, the defining capability named in the README.
• Diagram support, listed in the project topics alongside the editor and markdown tags.
• Browser-based markdown editor, evidenced by the editor and markdown topics.
• Self-hosted deployment using the install guide at https://docs.hedgedoc.org/setup/getting-started/.
• A public demo instance at https://hedgedoc.org/demo/, with a features page at https://demo.hedgedoc.org/features.
• A HedgeDoc 2 alpha available at https://hedgedoc.dev, documented at https://docs.hedgedoc.dev.
• A split architecture for HedgeDoc 2, with the backend and frontend both living in the same repository.
• Translation work coordinated through POEditor, and release announcements available as an Atom release feed.

Who uses it and how

• Organisations that want collaborative notes on their own servers deploy from the install guide rather than signing up for a hosted account.
• The 1.x line is described as stable and used around the world, so the common production shape is a self-run 1.x instance.
• Evaluators and newcomers use the demo instance to see the editor and its features before installing anything.
• Contributors and early testers work against the HedgeDoc 2 alpha at hedgedoc.dev, coordinating through the Matrix development chat and CONTRIBUTING.md.
• People packaging or patching 1.x take the source from the master branch, while the develop branch in this repository carries the in-progress 2.x code.

Getting started

Install HedgeDoc yourself by following the install guide at https://docs.hedgedoc.org/setup/getting-started/, or try the hosted demo instance first. Development environments are covered in the developer documentation at https://docs.hedgedoc.dev.

How it compares

The facts supplied here do not include a list of paid products that HedgeDoc is positioned to replace, so no licence, hosting or cost comparison is asserted. Among the similar tools the project itself names, the topic list references hackmd and codimd, placing HedgeDoc in the same collaborative-markdown-notes category; what those tools cost, where they run, or how their features differ is not covered by the available facts.

When to use it — and when not to

HedgeDoc 1.x is stable but maintenance-only: feature requests and pull requests are no longer accepted for that release, and non-critical bug reports may be closed if the issue will not exist in 2.0. Anyone who needs upstream to take new feature work, or who needs a complete 2.x today, should not adopt it on that basis — this branch holds the latest development code and does not implement all features yet, and the 2.x line is being split into separate backend and frontend components. The AGPL-3.0 licence also excludes the project logo, so branding reuse needs separate terms; beyond that, the licence, activity signal and deployment path are clear, and a self-hoster running a stable 1.x instance is the intended fit.