Rotki: A Self-Hosted Portfolio Tracker That Keeps Your Data Off Someone Else's Server

The Problem: Financial Data in Someone Else's Hands

Most portfolio tracking tools are closed-source SaaS platforms. You hand over exchange API keys, wallet addresses, and transaction history to a third party. Rotki addresses this by being a self-hosted application that keeps data encrypted and stored locally. The README states that it puts privacy first and gives users a self-sovereign alternative to cloud-based tracking. The target user is someone who wants to track balances across multiple platforms, blockchains, and exchanges without surrendering control of their financial data. This is not a tool for casual users who want a hosted dashboard; it is for people who are willing to run their own software and manage their own data.

How Rotki Works: Local Storage and Transaction Decoding

Rotki is a desktop application, not a web service. It runs on Windows, macOS, and Linux. The core mechanism is local data storage: all your portfolio information, transaction history, and accounting data reside on your machine. The README mentions transaction decoding, which turns raw blockchain transactions and exchange events into readable breakdowns. This is essential for accurate profit and loss reporting. Rotki also provides graphical insights and customizable accounting settings for PnL reports. The architecture is a Python backend with a Node.js frontend, as indicated by the required dependencies. The user imports addresses or exchange credentials, and rotki pulls balances and history from those sources, then processes and stores them locally. The exact data flow is not detailed in the README, but the emphasis on local encryption and self-hosting makes it clear that no data leaves your machine unless you choose to sync or export it.

Getting It Running: Binaries or Source Build

The README recommends downloading pre-packaged binaries for normal users. This is the simplest path, as it avoids dependency management. For developers, there is a build-from-source option. The requirements list Node.js, npm, Python 3.14, uv (the Python package manager), and Docker. This is a demanding set of prerequisites. Python 3.14 is a specific version, not a generic 'Python 3' requirement, so you cannot assume an older system Python will work. The build process likely involves setting up a virtual environment with uv, installing Python dependencies, and building the frontend with npm. The README does not give exact commands, so you must consult the build-from-source documentation. For most users, the packaged binaries are the only sensible route, because the source build requires a specific toolchain and Docker for some components.

A Genuine Limitation: The AGPL License Is a Real Constraint

Rotki is licensed under AGPL-3.0. This is a strong copyleft license. If you embed rotki in a proprietary product, redistribute it as part of a commercial offering, or offer it as a hosted or SaaS service, you trigger AGPL obligations. The README explicitly warns about this and offers a commercial license as an alternative. This is not a minor detail. For an individual self-hoster, the AGPL has little practical impact. For a company that wants to integrate rotki into a commercial product or offer it as a service, the license can be a dealbreaker. The commercial license is available, but it costs money and requires contacting the project. This is a significant limitation that any engineering team must evaluate before adoption. It is not a project you can casually fork and embed without understanding the legal implications.

Alternative Approaches: Closed-Source SaaS vs. Self-Hosted

The main alternative to rotki is a closed-source SaaS portfolio tracker, such as CoinTracking or Koinly. These services handle the hosting, updates, and security for you, but they require you to upload your financial data to their servers. The difference in approach is fundamental: rotki puts the burden of maintenance on you, but gives you data sovereignty. SaaS tools are easier to start with, but they create a privacy trade-off. Another alternative is a manual spreadsheet or a local database tool, which gives you full control but no automation. Rotki sits in the middle: it automates data collection and accounting, but keeps everything local. If your primary concern is convenience and you trust the SaaS provider, a hosted service is simpler. If your primary concern is privacy and control, rotki is the more aligned choice. The trade-off is maintenance effort versus data custody.

Maintenance and Upgrade Cost: Regular Releases, Self-Service

The repository shows a steady release cadence. Recent releases include v1.44.0, v1.43.2, and v1.43.1, with dates from May to August 2026. This indicates active development and regular updates. The changelog is available online, and the project has a contribution guide. For a self-hosted tool, the maintenance cost is on you. You must monitor releases, apply updates, and ensure your local data is backed up. The README does not mention any automatic update mechanism, so you should assume manual upgrades. The requirement for Python 3.14 and Node.js means that upgrading the system environment could break rotki if versions drift. The AGPL license also means that if you modify the source, you may need to release your changes, which adds a compliance burden. There is no managed service or enterprise support, so you are responsible for troubleshooting. The project has a Discord and GitHub discussions for community help, but that is not a substitute for in-house expertise.

What the README Does Not Tell You

The README is heavy on marketing language and light on technical specifics. It does not describe the actual data storage format, the encryption method, or how exchange integrations work. It does not mention performance characteristics for large portfolios. It does not list supported exchanges or blockchains. The 'Features' section is a bullet list without detail. This is a gap. If you are evaluating rotki for serious use, you need to read the full documentation, not just the README. The requirement for Python 3.14 is unusual, as many systems still run Python 3.10 or 3.11. This could be a barrier for developers who want to build from source. The README also does not clarify whether the packaged binaries include the Python runtime or require a separate installation. These unknowns mean that a proof-of-concept install is essential before committing to rotki. The project's active release schedule suggests it is not abandoned, but the documentation gaps are a real friction point.

Who Should Adopt Rotki and Who Should Not

Adopt rotki if you are a privacy-conscious individual or a small team that wants to manage crypto and financial portfolios without uploading data to a third party. You should be comfortable with self-hosting, manual updates, and the AGPL license. You should not adopt rotki if you need a turnkey solution with support, or if your organization cannot accept AGPL obligations for commercial or hosted use. Before adopting, verify that your operating system is supported by the pre-packaged binaries. Check that you can meet the Python 3.14 and Node.js requirements if you plan to build from source. Read the full documentation to confirm that rotki supports the specific exchanges and blockchains you use. The project is real and actively maintained, but it is not a zero-effort tool. The concrete next step is to download a pre-packaged binary for your OS, import a test wallet, and see if the transaction decoding and PnL reports match your accounting needs. That test will tell you more than any README.

Editorial conclusion

Adopt rotki if you want a self-hosted portfolio tracker that keeps your financial data on your own machine, and you are comfortable with the AGPL-3.0 license and a Python 3.14 environment. Do not adopt it if you need a zero-maintenance SaaS solution or if your organization cannot comply with AGPL obligations for hosted or embedded use. Before adopting, verify that your operating system is supported by the pre-packaged binaries, and confirm that your Python and Node.js versions match the requirements listed in the README. The project is actively maintained with regular releases, but you must be willing to handle your own backups and upgrades, as there is no managed service.

Official sources

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