Wealthfolio V36 Released The Local-First Investment Tracker Is Now A Full Personal Finance App Net Worth Spending Goals Fire Simulations Now With Sso

Wealthfolio V36 Released – The Local‑First Investment Tracker Is Now a Full Personal Finance App with Net Worth, Spending, Goals, FIRE Simulations and SSO

INTRODUCTION

If you have ever felt the friction of juggling multiple spreadsheets, cloud‑based budgeting SaaS tools, and ad‑hoc scripts to keep tabs on investments, net‑worth trends, and retirement projections, you are not alone. The homelab community has long relied on locally hosted solutions to retain data sovereignty, reduce latency, and avoid vendor lock‑in. The recent Wealthfolio V36 release takes this paradigm a step further by turning a modest investment tracker into a full‑featured personal finance application that still respects the local‑first philosophy.

For DevOps engineers and sysadmins who manage homelab stacks, the implications are clear: a self‑hosted finance app that supports SSO / OIDC authentication, FIRE (Financial Independence, Retire Early) simulations, and real‑time net‑worth visualisation can be integrated into existing infrastructure with the same rigor applied to any production service. This article will walk you through the technical underpinnings of Wealthfolio V36, outline the prerequisites for a robust deployment, and provide a step‑by‑step guide to installing, configuring, and maintaining the service in a self‑hosted environment.

By the end of this guide you will understand:

• How Wealthfolio V36 evolved from a simple investment tracker to a comprehensive finance dashboard.
• The architectural choices that make it suitable for self‑hosted, high‑availability setups.
• The exact commands and configuration snippets needed to run it behind a reverse proxy, with Docker, and with optional Kubernetes manifests.
• Security hardening techniques, including OIDC integration, secret management, and network segmentation.
• Operational best practices for backups, monitoring, and scaling.

All of this is presented with a focus on infrastructure management, system administration, and automation, making it directly relevant to the readership of **.

---

UNDERSTANDING THE TOPIC

What Is Wealthfolio V36?

Wealthfolio is an open‑source, local‑first project that began as a lightweight investment tracker. The V36 release marks a milestone: the codebase now ships with modules for

• Net‑worth aggregation across accounts, crypto wallets, and physical assets.
• Spending categorisation driven by transaction imports from CSV, OFX, or direct bank feeds.
• Goal management, allowing users to define savings targets, debt payoff timelines, and custom milestones.
• FIRE simulations that model retirement timelines based on varying savings rates, investment returns, and inflation assumptions.
• SSO / OIDC authentication, enabling single‑sign‑on with identity providers such as Keycloak, Auth0, or any OpenID Connect‑compatible service.

All of these features are packaged in a Docker‑centric distribution, making it straightforward to embed within a homelab stack that already runs services like Traefik, Portainer, or a self‑hosted GitLab Runner.

Historical Context

The project’s early commits (circa 2020) focused on a simple SQLite‑backed UI for tracking stock positions. Community contributions added CSV import support, a basic REST API, and a modest front‑end built with Vue.js. By early 2023, the repository had crossed 8 k stars on GitHub, signalling growing interest from the self‑hosted finance niche.

The V36 release introduced a modular architecture that separates concerns into distinct Docker services:

• wealthfolio-api – a Flask‑based backend exposing CRUD endpoints for assets, transactions, and goals.
• wealthfolio-web – a Vue SPA that communicates with the API via a unified /api namespace.
• wealthfolio-db – a PostgreSQL instance that persists all relational data.
• wealthfolio-auth – an optional OIDC sidecar that handles authentication and token exchange.

This separation aligns with modern DevOps practices, allowing each component to be versioned, scaled, and monitored independently.

Key Features and Capabilities

