Neuron: Zettelkasten notes and static publishing

Neuron's Markdown vault and publishing scope

Neuron addresses a specific combination of local note management and public publishing. It is intended for people who keep their source material as ordinary Markdown files in a directory and want those notes organized through Zettelkasten practices rather than trapped inside a proprietary application. The repository description also places web publishing within the same project, so the publishing output is tied to the same note collection instead of requiring a separate editorial system.

The repository identifies Neuron as an application for plain-text notes in Zettelkasten style. Its documented capabilities include hierarchical tagging, a linking syntax, and automatic generation of a static website. Those features make it more than a Markdown viewer: Neuron is intended to impose a note-oriented structure on files while also producing a browsable web representation. The README does not describe a hosted service, database account, or collaborative editing backend, so the local directory of Markdown files remains the clearest source-of-truth model.

This design is most relevant to individual researchers, writers, programmers, and knowledge workers who value plain-text ownership and accept the organization imposed by a command-line or editor-centered workflow. A team requiring simultaneous online editing, comment workflows, or account-based synchronization would need capabilities that the README does not document. Neuron's scope is therefore narrower and more file-oriented than a general collaborative knowledge platform.

From Markdown files to a generated Neuron site

The documented data flow starts with a directory of Markdown files. Neuron works with those files, applies its note-management model, and can generate a static website from the same collection. This arrangement keeps authoring close to ordinary text files while leaving web publication as a separate output generated from the notes.

The linking syntax is central to that model. Hierarchical tagging and links are presented as primary capabilities, which indicates that Neuron uses relationships and namespaces rather than relying only on folders or page titles. However, the README does not show the exact link syntax, tag grammar, template resolution rules, search index format, or static-site output path. Inventing examples for those details would risk producing notes that Neuron does not interpret as intended.

Optional editor integration is another part of the workflow. The README names Emacs, Vim, and VS Code among the supported or documented editor paths. It does not provide plugin names or configuration snippets, so the supported integration surface cannot be reduced to a specific extension command here. The practical conclusion is that Neuron can fit an existing text-editing setup, but users must consult its editor documentation for the exact setup.

The Haskell repository layout includes `neuron.cabal`, `src/`, `exe/`, `test/`, and Nix-related files such as `default.nix`, `shell.nix`, `flake.nix`, and `flake.lock`. Based on that layout, the implementation is packaged as a Haskell project with separate source, executable, test, and environment files. The README does not document an API for external services, so the repository evidence supports a local application model rather than a hosted API model.

Installing Neuron through the documented setup paths

The README does not contain installation commands, a package-manager invocation, or a source-build sequence. It directs users to the external Neuron installation page at `https://neuron.zettel.page/install` for local installation and first use. It also offers a separate path for people who primarily want to publish a Neuron site through GitHub Pages: the `neuron-template` repository at `https://github.com/srid/neuron-template`.

Because exact setup commands are absent from the README, this article does not substitute guessed flags or package names. A reader following the local path should first look for the current installation method on the Neuron install page, including its prerequisites and invocation syntax. A reader following the publishing path should inspect `neuron-template`, since the README positions that repository as the starting point for a GitHub Pages deployment rather than merely as a sample notebook.

The first meaningful use cannot be reproduced faithfully from the README because no sample Markdown source or command is included. The documentation establishes what that first result should contain: Neuron should be operating on a directory of Markdown files and able to generate a static site. Exact tag, link, configuration, and output-directory syntax must be taken from the linked install and usage documentation.

Neuron's successor boundary and maintenance history

The clearest project-specific warning is in the README itself: Neuron is being superseded by Emanote, with the successor repository identified as `https://github.com/srid/emanote`. That changes how maintenance signals should be interpreted. The repository is not archived, and its last push was on 2026-09-28, so the available status does not support calling it archived or abandoned. That fact alone, however, does not erase the explicit succession notice.

The listed releases provide a different signal. The most recent documented release is version `1.9.35.0`, dated 2021-08-11, following `1.0.1.0` from 2020-10-09 and `1.0.0.0` from 2020-10-08. The repository has received a later push, but the README does not explain whether that push includes a new release, targeted fixes, documentation work, or migration-related changes. A recent push is therefore relevant repository activity, not proof that Neuron has become the preferred foundation for a new installation.

For engineers, this creates a migration question that ordinary release cadence cannot answer. Existing users may reasonably assess whether their current setup still works and whether Emanote can consume the same Markdown directory. New users must weigh the convenience of a completed Neuron deployment against the stated successor relationship. The README does not document compatibility, migration commands, export procedures, or a formal end-of-life date, so none should be assumed.

AGPL-3.0 and source-build implications

Neuron is licensed under AGPL-3.0. The repository contains a `LICENSE` file, a `neuron.cabal` package definition, and several Nix configuration files. For an engineer deciding whether to depend on Neuron as software, this combination means that source availability, licensing, and the chosen installation method are separate questions.

The presence of `default.nix`, `shell.nix`, `flake.nix`, and `flake.lock` shows that the repository includes Nix-based development or environment files. The README also includes a Nix build badge, while source installation is delegated to `CONTRIBUTING.md`. It would be incorrect to infer an exact reproducible installation command without that file's contents. In particular, the README does not confirm which executable names, Nix packages, Haskell compiler versions, or system services are required.

The AGPL-3.0 designation may matter to organizations that modify Neuron and provide the modified program to others over a network. Determining whether a particular deployment triggers source-offering obligations requires reviewing the license and actual distribution model. This article does not provide legal advice. Operationally, an adopter should at least account for reviewing `LICENSE`, `neuron.cabal`, and the source-build instructions in `CONTRIBUTING.md` before modifying or redistributing the application.

Choosing between Neuron and a conventional static-site pipeline

The closest conceptual alternative is a conventional static-site generator fed by manually managed Markdown files. The distinction is that a general generator commonly treats content primarily as pages and site assets, while Neuron is specifically designed around Zettelkasten-style notes, hierarchical tags, and note linking. The README does not name or benchmark a particular static-site generator, so the comparison must remain architectural rather than product-specific.

Choose that conventional approach when the main requirement is a site whose information architecture is defined primarily by templates, front matter, and explicit site routes. Choose Neuron when the graph-like and hierarchical qualities of a Zettelkasten are central to note retrieval and publication. A further consideration is succession: Emanote is explicitly presented as Neuron's successor, while no corresponding successor is identified for a generic static-site pipeline.

Neuron is the wrong tool when plain files are merely one import format for a larger publishing platform. Its documented model begins with a directory of Markdown notes and centers their organization and generated site. It is also a poor fit where the requirement is a managed multi-user editor, since no such collaboration mechanism is documented in the README.

Editorial conclusion

Neuron fits users who want a directory of Markdown notes connected through Zettelkasten conventions and published through a generated website. It is a weaker choice for a new deployment when accepting a successor migration matters. Before adoption, verify the external installation and usage documentation, confirm that Neuron's current build works with your Haskell and Nix setup, and decide whether Neuron or Emanote is the appropriate long-term home for the note archive.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. srid/neuron on GitHub