akash-network/node: one Go binary that is a blockchain node and a marketplace client

Akash turns compute rental into an on-chain order

Akash is described as a decentralised cloud computing marketplace that connects two sides: tenants who need computing resources, and providers who have capacity to lease. The interesting part is that the negotiation itself lives on a blockchain rather than in a control plane owned by one company. A deployment order, its price and its settlement become chain state.

That design targets a specific reader. If you want to rent a GPU for a batch job, the conventional route is a contract with a hyperscaler, and the practical alternatives are self-hosting capacity you already own or accepting that provider. Akash inserts a third option, an open market where capacity is listed and claimed under on-chain terms. The intended users are providers who want to sell idle capacity and tenants who want to bypass a single vendor, plus validators who secure the chain that records the deals.

The scope is narrow in an important way. This is a marketplace for containerised workloads, not a general IaaS replacement. A tenant supplies a target workload definition, the provider supplies the machine, and the network coordinates the lease. Anything that needs a long term physical affinity, a specific network fabric, or a bespoke hardware appliance is outside what this arrangement addresses.

One binary carries both the chain and the client

Akash Suite is the reference implementation of the Akash protocol, and the documentation calls it a prototype focused on the distributed marketplace functionality. The implementation choice that matters for an operator is packaging: the Suite is composed of one binary, `akash`.

That binary contains a Tendermint powered blockchain node that implements the decentralised exchange, and it also contains client functionality for accessing the exchange and the network data in general. A single artefact therefore plays two roles. It is the chain participant that takes part in consensus and stores state, and it is the command line client that a tenant or provider uses to place orders, bid, and query the chain.

The single binary design is convenient for distributing and for containerising the software, and it keeps the client and node versions in lockstep. It also means there is no separate lightweight client for reading chain data, so any workload that only needs to query state still pulls in the full node. The dependency list in `go.mod` explains the weight: the module `pkg.akt.dev/node/v2` requires the Cosmos SDK at v0.53.6, CometBFT at v0.38.21, `github.com/CosmWasm/wasmd` at v0.61.7 with `wasmvm/v3` at v3.0.2, and IBC Go at v10.5.0, so the chain is a Cosmos SDK application with CosmWasm contracts and IBC enabled rather than a purpose built chain.

Installing the release binary with Homebrew or the install script

The quickest path is a prebuilt release binary. Two routes are documented, one through Homebrew and one through GoDownloader. The Homebrew route taps the project tap and installs the formula:

$ brew tap akash-network/tap
$ brew install akash

The script route pipes a remote installer into a shell, and installs the latest release:

$ curl -sSfL https://raw.githubusercontent.com/akash-network/node/main/install.sh | sh

The same script takes a version argument, which is what you want if you need to pin a specific release rather than track the newest tag:

$ curl -sSfL https://raw.githubusercontent.com/akash-network/node/main/install | sh -s -- v0.22.0

Two details deserve attention. First, the versioned example in the documentation names v0.22.0 while the current release tags are in the v2 series, so the pinned example is stale and you should substitute a tag that exists. Second, piping a script from a branch URL into a shell is convenient but it executes whatever the `main` branch currently holds, so a version pinned install for a production machine is the safer of the two forms.

Binary releases are published for Darwin and Linux on both amd64 and arm64, so an Apple Silicon laptop and an ARM server are both supported targets.

Building from source needs a C toolchain alongside Go

The build is Makefile driven, and the default target compiles the `akash` executable into `.cache/bin`. The comment in the Makefile notes that `akash` is the default target, so a bare `make` is equivalent:

make akash # akash is set as default target thus `make` is equal to `make akash`

The compiled binary in `.cache/bin` takes precedence over a system wide installed `akash` inside the repository, which is convenient for local work but also means you can be running a different build than the one on your PATH without noticing.

The toolchain requirements are wider than a pure Go project implies. Development and testing target Go 1.21.0 or later, and building requires a working Go installation, a properly set `GOPATH`, and `$GOPATH/bin` present in `$PATH`. Beyond that, a C or C++ compiler is required, gcc or clang, because there are C dependencies in use, libusb and libhid. Those two libraries are why hardware wallet and USB device support is in scope at all, and they are the reason a container image that only installs Go will fail at the cgo stage. The Makefile also carries a set of build tags, ledger and hidraw among them, and a database backend that defaults to `goleveldb` with `cleveldb` and `rocksdb` selectable through build options.

main carries features, mainnet/main carries the stable build

The branching policy is simple enough to matter for deployment. The `main` branch contains new features and is under active development, while `mainnet/main` holds the current stable release. Release numbering follows from that split: stable releases carry even minor numbers and are cut from `mainnet/main`, unstable releases carry odd minor numbers and are cut from `main`.

The recent tag list shows how that maps onto reality. v2.1.2 was published on 2026-09-24, v2.1.1 on 2026-07-24, and v2.2.0-a0 on 2026-07-14. The alpha suffix marks v2.2.0-a0 as a pre-release, while the v2.1.x tags carry no such suffix. The last push to the repository was on 2026-10-06, so the code is moving and the tags are recent enough to reason about.

