Bee v2.8.1 is a non-disruptive release focused on performance, data durability, and developer experience, with some operational cleanup. It was released on July 7th, 2026.
What Is Changing
This release brings faster chunk hashing, stronger crash safety for local storage, reduced blockchain RPC traffic, and a step toward browser-based uploads, alongside some operational cleanup.
Info
Bee v2.8.1 is non-disruptive for nodes already on the current network. It includes no breaking p2p protocol changes, and the new performance functionality is opt-in. Two things to note before upgrading:
- If you use
bee devfor local development, dev mode has been removed. See the alternatives below. - If you are still running a Bee v2.6.0 or older node, follow the upgrade path below.
Faster Chunk Hashing with SIMD
Bee v2.8.1 adds an optional, hardware-accelerated (SIMD) path for chunk hashing, a frequent and CPU-intensive operation. On supported hardware it noticeably lowers the CPU cost of hashing, which speeds up uploads and other hashing-heavy work. The SIMD acceleration relies on specialized x86-64 CPU instructions that are currently built for Linux amd64.
Tip
Linux x86-64 (amd64) operators can opt in by starting Bee with --use-simd-hashing (off by default).
Crash-Safe Local Storage
This release fixes a data-integrity issue that could affect a node interrupted mid-write (for example, by a crash or power loss while actively uploading). Under those conditions, a node could end up with corrupted local storage and, in some cases, serve invalid chunk data. Idle nodes were not affected.
Bee v2.8.1 closes the window that caused this and adds an automatic integrity check: after an unclean shutdown, the node now validates chunks against their content hashes during recovery and removes any that are corrupted, so it starts clean and avoids serving corrupted data. This recovery is automatic. No manual action or repair command is required. The change improves the real-world durability and reliability of data stored across the network.
Reduced Blockchain RPC Traffic
Bee nodes query their blockchain RPC endpoint constantly, which adds cost and rate-limit pressure for operators on paid or self-hosted RPC providers. Bee v2.8.1 substantially reduces how often a node makes those calls (in part by relying on the chain's average block time to estimate values locally between syncs), lowering RPC cost and load.
Tip
The block-number syncing interval defaults to 10, so operators who want to keep the default don't need to do anything.
To change it, set the block-sync-interval option using any of Bee's configuration methods (CLI flag, environment variable, or YAML config).
For example, in bee.yaml:
block-sync-interval: 10
The equivalent flag is --block-sync-interval and the environment variable is BEE_BLOCK_SYNC_INTERVAL.
- A higher value means fewer RPC calls, at the cost of a slightly staler block-number estimate.
1refreshes the block number as often as possible.0is not allowed; the node treats it as "no interval" and clamps it to1.
Client-Side Stamping for Browser Uploads
Bee v2.8.1 lets a client sign its own postage stamps and upload already-stamped chunks, rather than handing raw data to a node to stamp. This opens up new possibilities for applications built on Swarm:
- Browser-based uploads with the key in the browser. The signing key can stay client-side, so an app can upload to Swarm directly from the browser without entrusting its key to a node.
- Faster uploads through parallel stamping. Stamp signing can be spread across Web Workers, parallelizing the work to improve upload performance.
- Per-chunk batch selection. Different chunks can be stamped with different postage batches within the same upload.
Together with the AutoTLS and secure WebSocket (WSS) support from v2.7.0, this is another step toward running Bee directly in the browser.
Tip
For developers: the /chunks/stream (WebSocket) endpoint accepts pre-signed (client-stamped) chunks.
Omit the Swarm-Postage-Batch-Id header on the connection to enter per-chunk-stamp mode.
Then, for each chunk, send the stamp envelope bytes (113 bytes) first, followed by the chunk data (span + payload).
With the batch-id header set instead, each message is treated as raw chunk data.
Browsers, which can't set custom headers on a WebSocket connection, can pass the swarm-tag query parameter instead.
Dev Mode Has Been Removed
The bee dev command (and its devnode / start-dev internals) has been removed. Bee now supports only its three production runtime modes: light, full, and ultra-light. This completes the deprecation first announced with Bee v2.7.0.
Node operators are unaffected, as production nodes never ran in dev mode.
Tip
Developers who used bee dev for local development should switch to one of two options:
- Bee Factory: a one-command local Swarm development stack (multiple Bee nodes plus a local blockchain), ideal for fully local development and integration testing.
- The Sepolia testnet configuration: run a real Bee node against the public test network for realistic, pre-mainnet testing.