Yuvomi: a self-hosted family planner with nineteen modules on one server

What Yuvomi replaces, and for whom

The README frames the problem as subscription sprawl: a to-do app, a shared calendar, a cost-splitting app, a budgeting app, a meal planner, a grocery list, a pantry tracker, a document manager, a home inventory, and a notes app, each with its own account and its own copy of a household's data on someone else's server. Yuvomi's answer is to run all of those as modules inside one container on hardware you control. The README claims that "the only thing that leaves it is a version check," which is a strong statement, and the repository's SECURITY.md is where a sceptical operator should look before repeating it.

The intended user is a household, not an individual. Family member profiles, roles, invite links, per-member assignment on tasks and events, and a rewards ledger where a ticked-off chore credits the assigned member all assume more than one person. A couple or a single person can run it, and the README says so, but the module set is sized for the family case.

The repository is not archived and the last push was on 2026-08-29, the same day as the v2.52.1 release. Note the gap between what the release list shows and what package.json contains: the manifest declares version 2.66.1 while the newest tagged release is v2.52.1. That is not necessarily an error, but it means the tag history and the manifest are not in step, and anyone pinning a version should check which of the two they are pinning to.

One Node process, SQLite with ciphers, and modules that write into each other

The runtime is a single Node.js process: package.json sets "main" to server/index.js, "type" to "module", and engines.node to ">=22.0.0". The Dockerfile builds on node:24-slim pinned by digest, installs python3, make and g++ in the build stage as a fallback for native modules, then copies node_modules into a runtime stage that adds gosu. The comment in the Dockerfile states that since v13 better-sqlite3-multiple-ciphers ships Node-API binaries for linux-x64 and linux-arm64, glibc and musl, so node-gyp only runs on a platform without a bundled binary. The cipher layer is inside that module; a system SQLCipher is not required. That is why the README can offer AES-256 database encryption as an option rather than a separate install.

Persistence is three bind mounts in docker-compose.yml: /data for the database and app data, /backups for scheduled backups, and /app/modules for drop-in modules. A fourth, optional mount handles local document storage, and the compose file carries a warning about it: both ends of that mount come from .env, because the app writes to DOCUMENT_STORAGE_LOCAL_PATH. If you mount at a fixed /documents while the app writes elsewhere, uploads land in the container layer and disappear on the next pull and up -d.

The cross-module behaviour is the part a folder of separate apps cannot reproduce. The meal plan writes ingredients to the shopping list. Ticking items off after a shop books them back into the pantry with their quantity. Points from a completed task credit the assigned member's rewards account. A receipt can belong to a budget transaction, a shared expense and an inventory item at once. The Schedule module takes a different approach from most calendar features: rotating shift patterns and weekly timetables are computed on read and shown as a read-only calendar overlay, so editing a pattern leaves no stale appointments behind. That is a deliberate trade-off, and it means schedule entries are not editable as individual events.

Installing Yuvomi with Docker Compose

The README's install section points at a container image, ghcr.io/ulsklyc/yuvomi:latest, and the repository ships docker-compose.yml, podman-compose.yml, install.sh and setup.js. A bare-metal path exists through npm, and package.json exposes "start": "node --import dotenv/config server/index.js" and "setup": "node --import dotenv/config setup.js", but Docker is the documented route.

Start from the environment template. Copying .env.example to .env is the first step the file itself states, and the two values that matter most are the host port and the session secret.

cp .env.example .env
# edit .env: OIKOS_HTTP_PORT, SESSION_SECRET, TZ

The compose file maps the host port from OIKOS_HTTP_PORT onto container port 3000. The app inside the container always listens on 3000; only the host side moves. The comment in .env.example is explicit that without SESSION_SECRET the container exits at startup, which is why the compose file uses the short env_file form rather than the newer long form: the long form needs Compose v2.24 and fails to parse on older Synology DSM, QNAP and distribution packages. GitOps stacks without a .env are pointed at docs/docker-compose.portainer.yml instead.

docker compose up -d
docker compose logs -f yuvomi

After the container is up, open the host port you set (3000 by default) and create the first account. The README states that new members join through an invite link and pick their own password, so the first user is the administrator and everyone else arrives by invitation. For a first real use, turn on Tasks and Shopping, create a shopping list, then add a recipe and place it in a meal slot for the coming week. The README says the ingredients land on the shopping list from there, which is the shortest path to seeing whether the module interlocking is worth it for your household. If you only want a task board, you can leave the other modules off; the README notes that Inventory and Schedule are off by default and that every module is independent.

Where Yuvomi is the wrong choice

The deployment surface is the first honest limitation. Docker Compose is the supported path, and the compose file's own comments describe a compatibility trap: the long env_file syntax fails on Synology DSM, QNAP and older distributions before the first start. The project routes around it with a short form plus a separate Portainer file, but the effect is that a GitOps setup without a .env has to be assembled from a second document rather than the primary one.

