cardano-node: the integration point where Cardano's three Haskell layers meet

An integration repository, described as one

The README is short enough to read in a minute, and the first paragraph tells you what this project is. The `cardano-node` repository is the point of integration of the ledger, consensus and networking layers, and it provides the `cardano-node` executable used to participate in the Cardano network. The three layers are separate repositories: `cardano-ledger`, `ouroboros-consensus` and `ouroboros-network`.

The README includes a dependency diagram, and reading it tells you more than the prose does. `cardano-node` depends on `cardano-api` and on `trace-dispatcher`. `cardano-api` in turn depends on `ouroboros-consensus`, `ouroboros-network` and `cardano-ledger`. `ouroboros-consensus` depends on both `ouroboros-network` and `cardano-ledger`, and `cardano-ledger` depends on `plutus`.

That last edge is the one with consequences. The ledger layer sitting on top of Plutus is why a node release note about faster Plutus script validation is a node release note. It is also why the repository is Haskell, licensed under Apache 2.0, with roughly 3,200 stars and 750 forks. The project is not archived and the last push is 2026-09-23.

The runbook is not in the repository

There is no install command in this README, and that is intentional rather than an omission. The instructions section points out to the Cardano Developer Portal for the process of getting a `cardano-node` executable, and points there again for the configuration and files required to run a node in one of the supported networks. Two separate portal pages, one for installing and one for running.

So if your goal is to get a node up, the GitHub repository is not where you start. It is where you go once you want to understand the internals or build from source. That division is normal for Cardano and probably sensible: node configuration changes with every hard fork, and a configuration reference that lived in the repository would go stale.

The repository does carry a `configuration/` directory at the root, and the Makefile has a target that generates tracing documentation from a mainnet configuration file, so the shipped configuration is real and consumed by tooling even though the human-facing instructions are hosted elsewhere.

Running from containers with a shared IPC volume

There is a `docker-compose.yml` at the repository root, and it shows something about the architecture that a single-container image would hide. Two services are defined, `cardano-node` and `cardano-submit-api`, and they communicate through a named volume called `node-ipc` mounted at `/ipc` in both, while the node database lives in its own `node-db` volume at `/data/db`.

  cardano-node:
    image: ghcr.io/intersectmbo/cardano-node:${CARDANO_NODE_VERSION:-latest}
    environment:
      - NETWORK=${NETWORK:-mainnet}

The submit-api service publishes port 8090, depends on the node, restarts on failure, and shares the same IPC volume. Both images default to `latest` and both read a `NETWORK` variable defaulting to `mainnet`, so pinning `CARDANO_NODE_VERSION` and `CARDANO_SUBMIT_API_VERSION` is the difference between a reproducible deployment and one that changes underneath you. Both services cap their json-file logging at 200k with ten files, which is a sensible default for a process whose log volume over a long sync would otherwise fill a disk.

Nix, Cabal and hlint are the build story

The root of the tree carries a full modern Haskell toolchain rather than a single build file. There is `cabal.project`, a `Makefile`, and a Nix layer consisting of `flake.nix`, `flake.lock`, `shell.nix`, `default.nix`, `nix.mk` and `release.nix`. The `Makefile` pulls in `nix.mk` and defines lint targets that shell out to Nix.

lint hlint: ## Run the CI version of hlint
	nix build --no-link '.#checks/hlint' --cores 0

The pattern is that the Makefile is the human interface and Nix is the actual environment, which means the CI version of hlint and your local version can differ deliberately. There are also targets for generating Haddock documentation, for regenerating trace schemas and validating them against a meta schema, and for checking that every schema override is applied and that generated schema files never change without a matching override sidecar. That last check is the kind of hygiene you rarely see in a project README, and it tells you the trace message schemas are treated as a compatibility surface.

Style tooling is configured in files rather than described in prose: `.hlint.yaml` and `.stylish-haskell.yaml` sit at the root, alongside `.herald.yml` for changelog management and a `STYLEGUIDE.md`.

The 11.1 line removes more than it adds

Three releases in eight weeks tell a consistent story. Version 11.1.0, published 2026-08-21, was a pre-release not yet recommended for mainnet. Versions 11.1.1 on 2026-09-08 and 11.1.2 on 2026-09-17 followed it, and all three share the same headline removals.

The legacy tracing system, named in the release notes as iohk-monitoring-framework, is completely removed. The new tracing system is now the only one included, and configurations still using legacy keys must be migrated, with a New Tracing Quick Start page and pull request 6580 documenting the removed keys. The V1 LedgerDB and the LMDB storage backend are also removed, with LMDB users required to switch storage backend. Ledger snapshots are now predictable and Mithril compatible, so they are comparable and shareable across nodes.

The additions are quieter: more efficient transaction forwarding between peers, mempool snapshots that stay fast as the mempool grows, quicker Plutus script validation, and initial network and consensus support for Peras, which is off by default behind the experimental `NodeToNodeV_16` protocol version. Version 11.1.2 optimises memory usage in timelock scripts and admits a slight increase against 11.0.1 while syncing, though far less than the 11.1.0 regression, plus a small increase while on tip that correlates with taking ledger snapshots. It also flags that `cardano-rpc` contains breaking changes from 11.0.

Using the packages as a library, and the rest of the tree

The README's only other substantive section is for developers who want to depend on these Haskell packages from another Haskell project. The instruction is to set up CHaP so the packages defined in this repository are available, and the generated API documentation is published on a dedicated webpage rather than in the repository.

The rest of the tree explains the scope of the project beyond the node itself. There is `cardano-submit-api`, which the compose file runs alongside the node, and `cardano-testnet` for local network work. `cardano-node-chairman` and `cardano-node-capi` are separate executable packages. `cardano-tracer` and `trace-forward/` cover the tracing stack that the 11.1 line made mandatory. `bench/` holds benchmarking material including the trace schema tooling. `plutus-example/` is there for the ledger's Plutus dependency. `ci/` and `ci-shell` cover continuous integration.

Governance files are thorough: `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `CODEOWNERS`, `SECURITY.md`, `STYLEGUIDE.md` and `RELEASE.md`. With 84 open issues against a repository this central, the issue tracker is the place to look for what the maintainers consider unresolved.

Editorial conclusion

The first thing to understand about cardano-node is that it is not a blockchain implementation, it is the place where three others are wired together, and the repository's short README is an accurate reflection of that role rather than a documentation failure. What the repo does give you is the dependency shape, the package names, the build and lint entry points, the container definition, and a release history that reads like a change log for production operations. The 11.1 line is a migration line: the legacy tracing framework is gone, the V1 LedgerDB and LMDB backend are gone, and snapshots are now Mithril compatible, so a configuration carried over from an older node will not simply start. Read the New Tracing Quick Start and the removed config key list before touching an existing deployment, then follow the Developer Portal for the actual install and run steps.

Frequently asked questions

Official sources

1. IntersectMBO/cardano-node on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases