LifeForge: a modular self-hosted life manager, mid-migration and honest about it

One self-hosted app against a drawer of SaaS subscriptions

LifeForge's stated enemy is app sprawl. The README argues that people now juggle too many productivity apps, that subscription SaaS costs recur, and that such services may harvest user data for advertising, analytics or AI training. Its answer is a single self-hosted application covering the domains a person might otherwise spread across half a dozen services. The repository topics read like a module list: calendar, todo list, note taking, journaling, finance management, idea box, project tracking, code time tracking, music library, photos management, password manager, repositories management and achievement tracking. The README itself is translated into English, Simplified Chinese, Traditional Chinese and Bahasa Malaysia, which is a broader language spread than most hobby infrastructure projects bother with. The framing targets individuals who already run their own servers and dislike renting their own life back month by month, a fair description of the self-hosting community.

React and Express around PocketBase, composed through module federation

The visible stack comes from the badges and the migration notes. The client is React with TypeScript. The server side is Node.js with Express, and the data layer is PocketBase, the embedded Go-based backend that ships auth, database and file storage in one binary, which is a sensible way to keep a self-hosted install small. The interesting part is the composition model. The client uses module federation: a host application loads feature modules dynamically, and each module owns one of the life domains listed above. The migration notes describe modules being loaded and composed at runtime, with both host and remote applications contributing to a single document. That architecture is what makes the project extensible in principle, and it is also exactly what caused the styling crisis documented next. Contributing sections in the README distinguish contributions to core from creating new modules, so the federation is a designed extension point, not an accident.

The Tailwind exit, documented as an architectural necessity

The longest and most instructive part of the README is the post-mortem of the styling failure. Both the host and the federated modules were bundling Tailwind CSS independently. Each module generated its own CSS output, all of it converging into one document cascade, so style precedence ended up depending on module injection order rather than intent. The results listed are unpredictable overrides, broken responsive utilities, cross-module interference and inconsistent rendering between host and remotes. The README is blunt that once multiple Tailwind bundles coexisted, no practical fix existed within that model, calling the migration away from Tailwind an architectural necessity rather than a preference. PR #93 replaced it with a token-driven, component-based internal UI library, @lifeforge/ui, which every application now consumes for primitives, tokens and styling behaviour, making it the single source of truth for visual presentation and removing per-module CSS by design. An update dated 31 May 2026 marks the rewrite complete, with module migration and documentation updates still outstanding. Any team building with module federation should read this section; it is one of the clearest public write-ups of why utility CSS and federated runtimes collide.

A legacy-final branch, an early-development banner, and a live mainline

Maturity signals cut both ways here. On the caution side, the README carries a warning in capitals that the project is still in early development and that features and modules are subject to change, pointing to the changelog for current state. The only release listed is legacy-final, dated 31 May 2026, which preserves the final Tailwind-based implementation on its own tag and branch for reference; it is explicitly no longer developed. On the activity side, the last push to main was 2026-09-10, one day before this review's reference date, and a note insists the project is still alive and kicking. Put together, the picture is a solo-driven project that paused for a large refactor, shipped it, archived the old line, and is now migrating modules onto the new UI system. Anyone adopting mid-migration inherits a moving target: the README says as much itself, with the aside that every final architecture eventually becomes tomorrow's migration project.

The password manager module deserves disproportionate scrutiny

Among the module topics sits password-manager, and that changes the risk calculation. Storing credentials in an application that describes itself as early development, mid-migration and subject to change is a materially different decision than storing a journal or a music library index. The supplied material contains no security documentation, no audit, and no statement about encryption at rest for the vault; nothing of the kind appears in the README text available here, and it should not be assumed from PocketBase's presence. The same caution applies in softer degrees to photos management and finance management, domains where data loss or exposure hurts. This is not a claim that the module is unsafe; it is a statement that the material gives no evidence either way, and the project's own banner advises expecting change. A reasonable posture is to adopt the low-stakes modules first and treat the credential vault as off limits until the project documents its security model.

A custom licence, and setup steps the README leaves to the docs

Two adoption barriers need naming. First, the licence. GitHub classifies it as Other, a custom licence it cannot categorise, with details in the LICENSE file. Custom licences defeat casual adoption: an organisation cannot assume MIT-style permissions, and anyone intending to self-host, modify or redistribute should read the file before deployment, not after. This review does not offer legal advice, only the observation that non-standard terms are a real filter. Second, the setup path. The supplied README truncates before its Setup section, so no install commands can be quoted from the material; the documentation site at docs.lifeforge.dev is the place where commands and configuration live, and the changelog there tracks module migration state. For comparison, established self-hosted platforms such as Nextcloud cover calendar, photos and notes with years of production history and clear licensing, at the cost of a heavier footprint and no first-class federation story for niche modules like code time tracking or achievement tracking. Single-purpose self-hosted apps, one per domain, remain the mature alternative, exchanging LifeForge's one-interface convenience for per-domain depth.

Editorial conclusion

Self-hosters who want one place for calendar, todos, journaling and hobby modules, and who can tolerate early-development churn, should follow the changelog at docs.lifeforge.dev/progress/changelog and check which modules have finished the @lifeforge/ui migration before investing data in them. It is the wrong choice today for anyone whose main need is the password manager or photo vault, given the project's own features-subject-to-change banner and the absence of security documentation in the material, and for organisations that cannot clear a custom licence. Read the LICENSE file and confirm the setup steps in the docs first, because the supplied README truncates before its Setup section.

Official sources

1. Issues
2. Lifeforge-app/lifeforge on GitHub
3. Project website
4. README
5. Releases