rotki: a self-hosted crypto portfolio tracker that keeps your data local

The problem rotki solves, and who feels it

Most portfolio trackers are hosted services. You paste exchange API keys and wallet addresses into someone else's database and read your net worth back through their web interface. rotki takes the opposite position: the README describes it as an "opensource self-hosted portfolio management tool that puts privacy first", and says data is kept encrypted and stored locally. That single design decision drives everything else about the product, including its installation story.

The audience follows from that. rotki is for someone holding assets across several blockchains and exchanges who wants one balance view, readable transaction history and profit/loss figures, and who is unwilling to hand the underlying addresses and trades to a third party. It is also for people who need accounting output rather than a price ticker; the project description in pyproject.toml calls it an "Accounting, asset management and tax report helper for cryptocurrencies".

The cost of that position is real. A hosted tracker asks you to sign up. rotki asks you to install something, keep it updated and manage your own data file. The README's own feature list is ordinary: balances across platforms, historical charts, transaction decoding, PnL reports with configurable accounting settings. Nothing there is unique. What is unusual is where the data lives.

Architecture: Python core, Rust sidecars, a REST API in between

The repository is not a single-language project. The Python package lives in rotkehlchen/, the desktop interface in frontend/, and a Cargo workspace at the root builds two Rust binaries, colibri and starling, from colibri/ and crates/. The Dockerfile builds the frontend with Node, then the Rust workspace with cargo build --release --locked -p colibri -p starling, then a Python 3.14 stage. Three toolchains in one image is a fair description of the project's shape.

The Python side exposes a REST API. pyproject.toml lists flask, flask-cors, marshmallow and webargs, plus uvicorn, described in a comment as "the asyncio api server (uvicorn serving REST via the a2wsgi bridge + native /ws)". So the frontend is a client of a local HTTP and WebSocket API rather than a set of direct Python calls. That is what makes running rotki headless in a container plausible at all.

The dependency list also shows how much of the work is chain specific. web3 and eth-abi handle EVM chains, scalecodec and a pinned fork of py-polkadot-sdk handle Substrate chains, and bech32 appears for address encoding. Storage goes through rotki-pysqlcipher3 and rotki-sqlite, which are the project's own builds of those libraries. The pinning is aggressive throughout: web3==7.16.0, eth-typing==5.2.1, requests==2.33.1. Cargo.toml states the reason for the same habit on the Rust side, that an exact pin makes a dependency bump "a deliberate, reviewable diff rather than something that drifts in on the next lockfile refresh".

The practical consequence is that rotki's dependency graph is not something you casually upgrade. It is a deliberate, pinned graph, and the version of Python is pinned too: pyproject.toml requires exactly 3.14.*.

Installing rotki and getting a first portfolio view

The README recommends pre-packaged binaries over building from source, and links to the packaged binaries page in the documentation for Windows, macOS and Linux. That is the path most users should take. If you would rather run it in a container, the README links the rotki/rotki image on Docker Hub, and the repository ships a Dockerfile and a packaging/build-docker.sh script invoked by the docker-image target in the Makefile.

Building from source is a developer path, and the requirements section is explicit about what it needs: Node.js, npm, Python 3.14, uv and Docker. The Makefile confirms the toolchain split, with uv run pytest for the test targets. The lint target is worth reading before you send a patch, because it runs ruff, mypy, pyright and pylint in sequence, plus two project-specific checks.

uv run pytest -m asset_test rotkehlchen/tests

That target, test-assets, is the one the Makefile exposes for asset-related tests. The broader suite is ordinary pytest, so a plain uv run pytest rotkehlchen/tests is the obvious starting point once dependencies resolve.

For the container path, the image is published as rotki/rotki on Docker Hub. The README does not spell out the port or the volume layout, so read the Docker section of the documentation before writing a compose file rather than guessing at environment variables.

Inside the application, the README's quick start is short: follow the usage guide, configure settings, import your addresses, and start analysing. In practice the first meaningful step is adding one exchange or one address and checking that the decoded transaction history matches what you expect. If the decoding is wrong for an obscure protocol, you will see it there, before you have imported everything.

