Holochain Core Development and Installation Boundaries

Holochain's peer-to-peer application boundary

Holochain addresses the development of peer-to-peer applications in which application behavior and data handling are distributed across participating nodes rather than centered in one conventional application server. The repository describes its goal as an open-source framework with high levels of security, reliability, and performance, but it does not provide application-specific templates or an AppStore runtime.

The repository is aimed at application developers who need Holochain's core implementation. It is also relevant to Rust contributors because the workspace contains components for conductors, peer-to-peer networking, state, storage, WebSockets, tracing, metrics, keystores, client access, and developer utilities. The intended end user who merely wants to install Holochain and run apps from its AppStore is explicitly outside the scope of this source tree.

That boundary matters when evaluating the repository. A successful application deployment does not follow from cloning and building these crates alone. The README does not define a complete application template, deployment topology, application packaging workflow, or a short hello-world sequence for app developers. It instead separates core development from the distribution path provided by Holochain Launcher. This makes the repository a framework codebase, not a packaged desktop application.

Workspace structure across Holochain Rust crates

The root Cargo.toml defines a Rust workspace with multiple crates under crates/. Their names expose the principal subsystem boundaries without requiring claims about undocumented runtime behavior. The holochain crate sits alongside holochain_p2p, holochain_state, holochain_state_types, and holochain_data, which separate the main implementation from peer connectivity, state management, state representations, and data concerns.

The surrounding workspace reflects several distinct access and operational paths. holochain_conductor_api and holochain_conductor_config concern conductor APIs and configuration. holochain_websocket provides a WebSocket-related component, while holochain_keystore handles key storage responsibilities reflected by its name. holochain_trace and holochain_metrics provide tracing and metrics components. The client, hc_client, hc, hc_bundle, hc_sandbox, and holochain_terminal crates indicate client libraries, command-line tooling, bundles, sandbox support, and terminal-facing functionality.

Build configuration is itself substantial. The root file selects Cargo resolver version 2, defines debug and release profiles, enables link-time optimization for release builds, and declares workspace lint groups. It also lists mutually considered build paths for wasmer-sys-cranelift and wasmer-wasmi in the Makefile. The repository has rust-toolchain.toml, Cargo.lock, release.toml, scripts, nix directories, and extensive CI-related configuration. Based on this layout, adopting Holochain means integrating with a multi-crate Rust workspace rather than adding one self-contained package.

Build, test, and feature selection for core developers

The Makefile exposes the repository's principal developer workflows. Its default target builds and tests the workspace against both wasmer-sys-cranelift and wasmer-wasmi. That dual path is significant because these are mutually exclusive features named in the Makefile, and choosing only one would omit one of the documented validation paths. The default also includes slow_tests, build_wasms, and encryption through DEFAULT_FEATURES.

For contributors, the documented static checks are concrete and can be run through the following target:

The Makefile provides a `static-all` target for these checks.

According to the Makefile, that target runs formatting, TOML formatting checks, Clippy for default and unstable feature sets, and documentation checks. Its individual operations include these exact commands:

cargo fmt --check

The TOML check installs a pinned formatter before checking root and crate manifests:

cargo install [email protected] --locked

This command is not merely a convenience example. The Makefile explains that `--locked` prevents an unlocked resolution from selecting a newer semver-compatible dependency that fails to compile with the project toolchain. The formatting check then targets root TOML files and files beneath crates. This gives contributors a specific first validation step after code changes, although the README does not provide a minimal build command with installation prerequisites.

Initial Beta status and hardening constraints

The README labels the code as an initial Beta release and says it is ready for limited production use. It also says security reviews and hardening of network protocols are still in progress. Those statements define the principal adoption constraint more clearly than the repository description does. A production team should not read the project description alone as evidence that all network behavior has completed review.

The repository is not archived, and the last push was on 2026-10-15. Release activity is also visible in the release list: holochain-0.7.1 appeared on 2026-10-14, followed by holochain-0.8.0-dev.11 on 2026-10-12. This indicates recent code and release work, but it does not remove the README's Beta designation or turn network hardening into a completed step.

A second constraint is operational maturity. The Makefile includes slow_tests, build_wasms, encryption, and several unstable feature sets. This indicates a broad validation surface and a separation between default and unstable capabilities. The exact compatibility matrix for a particular application, operating system, WebAssembly target, and Holochain release is not documented in the repository documentation. The README is silent about rollback procedures and production support boundaries. Those omissions should be checked against project documentation before a deployment decision.

Holochain Launcher as the end-user alternative

Holochain Launcher is the practical alternative for someone whose goal is to install Holochain and operate applications from its AppStore. The README gives Launcher a different role: it distributes the runtime intended for end users, while this repository supplies core libraries for application development and contribution. Launcher releases are identified as available for Linux, Mac, and Windows.

This is a difference in operating model rather than a competing implementation of the same Rust workspace. Choosing Launcher avoids requiring the reader to compile the core crates merely to run AppStore applications. Choosing this repository is necessary when developing Holochain itself, contributing changes, or integrating directly against its libraries. Neither choice should be presented as a way to avoid application development: the README only establishes the package boundary.

For a first real use, the documentation provides no application example that can be copied and executed. It directs application developers to the Holochain developer portal for installation and directs AppStore users to the latest appropriate Launcher release. Consequently, no invented cargo command or sample app should be substituted here. The verifiable first action is to follow the installation guidance at developer.holochain.org/install for framework development, or obtain Launcher when the requirement is simply running Holochain applications.

CAL 1.0 and the cost of tracking a Rust workspace

The repository identifies CAL 1.0 as its licence and links to the cryptographic-autonomy-license project. GitHub categorizes the licence as custom, so adopters need to read the repository's LICENSE file rather than assume a standard permissive or copyleft licence. The README states that the program can be redistributed or modified under that licence and includes the project's warranty disclaimer. This is a factual summary, not legal advice or a substitute for the licence text.

Upgrade and maintenance work is most likely to be nontrivial for teams integrating the core crates. Cargo.lock records dependency resolution for the workspace, the Makefile validates two WebAssembly build configurations, and the project includes multiple command and service crates. Changes to Holochain releases can therefore affect dependencies, feature selection, generated bindings, documentation, and application-facing APIs. The repository provides RELEASE.md, CHANGELOG.md, release tooling, and Nix-related files, but the README does not give a short upgrade procedure for downstream applications.

Contributors also face a broad local validation policy. Formatting, TOML formatting, Clippy checks, documentation checks, WebAssembly generation, tests, and unstable feature variants are represented in the build files. The command surface is therefore more involved than a typical single-binary project. Teams that lack Rust build capacity or cannot support two WebAssembly backends should treat that operational burden as part of adoption cost, rather than focusing only on the source repository's open-source status.

Editorial conclusion

Application teams evaluating Holochain should adopt this repository when they intend to build against its Rust core libraries and can tolerate initial Beta software, pending security reviews, and network hardening. Developers seeking an installer for AppStore applications should use Holochain Launcher instead. Before adoption, verify the exact release, custom CAL 1.0 licence terms, required Rust and WebAssembly build environment, and the security review work still outstanding.

Frequently asked questions

Official sources

1. holochain/holochain on GitHub
2. Issues
3. Project website
4. README
5. Releases