HomeHub: a no-login family dashboard that runs on a Raspberry Pi

The problem HomeHub targets: shared household state without an account system

Most family coordination happens in chat threads and paper notes. HomeHub puts that state on one machine inside the home network: shared notes, a shopping list, chores, a calendar, an expense tracker with recurring bills, and a media downloader. The README frames the audience as the whole household, not the person who installs it, and the config example lists family members as plain strings (Mom, Dad, Dipanshu, Vivek, India) rather than accounts. The privacy claim is specific: all data stays on your network, and the repository topics include no-tracking. There is no login flow by default. The config example shows password: "" with the comment leave blank for password less access, so the default posture is an open page on your LAN. That is the design, and it is also the first thing to think about before you put it on a network you do not control.

What the config.yml surface actually controls

Configuration is a single YAML file mounted read-only into the container. instance_name sets the title, admin_name sets the administrator label, and password optionally gates the whole site. feature_toggles is a flat map of thirteen booleans covering shopping_list, media_downloader, pdf_compressor, qr_generator, notes, shared_cloud, who_is_home, personal_status, chores, recipes, expiry_tracker, url_shortener, expense_tracker and calendar. Turning a module off is one line. The reminders block carries time_format (12h or 24h), calendar_start_day (full weekday names, with Sunday as the default when the line is commented out), and categories, where each entry has a key, a label and a hex color. The theme block exposes eight color keys, from primary_color to sidebar_active_color. The README also states that the app follows system dark/light mode. That combination is the whole customization story: no plugin API, no database migrations to run by hand, no admin UI for settings.

Data flow: Flask on port 5000 with four bind mounts

The compose.yml in the README defines one service, container_name: homehub, image ghcr.io/surajverma/homehub:latest, and publishes 5000:5000 with the note that the app listens internally on port 5000. Four host directories are mounted: ./uploads to /app/uploads, ./media to /app/media, ./pdfs to /app/pdfs, and ./data to /app/data. The config is mounted read-only at /app/config.yml. FLASK_ENV is set to production, and SECRET_KEY is read from the environment with a fallback to a random value. That fallback matters: the comment says it falls back to random if not provided, which means an unset key changes on every start. The repository is primarily HTML with a Python backend implied by the Flask environment variables and the /app paths, and the Docker image is built by the docker-publish.yml workflow referenced in the README badge. Media downloads land in the media volume, uploaded files in uploads, generated PDFs in pdfs. Nothing in the supplied material describes a database service, so persistence appears to live in the ./data directory.

Getting it running: two commands and one file copy

The README gives a short path. First copy config-example.yml to config.yml and edit it. Then create or use the provided compose.yml, and run docker compose up -d. The app is reachable at http://localhost:5000. If you prefer not to use Compose, the image is ghcr.io/surajverma/homehub:latest and the only required port mapping is 5000. For SECRET_KEY, the compose file expects it via a .env file (${SECRET_KEY:-}); leaving it empty triggers the random fallback. The read-only config mount means edits require a container restart to take effect, since the file cannot be written from inside the container. There is no documented reverse-proxy configuration, no TLS setup, and no migration command. That is the entire install procedure as published.

The password field is a gate, not an account system

This is the limitation worth stating plainly. HomeHub has one optional password for the whole site. The family_members list is a set of display names, and the README does not describe per-member credentials, roles, or an audit trail of who changed what. On a trusted home LAN that is often acceptable and matches the no-login pitch. Exposed to the internet through a port forward, it is a single shared secret protecting an expense tracker and a file store, with no rate limiting or lockout documented. The other structural risk is the SECRET_KEY fallback: if you never set it, sessions are signed with a key regenerated at each start, and the practical result is that people get logged out whenever the container restarts. The maintainer note is candid about a third constraint: sole maintainer, full-time job, delayed responses to issues and pull requests, work done after office hours or on weekends. Plan for slow turnaround on bug reports.

Where HomeHub is the wrong tool

If you need separate logins for each family member, shared calendar sync over CalDAV, or an API that other services can call, the supplied material does not show any of it. The feature set is a fixed menu of thirteen toggles, so a household that wants, say, a chore system with points and rewards will not find that described here. If you want a dashboard that pulls live data from external accounts (bank feeds, school portals, smart-home sensors), HomeHub is a local store with manual entry, not an integration hub. And if you are deploying for an organization rather than a household, the single-password model and the absence of roles make it a poor fit regardless of how light the container is. The README's own framing, a personal utility that grew, is the honest scope statement.

Alternatives and the actual difference in approach

Home Assistant occupies adjacent territory with a different architecture: an entity-and-integration model where devices and services are represented as state objects, extended through a large integration catalog and an automation engine. HomeHub has no entity model and no automation engine; it is a set of pages backed by files on disk, configured through YAML toggles. For notes and lists specifically, a self-hosted wiki or note app such as a Markdown-based wiki offers richer text handling but no chore tracker, expense tracker, or media downloader in the same container. The trade is breadth of small utilities in one image against depth in any single one. If your household needs one thing done well, pick the specialist tool. If you want a single page the family opens in the morning, HomeHub's bundling is the point.

Maintenance, upgrades and the MIT licence

The release history shows v0.2.3.3 in May 2026, v0.2.3.4 in June, and v0.2.4 in August, so the cadence is roughly every one to three months, with the version numbering itself irregular (three-part and four-part tags in the same series). Upgrading means pulling a new image and restarting the container; the README does not document a migration step, and since config.yml is mounted read-only, a new release that adds config keys will simply see them absent and fall back to defaults. Back up the four bind-mounted directories before pulling, because that is where uploads, media, PDFs and data live. The project is MIT licensed, which permits commercial and private use and modification, and requires that the licence text and copyright notice be preserved in copies. That is a summary of the licence identifier given in the repository metadata, not legal advice; read the LICENSE file for the binding terms. The maintenance cost you should actually budget for is the human one: a single maintainer working evenings and weekends.

Editorial conclusion

Adopt HomeHub if your household wants a LAN-only dashboard and you are comfortable editing config.yml and running docker compose up -d. Skip it if you need multi-tenant accounts, audit trails, or a support SLA, because the README describes a single optional site password rather than per-user authentication, and the maintainer states that responses to issues and pull requests may be delayed. Before committing, verify that the feature toggles you need exist in config-example.yml, that your compose.yml bind mounts (uploads, media, pdfs, data) point at storage you back up, and that SECRET_KEY is set through .env so sessions survive a container restart.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. surajverma/homehub on GitHub