romanz/electrs: A Private Bitcoin Electrum Server for Small Deployments

Why romanz/electrs Exists for Bitcoin Wallet Operators

romanz/electrs addresses a specific privacy and infrastructure problem: an Electrum wallet normally needs an Electrum server to answer balance and transaction-history queries. A self-hosted deployment can keep those queries on infrastructure controlled by the operator, so wallet addresses and balances do not need to be disclosed to an external server. The intended audience is an individual Bitcoin user, family, or small group that already operates, or is prepared to operate, a local Bitcoin full node.

The project is not a standalone blockchain node. Its README says it indexes the Bitcoin blockchain while relying on a local full node for transaction retrieval. It does not require `txindex` in Bitcoin Core, which can reduce the indexing burden placed on the full node. The resulting Electrum index supports fast queries for a given wallet, including balance and transaction-history requests.

The deployment boundary is unusually important. romanz/electrs describes itself as optimized for personal or small-scale use by family and friends. It says that public operation is a bad idea because it exposes the operator to denial-of-service attacks and potentially other attacks. The README points operators seeking a public server to the Blockstream fork of electrs, which it says is better optimized for that use at the cost of significantly greater resource consumption. That distinction should be resolved before installation, not after an index has already been built.

How electrs Connects Bitcoin Core to Electrum Requests

The documented architecture has three principal parts. Bitcoin Core supplies blockchain and transaction data. electrs processes that data into a persistent index. Electrum clients then query the resulting server through Electrum protocol v1.4.

The index covers transaction inputs and outputs. That structure lets electrs answer balance queries without asking the local node to recompute a wallet's complete history for every request. According to the README, it also maintains a mempool tracker intended to improve fee estimation. The README describes faster initial Bitcoin synchronization and low index storage overhead, while reporting that CPU and memory use are lower after initial indexing. Its example timing and storage figures are historical estimates from August 2023, not a guarantee for a new machine.

Persistence is handled through one RocksDB database. The project lists `rust-rocksdb` and says that the single database provides consistency and crash recovery. A separate schema document is linked as the authority for the index structure, so operators planning restoration, migration, or manual inspection need to consult `doc/schema.md`. The repository also includes `doc/usage.md`, `doc/config.md`, and `doc/monitoring.md`, indicating that startup configuration and operational inspection are separate concerns from index construction.

Building electrs 0.12.0 with Cargo

The repository's `Dockerfile` shows a source build through Cargo. It explicitly warns that the file is for demonstration and may not be suitable for production, and it tells unfamiliar Docker users to avoid it. The build stage installs native build prerequisites, copies the repository into `/build/electrs`, and points Cargo at the system RocksDB installation.

Inside the Docker build environment, the confirmed install command is:

FROM debian:trixie-slim AS base
RUN apt-get update -qqy
RUN apt-get install -qqy librocksdb-dev curl

The result is an `electrs` executable placed at `/usr/bin/electrs`. The README links to `doc/install.md` for source installation. It would be wrong to substitute guessed flags or a guessed configuration path.

The build stage shown in `Dockerfile` installs the required build context before compiling the crate:

FROM base AS electrs-build
RUN apt-get install -qqy cargo build-essential libclang-dev
WORKDIR /build/electrs
COPY . .
ENV ROCKSDB_INCLUDE_DIR=/usr/include
ENV ROCKSDB_LIB_DIR=/usr/lib
RUN cargo install --locked --path .

The `--locked` option makes Cargo use the dependency versions recorded in `Cargo.lock`. After a successful build, the image copies `/root/.cargo/bin/electrs` into `/usr/bin/electrs`. A first operational use still requires Bitcoin Core and a completed configuration based on `doc/config.md`; the README does not give enough detail to invent a startup command, network address, RPC setting, or data directory.

RocksDB Index Storage and Full Node Requirements

Storage planning is part of the adoption decision. The README characterizes index storage as roughly 10 percent overhead in the context of Bitcoin data and says the server relies on the local full node rather than duplicating every transaction in its own index. That is an approximate project claim, not a capacity formula. Block data growth, chain configuration, RocksDB behavior, and filesystem requirements can change what an individual deployment consumes.

The database also affects operational work. Because electrs uses one RocksDB database for its index, a defect in that database may affect startup and recovery as a unit. The README says this arrangement supports consistency and crash recovery, but it does not provide backup instructions or a rollback procedure. Operators should therefore treat `doc/schema.md` and the index location configured through `doc/config.md` as project-specific files to inspect before committing storage or migration procedures.

Bitcoin Core remains a dependency. electrs needs a local full node for transaction retrieval, even though `txindex` is unnecessary. This division of work can be attractive to a user who already runs a node, but it means electrs is not a lightweight replacement for every part of a Bitcoin node. A user with no existing full node must account for operating that node, its RPC connection, and whatever policy restrictions or resource limits are configured there.

Why electrs Is Not the Right Public Electrum Server

The strongest limitation is explicit: the project says it is optimized for personal or small-scale use and warns against public exposure. The stated risk is denial of service, with possible additional attacks. Nothing in the README suggests that this warning is merely about resource consumption. It is a deployment-scope warning.

The listed resource characteristics therefore should not be interpreted as public-service capacity. Low CPU and memory use after initial indexing can be useful for a household deployment, but public clients can generate a different workload. The README gives no request limits, authentication model, rate limits, horizontal scaling instructions, or public hardening procedure. `SECURITY.md` exists in the repository.

Bitcoin-only support is another hard boundary. The README states that altcoins are unsupported and that Bitcoin code forks that relax consensus rules through hard forks are also unsupported. This excludes an operator who needs the same Electrum server for another chain or expects compatibility with a non-consensus-compatible Bitcoin fork.

A real alternative exists for the public case. The README identifies the Blockstream fork of electrs and states that it is better optimized for public use, although it consumes significantly more resources. The choice is therefore between electrs's lower-resource personal deployment and a fork designed around a heavier public-service profile. That is an architectural difference, not merely a brand choice.

Release History, License, and Upgrade Work for electrs

The repository is not archived, and its last push was on 2026-10-13. Recent releases include v0.12.0 on 2026-09-13, v0.11.1 on 2026-02-22, and v0.11.0 on 2025-11-17. The current `Cargo.toml` identifies the crate as `electrs` version `0.12.0`, requires Rust `1.85.0`, and uses edition 2021. These facts help an adopter determine whether its toolchain matches the checked-out source.

Upgrade planning needs more care than checking the latest tag. The README singles out `doc/upgrading.md` as containing important changes from older versions, and `RELEASE-NOTES.md` is also present. Since electrs stores a versioned RocksDB index, a binary upgrade may have database implications, but the repository does not state whether schema changes occur between v0.11.1 and v0.12.0. It would be unsafe to promise either a seamless upgrade or a destructive migration.

The crate declares the MIT license, and the repository includes a `LICENSE` file. That declaration permits use and modification under the license's terms, subject to its actual text and applicable law. This review does not interpret licensing beyond the declared identifier. The README says the project logo was provided by Dominik Průša under the MIT license and is based on the Electrum and Rust language logos.

Editorial conclusion

romanz/electrs is suitable for an operator who wants Electrum wallets to query a locally indexed Bitcoin blockchain without depending on an external Electrum server. It is unsuitable for a public service because the README warns about denial-of-service and other attacks. Before adoption, verify that the local Bitcoin node can supply the required transaction data, that RocksDB storage meets the operator's capacity needs, and that the deployment remains within the documented personal or small-scale boundary.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. romanz/electrs on GitHub