Time zones are the second. .env.example documents TZ as the container zone and the default for the household zone, then notes that since v2.34.0 the household zone is its own setting under Settings > Personal > Appearance > Region, and that this setting wins where both exist. TZ lives in the compose file, which the file itself points out you cannot reach on Umbrel, TrueNAS or Unraid. The consequence is spelled out: the zone affects which calendar day server jobs call "today", events pushed to Google or Outlook, CalDAV reminder due times synced into Tasks, and the times in the exported calendar feed. A wrong zone shifts every appointment. That is a real failure mode, not a cosmetic one.

Third, the module count cuts both ways. Nineteen modules, twenty-four languages and optional encryption are a large surface to configure, and the README's own framing is that you switch off what does not fit. If your household's actual need is a shared task list, a dedicated task tracker will be smaller to run and smaller to upgrade. Yuvomi is also not a mobile app: the README describes wall mode for a kitchen tablet and an Immich screensaver, but nothing in the repository describes a native Android or iOS client, so a household that expects an app-store install is looking at the wrong project. Finally, the release list and package.json disagree on version (v2.52.1 against 2.66.1), so pinning to a tag and pinning to a manifest are not the same act here.

Yuvomi against Vikunja and the single-purpose tools

The most direct comparison in the related searches is Vikunja, and the difference is scope rather than quality. Vikunja is a task and project management tool: lists, kanban, assignments, due dates. Yuvomi's Tasks module covers that ground, with kanban, deadlines, recurring schedules, multi-member assignment, comments and a lock that lets only the creator and admins redefine a task while everyone else can still tick it off. But Tasks is one of nineteen modules, and the reason to pick Yuvomi over a task tracker is the wiring around it: a chore that pays points into a rewards ledger, a meal plan that writes the shopping list, a receipt attached to a transaction and an inventory item at the same time.

If you do not want that wiring, the trade is unfavourable. A single-purpose tracker has one data model, one upgrade path and one set of settings; Yuvomi has a module registry, per-module enablement, and a database whose schema the project tests heavily (the package.json scripts include test:migrations-append-only, test:schema-mirror, test:schema-reconcile and test:db-encryption, which suggests schema changes are treated as a first-class risk). That test list is a signal about where the project expects breakage, and it is a cost you inherit whether or not you use the modules that caused it.

On the calendar side, Yuvomi is a consumer and producer rather than a replacement for a calendar server. The README describes two-way sync with Google and CalDAV, one-way Outlook push through Microsoft Graph, calendar subscriptions and per-event visibility. If your household already runs a CalDAV server, Yuvomi can sync against it; if you want the server itself, that is a different project.

Upgrades, backups and what the MIT licence leaves to you

Upgrade cost is mostly the container pull. The compose file pins the image to ghcr.io/ulsklyc/yuvomi:latest and sets restart: unless-stopped, so a pull followed by up -d replaces the running version. The Dockerfile pins its base image by digest and its comment says Dependabot raises the digest alongside the tag, which means base-image updates arrive through the repository rather than through you. Because the database is a file under /data, the upgrade risk sits in schema migrations, and the test scripts named in package.json (test:migrations-append-only, test:db-newer-schema) indicate the project has guards for migrations and for opening a database written by a newer version.

Backups are a built-in module: manual and scheduled backup and restore with pre-restore rollback and optional cloud upload. The Dockerfile carries a comment about the backup target that is worth repeating, because it is the kind of thing that silently fails: without the container-level BACKUP_DIR environment variable, the app falls back to its bare-metal default of ./backups, which resolves to /app/backups, where the node user has no write permission, so backups do not land in the mounted volume. If you enable scheduled backups, confirm a file appears in the host BACKUP_DIR you set in .env.

Licensing is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. The repository also ships SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md and SUPPORT.md, so there is a stated process for reporting problems rather than a support contract. MIT gives you no warranty, and nothing in the repository promises a support channel or a compatibility guarantee across versions. That is a normal arrangement for self-hosted software and worth stating plainly rather than treating as a defect. Note also that the README references a hosted tour at yuvomi.cloud; that site is a demonstration, not a hosted version of your data.

Editorial conclusion

Adopt Yuvomi if your household already runs a home server or NAS, you want one database for chores, lists and budgets, and you accept Docker as the supported deployment path. Skip it if you want a hosted service, a phone app you install from a store, or a task tracker you can read in one sitting: nineteen modules is the point and also the cost. Before you commit, verify three things on your own hardware: that the container starts with SESSION_SECRET set, that your Compose version accepts docker-compose.yml's short env_file form, and that a scheduled backup actually lands in the mounted BACKUP_DIR rather than inside the container layer.

Frequently asked questions

Official sources

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