The module path is `pkg.akt.dev/node/v2` and the `go.mod` file contains a `retract v2.0.0` directive, which tells the Go tool that a specific release in the v2 line is withdrawn and should not be selected. That is a small signal with a large consequence for automation: a dependency resolver or a script that picks the newest matching tag can land on a version the maintainers consider invalid. Pin explicitly, and read the `retract` directive before you let a tool choose.

An operator running a provider or validator therefore has two reasonable choices, and the choice is not cosmetic. Track `main` if you want the newest protocol behaviour and accept that you are running unreleased code, or track a stable tag and accept that protocol changes arrive later.

Three local environments, from an empty node to a Kubernetes cluster

For development, the project ships three thin integration testing environments under `_run`, and the difference between them is the level of realism you need.

The `lite` environment is a single node running locally with no workloads, which is enough to exercise chain start, transaction submission and client commands without any provider in the picture. The `single` environment adds a provider and runs the workloads inside a virtual machine, so a deployment is actually scheduled and executed. The `kube` environment runs the same node and provider pair inside Kubernetes, which is the closest match to a real deployment topology and therefore the one to use when you are testing provider behaviour rather than chain behaviour.

The stated purpose of the thin environments is to simplify development and testing. That is a deliberate design choice with a cost. A thin harness that starts fast and covers the common paths will not reproduce the operational problems of a full cluster, such as image pull behaviour under load, persistent volume handling, or scheduling across nodes with heterogeneous accelerators. Treat these as development tools. Before you trust a deployment in production, run it against a Kubernetes environment that resembles your own, and check the `_docs/development-environment.md` guide, which the repository points to for setting up a local development environment.

A Go chain with a Rust contract workspace alongside it

The repository layout shows a codebase with two toolchains in play. Most of the tree is Go: `app/`, `cmd/`, `client/`, `x/` for the chain modules, `pubsub/`, `upgrades/` for chain upgrade handling, `docgen/`, `tests/` and `testutil/`. Alongside it sits a Rust workspace, declared in `Cargo.toml`, with members `contracts/wormhole`, `contracts/pyth`, `contracts/pyth_vaa` and `contracts/pyth_pro`. The Rust side pins a rust version of 1.86.0 and builds with LTO, a single codegen unit, overflow checks enabled and panics set to abort.

The Go module pulls in `github.com/CosmWasm/wasmd` and `wasmvm/v3`, which is how CosmWasm contracts execute inside the chain, and the contracts in that Rust workspace are evidently the pieces being compiled to that runtime. The presence of a wormhole contract alongside Pyth price feed contracts is a strong hint about the intended use: contracts that consume external price data and move value across chains.

This split has a maintenance consequence that is easy to miss. The Go module and the Rust workspace version independently, the Cargo workspace carries its own `0.0.1` version, and the build targets are wired through the Makefile. A release therefore has to keep a Go binary and one or more compiled contract artefacts consistent, and a mismatch between the contract version and the wasmvm version in the chain is a class of failure that only appears at deployment time. The repository does not document that release procedure in the root README, so confirm it with the maintainers before shipping a contract set of your own.

Where the marketplace model stops being the right answer

There are workloads this design serves poorly, and the trade-offs are worth stating plainly rather than as a general caution.

The first is trust in physical locality. A tenant whose jobs are sensitive to data residency, to a specific network segment, or to latency against hardware it cannot see in a listing will find that a marketplace optimised for price and capacity discovery is solving a different problem. The second is operational ownership. Running a provider means running Kubernetes, managing images, handling accelerator hardware and absorbing the cost of running idle capacity that does not get leased. A marketplace shifts the rental cost, it does not remove the infrastructure cost from the provider.

The third is the one that catches new adopters. The documentation itself describes Akash Suite as a prototype focused on the distributed marketplace functionality, and a prototype deployed as a production dependency carries different expectations around upgrade paths, breaking changes and support than a mature chain does. The `main` branch is where new features land and where unstable, odd minor releases are cut, so tracking it in production means accepting unreleased behaviour on your own schedule.

Compared with running containers on infrastructure you already control, the Akash route trades direct operational control for an open market and on-chain settlement. Compared with a hosted IaaS contract, it trades a predictable invoice for price discovery across independent providers. Neither comparison is free, and the choice depends on whether your constraint is cost, control, or trust.

Editorial conclusion

Adopt this repository if you intend to run a node, a provider or a validator on the Akash network, and if you can accept that the client and the chain share one binary and that a source build needs both Go and a C compiler. Do not adopt it as a general purpose compute SDK, as a single tenant application runtime, or as a stable release branch, because `main` is where new features land. Verify three things before committing: that the tagged version you install matches the chain you intend to join, whether the `goleveldb` default database backend fits your deployment, and how the Rust contract workspace under `contracts/` is versioned against the Go module, since the two toolchains move separately.

Frequently asked questions

Official sources

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