Feature	Description	DevOps Relevance
Local‑First Data Store	All data resides in a mounted volume; no external SaaS dependencies.	Enables full control over data residency and compliance.
SSO / OIDC	Configurable client IDs, secret keys, and redirect URIs.	Integrates with existing identity providers; supports MFA.
FIRE Simulation Engine	Monte‑Carlo and deterministic models that accept user‑defined parameters.	Provides a calculable use‑case for automated reporting.
RESTful API	JSON endpoints for assets, transactions, goals, and simulation results.	Facilitates integration with monitoring, CI/CD, and backup pipelines.
Docker‑Compose Deployment	Single‑file orchestration with health checks and restart policies.	Fits naturally into existing compose‑based homelab stacks.
OpenAPI Documentation	Auto‑generated Swagger UI at /api/docs.	Allows programmatic exploration and client SDK generation.

Pros and Cons

Pros

• Self‑contained: All components can be launched with a single docker compose up -d.
• Extensible: Modular services enable targeted updates without full redeployments.
• Transparent: Open‑source codebase permits audits and custom extensions.
• Community‑Driven: Active issue tracker and contribution model encourage continuous improvement.

Cons

• Resource Footprint: PostgreSQL and the Vue front‑end consume moderate CPU and memory; careful sizing is required on low‑end hardware.
• Complexity of OIDC: Proper client configuration demands coordination with the identity provider’s redirect URIs and scopes.
• Limited Built‑In HA: The reference deployment is single‑instance; high‑availability requires external load balancing and database replication.

Real‑World Use Cases

• Homelab Budget Dashboard – A centralised view of household cash flow, fed by automated CSV imports from personal banking exports.
• Crypto Portfolio Tracker – Aggregates holdings across multiple wallets, applying cost‑basis calculations for tax reporting.
• Retirement Planning Suite – Runs nightly FIRE simulations, stores results in a separate analytics database, and pushes alerts via webhook to a Slack channel.

These scenarios illustrate why a DevOps‑savvy audience would want to evaluate Wealthfolio V36 as part of their self‑hosted financial infrastructure.

---

PREREQUISITES

Before attempting to deploy Wealthfolio V36, verify that your environment meets the following baseline requirements.

System Requirements

Component	Minimum	Recommended
CPU	2 vCPU	4 vCPU
RAM	2 GB	4 GB
Disk	10 GB SSD	20 GB SSD (for PostgreSQL and persisted data)
OS	Ubuntu 22.04 LTS / Debian 12	Any recent Linux distribution with Docker Engine ≥ 24.0

Required Software

1. Docker Engine – Install the latest stable release. Verify with docker version.
2. Docker Compose – Version 2.20 or newer.
3. Git – For cloning the repository.
4. PostgreSQL Client – Optional, for manual DB migrations.
5. OpenID Connect Provider – Either self‑hosted (e.g., Keycloak) or a cloud‑based IdP with client credentials.

Network and Security Considerations

• The application will expose ports 80 (HTTP) and 443 (HTTPS) only through a reverse proxy (e.g., Traefik or Caddy). Direct exposure of container ports is discouraged in production.
• All secrets (database passwords, OIDC client secret) must be stored in a Docker secret store or an external vault (e.g., HashiCorp Vault).
• Network segmentation: Place the containers in a dedicated Docker network (wealthfolio_net) to isolate traffic from other services.

Pre‑Installation Checklist

1. Create a dedicated system user for the application (e.g., wealthfolio).
2. Generate a strong PostgreSQL password and store it in a secret file (/etc/wealthfolio/.db_password).
3. Configure your OIDC provider: note the client ID, client secret, authorization endpoint, and token endpoint.
4. Reserve a domain name (e.g., finance.example.com) and obtain a TLS certificate via Let’s Encrypt or your internal PKI.
5. Ensure Docker daemon is configured to restart containers on failure (--restart unless-stopped).

---

INSTALLATION & SETUP

The following sections provide a complete, reproducible installation workflow using Docker Compose. All commands are written to avoid Jekyll‑sensitive syntax; placeholders such as $CONTAINER_ID are used where dynamic values are required.

1. Clone the Repository

git clone https://github.com/wealthfolio/wealthfolio.git
cd wealthfolio

2. Create a Docker Network

docker network create wealthfolio_net

3. Prepare Environment Files

Create three files in the project root:

• .env – Holds generic environment variables.
• db.env – Specific to the PostgreSQL service.
• auth.env – Specific to the OIDC sidecar.

.env example

# Application URL (used for generating absolute links)
APP_URL=https://finance.example.com

# Port mapping (exposed only to the reverse proxy)
WEB_PORT=8080
API_PORT=8000

db.env example

POSTGRES_USER=wealthfolio
POSTGRES_PASSWORD=REPLACE_WITH_STRONG_PASSWORD
POSTGRES_DB=wealthfolio
POSTGRES_HOST=wealthfolio-db
POSTGRES_PORT=5432

auth.env example

# OIDC Provider Settings
OIDC_CLIENT_ID=wealthfolio-client
OIDC_CLIENT_SECRET=REPLACE_WITH_SECRET
OIDC_AUTHORIZE_URL=https://auth.example.com/authorize
OIDC_TOKEN_URL=https://auth.example.com/token
OIDC_REDIRECT_URI=https://finance.example.com/auth/callback
OIDC_SCOPE=openid profile email

Note – Replace all placeholder values with production‑ready credentials before proceeding.

4. Build and Start Services

docker compose up -d

The compose file defines four services: wealthfolio-db, wealthfolio-api, wealthfolio-web, and wealthfolio-auth. Each service includes a restart: unless-stopped policy and health checks.

5. Run Database Migrations

docker exec $CONTAINER_ID_wealthfolio-db pg_isready -U $POSTGRES_USER
docker exec $CONTAINER_ID_wealthfolio-api python manage.py migrate

Replace $CONTAINER_ID_wealthfolio-db with the actual container ID obtained via docker ps. The migration command applies schema changes to the freshly initialized PostgreSQL instance.

6. Verify Service Health

docker ps --filter "name=wealthfolio" --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Image}}"

You should see all four containers in the Up state with health checks reporting healthy.

7. Configure Reverse Proxy (Example with Traefik)

Create a static configuration file traefik.yml that routes traffic to the services:

entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false

http:
  routers:
    wealthfolio-web:
      rule: "Host(`finance.example.com`)"
      entryPoints: ["websecure"]
      service: "wealthfolio-web-svc"
      tls:
        certResolver: letsencrypt
    wealthfolio-api:
      rule: "Host(`api.finance.example.com`)"
      entryPoints: ["websecure"]
      service: "wealthfolio-api-svc"
      tls:
        certResolver: letsencrypt
  services:
    wealthfolio-web-svc:
      loadBalancer:
        serverTransport: ["websecure"]
        locations: {servicePath: "/"}
    wealthfolio-api-svc:
      loadBalancer:
        serverTransport: ["websecure"]
        locations: {servicePath: "/api"}

Deploy Traefik alongside the stack:

docker run -d \
  --network wealthfolio_net \
  --name traefik \
  -p 80:80 -p 443:443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ./traefik.yml:/etc/traefik/traefik.yml \
  traefik:v2.11

After Traefik is up, the application will be reachable at https://finance.example.com (web UI) and https://api.finance.example.com (REST API).

8. Initialise OIDC Authentication

Navigate to the authentication callback endpoint (/auth/callback) and follow the provider’s consent screen. The first‑time setup will create a user record in the PostgreSQL database and store the session token in an encrypted cookie.

---

CONFIGURATION & OPTIMIZATION

1. Environment Variable Management

Wealthfolio relies on a set of environment variables for feature toggles and external integrations. Below is a representative list with explanations:

Variable	Default	Description
APP_URL	required	Base URL used for generating links in emails and OAuth redirects.
API_RATE_LIMIT	1000	Maximum requests per minute per IP; adjust based on expected load.
LOG_LEVEL	INFO	Verbosity of application logs (DEBUG, INFO, WARNING, ERROR).
DB_MAX_CONNECTIONS	20	PostgreSQL connection pool