Local tracking and optional sync are separate choices
Wealthfolio lets you evaluate local portfolio tracking before deciding whether to pay for brokerage connections. The README describes manual tracking and CSV import as free, with no account required. Wealthfolio Connect is an optional subscription for read-only brokerage sync across 30+ institutions and encrypted multi-device sync. Those are project claims; our run did not exercise either service.
The repository describes investment holdings, performance analytics, activities, goals, net worth, spending, and simulations. SQLite stores local financial data. Desktop downloads, iOS, and self-hosted Docker/web are documented, but our source run was not a compatibility test of those platforms.
For version context, the supplied v3.7.0 release notes specify macOS 12, iOS/iPadOS 16, Chrome/Edge 107, Firefox 104, and Safari 16 as minimums. That release is distinct from our measured checkout: the October run's build log identifies the frontend package as frontend@3.9.2. We did not test the v3.7.0 release binary or establish the latest available release.
What our October 3 source run establishes
Our stored run began on October 3, 2026, at commit 0deea7f312e577acb7416078967438f4423e4516, whose recorded commit date is October 1, 2026. No new execution was performed for this correction.
| Recorded step | Observation | Limit |
|---|---|---|
| Dependency installation | Exit 0 in 22.779 seconds, rounded to 23 seconds | Establishes dependency installation, not an installed or launched Wealthfolio application |
| Build | Exit 2 in 52.752 seconds, rounded to 53 seconds | The frontend build stopped at TypeScript errors |
| Test command | Exit 0 in 777.396 seconds, rounded to 777 seconds | Vitest reported passing results for this command, not every platform or financial workflow |
The dependency measurement recorded 1,181 dependencies and 644 MB. The install log separately said 1,180 packages were added. The checkout contained 6,855 files, approximately 673,053 source lines, and occupied 72.4 MB. Detection found 11 CI workflow files, Docker and Compose files, a tests directory, and workspaces. These measurements describe this checkout and environment, not application speed or typical storage requirements.
The recorded sandbox configuration lists 3 CPUs, 8 GB of memory, and image lab-node:22. The image name is not proof of the runtime version; the raw detector recorded nodeMajor 24. We cannot resolve the actual runtime from those fields alone.
The test output reported 329 passing files and 2,903 passing tests. The stored summary recorded zero failed and zero skipped tests. The command took 777.396 seconds end to end; Vitest's own duration line was 765.95 seconds. These timings have different scopes. The supplied record explicitly says exhaustive unique coverage was not verified through complete-log reconciliation.
There was no recorded advisory audit result. The record also does not demonstrate a desktop launch, installed-binary check, Rust test run, Docker deployment, broker connection, or reconciliation of a real portfolio. Passing this test command cannot establish financial accuracy.
A failed build needs a narrower conclusion
The build tail reports TS6305 errors because declaration outputs under packages/ui/dist had not been built from their source files. It also contains TS7006 implicit-any parameter errors and TS7031 implicit-any binding errors. pnpm stopped at the frontend workspace with exit code 2.
The current README includes pnpm build:types after dependency installation and directs contributors to repository-defined Node, pnpm, and Rust versions. The README captured at the measured commit did not include that type-build step in its installation sequence. This is useful setup context, but we did not rerun the current sequence and cannot say it resolves every reported error.
The supported conclusion is that this recorded build attempt failed in its environment. It does not establish that release downloads, Docker images, or the product as a whole are broken.
Self-hosting adds storage and access responsibilities
The README documents an Axum server for web mode alongside the frontend. Its configuration requires a 32-byte secret through WF_SECRET_KEY or a key file, supports password authentication using an Argon2id hash, and requires explicit CORS origins when authentication is enabled. OIDC has additional issuer, client, redirect, and access-policy settings.
The supplied Docker guide, marked updated October 26, 2026, documents persistent storage under /data and says to back up that volume together with the matching WF_SECRET_KEY. Keep the key protected separately from the encrypted data. For an HTTPS reverse proxy, the README documents forwarding X-Forwarded-Proto: https or explicitly configuring secure cookies.
These are documented deployment requirements, not configurations we verified. Before using a self-hosted instance for household records, test backup restoration with a separate copy and confirm that your access configuration works as intended.
The add-on SDK is another reason to inspect permissions. The README describes access to accounts, holdings, activities, and market data, with declared permissions and user consent. The v3.7.0 release notes describe a rebuilt Blob-based sandbox and intentionally unavailable direct networking, remote CSS imports, workers, service workers, and popups. These are documented controls, not an independent security assessment. Review the access an add-on requests before giving it financial data.
Read issue reports with their versions and follow-ups
The supplied issues support checking representative data, but they do not establish that every reported symptom persists at our measured commit.
Issue 303 began with performance-chart timeframe reports on older versions. A June 2026 comment about v3.5.2 specifically says the metrics were correct while the ALL graph reverted to a one-year view. Describing the entire thread as proof of incorrect return calculations would erase that distinction.
Issue 1015 reports sell-first option positions producing phantom long holdings. Its July 11 follow-up includes a user saying that restarting the container and refreshing the browser exposed the open/close toggle on v3.6.1. That follow-up does not prove every option-accounting case is fixed, but the original report alone does not prove the current implementation lacks short-option support.
Issue 674 includes a contributor's March 11 explanation that consolidated cash can change when foreign-exchange rates change, describing that behavior as intended by the backend design. Later comments report other cash symptoms. The thread therefore cannot be summarized as one confirmed calculation defect.
A useful evaluation is to import a small, representative history into a separate profile and compare holdings, per-currency cash, returns, and closed positions with statements. Our run did not perform that reconciliation.
Alternatives depend on the workflow you want
Ghostfolio describes a web application for stocks, ETFs, and cryptocurrencies, with official container images and self-hosting instructions. Its documented backend uses PostgreSQL and Redis. Consider it when you want that browser-based deployment model and can operate those services.
Portfolio Performance describes tracking and evaluating portfolio performance across stocks, cryptocurrencies, and other assets. Consider it when that investment-performance focus matches your needs. The supplied extract does not support claiming that its calculations are more accurate than Wealthfolio's.
How to read the scores
These are editorial evidence ratings, not benchmark results. On this five-point scale, 1 means major documented obstacles, 2 means substantial limitations, 3 means useful documented capability with material validation gaps, 4 means broad supporting evidence with narrower gaps, and 5 requires strong direct validation of the criterion. Missing evidence does not by itself prove poor quality.
Setup receives 3 because deployment paths are documented and dependencies installed, but our build failed and no application launch was demonstrated. Documentation receives 4 for concrete source, authentication, storage, Docker, and add-on instructions, with the build sequence unverified here. Community receives 3 because the supplied release credits multiple contributors and issue threads contain maintainer responses, while adoption and support responsiveness were not measured. Maturity receives 3 because the project documents several deployment modes and release work, but our run does not establish packaging reliability or financial correctness.