Where rotki fits badly

The clearest limitation is the one the project states itself: rotki is an application you run, not a service you visit. There is no hosted version from the maintainers described in the README. If your workflow is checking balances from a phone or a work laptop you do not control, a self-hosted desktop application is the wrong shape for it.

The second is coverage. Transaction decoding and balance tracking depend on integrations with specific chains and exchanges, and the README points to a separate integrations page rather than promising universal coverage. Anything not on that page is not tracked, and a portfolio view that silently omits a holding is worse than no view. Verify your chains and venues before you invest time in importing history.

The third is the accounting model. PnL reports are only as good as the settings behind them, and the README describes them as "customizable accounting settings", which means rotki does not impose one answer. Two users with identical transactions and different settings will get different numbers, and neither is necessarily wrong. If you need a report that matches a specific jurisdiction's rules exactly, treat rotki as a tool that produces a number you must still check, not as a filing.

Finally, there is the Python 3.14 requirement. It is exact, not a minimum, and it makes rotki a poor candidate for a shared machine where you cannot control the interpreter version. Packaged binaries avoid this; a source build does not.

rotki compared with Wealthfolio and hosted trackers

Wealthfolio comes up often in the same searches, and the two projects share the local-first premise. The difference visible here is scope and stack. rotki is a Python core with a REST API, a Rust workspace for sidecar binaries, and a separate frontend build; Wealthfolio is not described in the README or the repository files, so the honest comparison stops at the premise. Both ask you to run software locally instead of uploading data, and that is the decision that matters most.

Against hosted trackers the trade is sharper. A hosted service gives you a URL, an account and someone else's uptime, and it can add a new chain without you doing anything. rotki gives you control of the data and makes you responsible for updates, backups and the machine it runs on. It also means a bug in decoding is yours to notice. The upside is that no one can change the terms under which your transaction history is stored, because they never had it.

There is a middle ground worth naming: running the published container on a home server. That keeps data local while removing the desktop application from the equation, and the Dockerfile in the repository is clearly built for it, with a dedicated frontend build stage and a Rust stage that compiles both binaries in one cargo invocation. It is more work than a desktop install and less work than maintaining a source build.

Licence and the maintenance bill

rotki is distributed under AGPL-3.0, and the README says so directly. The Cargo workspace declares AGPL-3.0-only for the Rust crates. The README also states that if your intended use would trigger AGPL obligations, for example embedding rotki in a proprietary product, redistributing it as part of a commercial offering, or offering a hosted version, the company offers a commercial licence as an alternative, with a contact address for enquiries. That is a factual statement about the licensing options, not legal advice; if your use is close to those lines, talk to a lawyer and to the maintainers.

For individual users the licence is not a practical constraint. For anyone building a product on top of rotki, it is the first thing to resolve, before writing code.

The maintenance picture is healthier than the licence question is settled. The last push to the develop branch was on 2026-08-21, the same date as the v1.44.0 release, and the two releases before it landed on 2026-06-18 and 2026-05-18. That is a steady cadence, not a burst. The repository is not archived.

The upgrade cost is where the pinning shows. Python is pinned to 3.14.*, web3 is pinned to an exact version, and the Rust workspace pins tokio, serde, axum and the rest exactly. If you build from source you inherit that graph and the release cadence that moves it. If you use a packaged binary or the published image, the maintainers absorb that work and you absorb only the update schedule. The Makefile's clean target removes build/, dist/, rotkehlchen_py_dist/ and frontend build output, which tells you what a local build leaves behind.

Editorial conclusion

Adopt rotki if you want portfolio and PnL history on a machine you control and you are willing to run a desktop app or a Docker container. Do not adopt it if you need a zero-install web dashboard, or if AGPL-3.0 obligations conflict with how you plan to redistribute or host the software, since the README points to a commercial licence for those cases. Before committing, confirm on the download page that your platform has a packaged binary, and check whether the chains and exchanges you use appear on the integrations page.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes