LiftTrace v1.3.0 Released: Privacy-First Self-Hosted Fitness Tracking Done Right

The rise of self-hosted open-source apps has become a meaningful counterforce to the relentless migration of personal data to the cloud — and fitness tracking is no exception. LiftTrace is a self-hosted weightlifting workout logger licensed under AGPL-3.0, positioned as an alternative to commercial apps like Strong, Hevy, FitNotes, and Jefit. Its core value proposition is refreshingly clear: no telemetry, no cloud sync, no external accounts. Your entire training log lives in a single SQLite file on your own machine, and the whole application runs as a single Docker container. The recently released v1.3.0 brings several practical updates that also reflect the design philosophy behind this class of privacy-first tools.

What LiftTrace Is: A Complete Workout-Log-First Solution

LiftTrace is part of the TraceApps family, which also includes NutriTrace for nutrition management, CookTrace for recipes and shopping, and NoteTrace for notes and tasks. As a "workout log-first" application, its core experience is solid: log weight, reps, and RPE (Rate of Perceived Exertion) set by set, mark warm-up sets, chain supersets, and let the rest timer start automatically.

One thoughtful detail: the previous session's data is displayed just above the row you're currently filling in, so you always know exactly what you're trying to beat. If manual entry feels slow, you can type or speak commands like "bench 3x5 185" directly. The app also ships with a built-in exercise library containing thousands of movements with images, plus meaningful analytics: volume over time, individual exercise progress, estimated 1RM, automatic personal records, and a muscle recovery map.

Gym-floor use cases are well considered too. The native Android app supports offline logging with sync on reconnect, or it can run entirely local with no server at all. It can import historical data from Strong, Hevy, FitNotes, Jefit, and Garmin, and supports OIDC single sign-on, multi-user role management, and full backups.

RPE (Rate of Perceived Exertion) is a subjective intensity scale widely used in strength training, typically rated 1–10 (a variant of the Borg RPE scale), where 10 represents complete failure. Unlike fixed percentage-based intensities, RPE dynamically reflects your body's state on any given day — the same weight might feel like RPE 8 when fatigued but only RPE 6 when fresh. Estimated 1RM (one-rep max) is a formula-based projection of your theoretical maximum lift from multi-rep sets; common formulas include Epley (weight × (1 + reps/30)) and Brzycki. Together, these two metrics form core data points in modern evidence-based strength training, letting athletes track progress without having to test their true maximum every session.

Core New Features in v1.3.0

This release addresses several structural limitations by centering updates around real-world training scenarios.

Multiple Workouts Per Day

The previous one-workout-per-day restriction has been lifted. You can now log a weightlifting session and a separate flexibility session on the same day, each tracked independently. Once a second session is created, tab navigation appears in the interface. This is a genuine necessity for anyone running concurrent strength and mobility training.

Timed Sets

For exercises like planks, dead hangs, wall sits, and loaded carries, measuring by duration rather than reps is the only thing that makes sense. The new hold timer counts down the entry, then times the hold and marks it complete — while recording your longest hold. Crucially, training plans, CSV exports, and importers for Strong, Hevy, FitNotes, and Garmin all understand this data type.

Progress Photos

Progress photos now have a dedicated page: a timeline annotated with logged bodyweight for the day, a draggable two-photo comparison scrubber effect, and a slider that plays your entire photo history as a time-lapse. iPhone HEIC photos are converted in the browser, and photo files are only served to the account that owns them.

Weekly Report and Recovery Map

A genuinely useful weekly report has been added: sessions completed against goal, sets, volume, duration, and records — each compared to the prior month's weekly average. The muscle recovery map has also been redrawn with accurate body proportions.

Privacy and Security Trade-offs

LiftTrace's most defining stance is "nothing ever phones home." No telemetry, no cloud sync, no account binding anywhere. This design is highly appealing to users who care about data sovereignty, but it also means the responsibility for backups and multi-device sync falls entirely on the user.

This release delivers meaningful security hardening: progress photos are now served behind authentication, full backup archives can no longer be accessed directly via URL, and uploaded files are served with their extension determined by actual file type under a sandboxed content policy. The developer also cleared all medium-and-above severity dependency vulnerabilities from this release cycle, including denial-of-service, validation bypass, and prototype pollution issues.

For power users who want automation integrations, v1.3.0 provides three interfaces — an MCP server, a REST API, and webhooks — but all three are off by default. Scoped tokens work across both MCP and REST, and webhooks can send signed POST requests to platforms like n8n and Home Assistant without polling. The default-off design once again reflects a security-first mindset.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic that allows AI assistants to read and write data from external applications through a standardized interface — essentially providing "tool slots" for large language models. LiftTrace's MCP server means users can let MCP-compatible AI clients (such as Claude Desktop) directly query training history and analyze progress trends without manually exporting data. Webhooks are a complementary integration mechanism: when a specific event occurs (such as completing a workout), the app proactively sends an HTTP POST request to a preconfigured URL, which automation platforms like n8n and Home Assistant can use to trigger downstream actions like updating a calendar or pushing a notification. Prototype Pollution is a JavaScript-specific security vulnerability in which an attacker manipulates Object.prototype to inject malicious properties into all objects, potentially enabling privilege escalation or code execution — a medium-to-high-severity risk category that Node.js backend applications need to guard against carefully.

Important Upgrade Notes for Docker Users

This upgrade contains one breaking change that's easy to miss: the container's listening port has changed from 3003 to 3002, to match the example host port. If your compose file maps "3002:3003", you'll need to update it to "3002:3002" before pulling, otherwise the app will be unresponsive.

Any setup that accesses the container directly via the old port — reverse proxies on the same Docker network, Traefik port labels, or tunnels — needs the same update. The good news is that the host port is unchanged, so bookmarks and Android app server addresses remain valid. Installations that set the PORT variable manually are unaffected.

Docker's port mapping syntax is "host_port:container_port" — for example, "3002:3003" forwards traffic on the host's port 3002 to port 3003 inside the container. This change moves the container's internal listening port from 3003 to 3002, meaning the mapping rule needs to be updated to "3002:3002". Traefik is a popular reverse proxy and load balancer in the Docker ecosystem that auto-discovers service routes via container labels; if its labels hard-code the old container port, they'll need manual correction. Users routing traffic directly to a container's IP and port via tunneling solutions like Cloudflare Tunnel or Tailscale Funnel will also experience connection failures from this port change and must update the target port on the tunnel configuration side.

AI's Role in Development

Worth noting: in keeping with community norms, the developer publicly discloses how AI was used in the project. The breakdown is roughly as follows — feature implementation was approximately half-and-half, with AI drafting code and the developer reviewing, testing on real hardware, and only committing verified portions, with every commit reviewed by a human. Architecture decisions were human-led, with AI suggesting trade-offs and edge cases. Documentation was also roughly 50/50. Testing was primarily manual on real devices, with AI helping draft test plans and think through edge cases. This kind of candid AI usage disclosure is becoming a transparency practice worth encouraging across the open-source community.

Nine community members contributed code, detailed bug reports, and feature suggestions during this development cycle, and all are credited by name in the release notes. It's a small but telling sign of a healthy open-source project in motion.