Baby Buddy: A Django Tracker for Infant Sleep, Feeding and Diaper Data
A :baby: buddy to help caregivers track sleep, feedings, diaper changes, tummy time and more to learn about and predict baby's needs without (as much) guess work.
At a glance
- What is it?
- Baby Buddy is a self-hosted Django application for logging infant care events. It is a good fit for caregivers who want their child's data on their own hardware and for tinkerers who want an HTTP API to build on, and a poor fit for anyone who wants a managed mobile app with no server to run.
- Who is it for?
- Adopt Baby Buddy if you already run a server, want the raw event data in your own database, and are willing to treat it as a long-lived Django deployment rather than an app.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Baby Buddy solves, and for whom
Infant care is a stream of timestamped events with no structure: a feeding at 02:40, a diaper change at 03:15, a nap that started sometime during a phone call. The information that matters later (how long since the last feed, whether sleep is consolidating, how many wet diapers today) lives in whoever was awake at the time. Baby Buddy's stated purpose is to record those events so caregivers can, in the project's words, "learn about and predict baby's needs without (as much) guess work."
The audience is narrower than the tagline suggests. This is a Django application, and the README points to a demo instance, a documentation site and a set of third-party integrations rather than to an app store listing. The people who get value from it are households with a server already running, or with the appetite to run one, plus developers who want a database of their own child's events to query. The topics attached to the repository (self-hosted, django, python) describe the intended user more accurately than the description does. A parent who wants to tap a button on a phone and never think about infrastructure is not the target, and the README's own integration list confirms this: the mobile options it names are separate projects, not part of this codebase.
What the Django project actually contains
The repository is a Django project named babybuddy, with a static_src directory holding front-end assets such as the logo at babybuddy/static_src/logo/icon.png. The README shows two screenshots, one labelled desktop view and one labelled mobile views, which indicates the templates are responsive rather than that a separate mobile client ships with the server.
Event types are the core of the data model. Sleep, feedings, diaper changes and tummy time are named in the description, and the phrase "and more" implies the set is larger than that list. The material does not enumerate the full set of models, so treat the four named types as confirmed and the rest as unverified.
Several features are visible from the surface of the repository rather than from its internals. Language is a per-user setting, changed at /user/settings/, and the README lists roughly two dozen locales including Brazilian Portuguese, Catalan, both simplified and traditional Chinese, Czech, Danish, Dutch, Finnish, French, German, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian Bokmål, Polish, Portuguese, Russian, Serbian, Spanish, Swedish, Turkish and Ukrainian. The project also exposes an API, because the third-party entries in the README describe clients that log and query data: an MCP server for AI assistants, a Home Assistant integration, an Alexa skill, and hardware keypads built on ESP8266 and ESP32 boards. A separate custom TypeScript frontend based on Remix is listed as well. None of those clients could exist without a documented HTTP interface, and the MCP entry explicitly links to MCP documentation at docs.baby-buddy.net/mcp/.
The README also points to a Grafana dashboard discussion, which suggests the data is queryable outside the application, though the discussion itself is not reproduced here.
Running it: what the material confirms and what it does not
The README does not include installation commands. It links to docs.baby-buddy.net for full documentation and to a GitHub Codespaces badge that opens the repository in a ready-to-code environment with the parameter quickstart=1. The Codespaces route is the only setup path the README itself offers, and it is a development environment rather than a deployment recommendation.
What the material does give you is the shape of a running instance. There is a demo at demo.baby-buddy.net with credentials admin and admin, and the README states the demo instance resets every hour. That is the fastest way to see the interface without installing anything. There is a user settings page at /user/settings/ where language is selected. The project is written in Python, uses Django, and follows black for code style, which tells you the deployment model: a Python web application with a database behind it, served over HTTP.
Beyond that, the specific commands (how to install dependencies, how to run migrations, which settings module to use, whether a container image is published) are not in the supplied material. Anyone planning a deployment should read docs.baby-buddy.net first and treat this article as a description of scope, not a runbook.
The API is the real interface, and that is a deliberate trade-off
Look at what the README spends its space on. After the demo and documentation links, the largest section is a list of projects that extend or consume Baby Buddy: an MCP server, a Home Assistant add-on and a separate Home Assistant integration, an Alexa skill, four different hardware keypads and displays, an iOS app, an Android app, a Sandstorm package, a Grafana dashboard, and a three-part blog series about building API clients, buttons and an LCD screen. The project treats its HTTP API as a first-class product surface and lets other people build the interfaces.
That is a coherent strategy and it has a cost. The web UI is one client among many, and features that would be trivial in a single-client application (offline logging, push notifications, background sync) belong to whoever writes the client. The README's mobile section points to third-party apps rather than to anything shipped here. If you want the polished mobile experience, you are depending on those projects, their release cadence and their compatibility with whatever Baby Buddy version you run. The repository also carries an iOS shortcuts discussion and a data-conversion discussion for importing from a commercial app called Baby tracker, which suggests import and quick-entry are recurring user concerns rather than solved problems.
For a developer this is the attractive part. The same API that makes the web UI thin makes it straightforward to log a feeding from a microcontroller or to pull a month of sleep data into a notebook.
Where Baby Buddy is the wrong tool
The most obvious failure mode is operational. Baby Buddy is a self-hosted Django service. It needs a host that stays up, a database that gets backed up, and someone who will apply upgrades. A caregiver logging a 3 a.m. feeding from a phone is doing so over the network to that service. If the server is down, asleep, or unreachable from the phone's network, logging stops. Nothing in the supplied material describes an offline queue in the web UI.
Second, the project is a recorder, not an advisor. The description says it helps you "learn about and predict baby's needs," but the material describes event tracking, a dashboard, an API and integrations. It does not describe a prediction model, a recommendation engine, or any analysis beyond what a caregiver reads off a screen. Expecting the application to tell you that your baby is ready to drop a night feed is expecting something the material does not support.
Third, the integration story cuts both ways. If your household already lives in Home Assistant, the README lists both an add-on that hosts Baby Buddy and an integration that monitors it, so the fit is good. If your household lives in a commercial ecosystem with no API access, Baby Buddy adds a second place to look rather than replacing the first.
Finally, the licence is BSD-2-Clause, a permissive licence that permits modification and redistribution with minimal conditions. That is friendly to the third-party client ecosystem described above. It also means there is no copyleft obligation pushing improvements back upstream, so forks can diverge. This is a description of the licence text, not legal advice; read LICENSE and SECURITY.md in the repository if either matters to your situation.
The alternative: a commercial tracking app
The realistic alternative for most caregivers is a commercial mobile app such as the one the README refers to as "Baby tracker - feeding, sleep and diaper," for which a community discussion exists about converting exported data into Baby Buddy. The difference in approach is not features, it is where the data lives and who operates the software.
A commercial app installs from an app store, syncs through the vendor's servers, and requires no maintenance from you. It also puts your child's feeding and sleep history in someone else's database, under terms you did not negotiate, on a schedule you do not control. Baby Buddy inverts every one of those: you run the service, you hold the database, and the mobile experience is something you or a third party assembles on top of an API. The README's own list of clients is evidence that this works, and also evidence that it takes more effort than installing an app.
There is a middle option worth naming. Home Assistant users can run Baby Buddy as an add-on and drive it from the integration, which keeps the data local while reusing automation the household already has. That path depends on third-party projects listed in the README, not on Baby Buddy itself, so its reliability is a separate question from Baby Buddy's.
Maintenance cost and upgrade surface
The release history in the supplied material shows v2.9.1 and v2.9.2 published on the same day in May 2026, followed by v2.10.0 in early August 2026, with the last push to the repository on 2026-09-01. That pattern (occasional patch releases clustered together, then a minor release) is what you would expect from a maintained Django project, and it means upgrades arrive a few times a year rather than continuously.
Each of those upgrades lands on a Python web application with a database schema, so the maintenance cost is the standard one: read the release notes, back up the database, apply migrations, restart. The material does not describe a migration or backup procedure, so that procedure has to come from docs.baby-buddy.net. The integrations listed in the README raise the cost slightly, because a Home Assistant add-on, an Alexa skill or a hardware keypad may need to track API changes independently of the server.
The language files are a second, quieter maintenance surface. Translations are contributed through a process documented at docs.baby-buddy.net/contributing/translation/, and the README credits "numerous translators" for the roughly two dozen locales. If you depend on a less common locale, its coverage is a function of volunteer effort rather than of the project's release schedule.
The licence does not add cost. BSD-2-Clause imposes no obligation to publish modifications, so a private fork for household use carries no distribution requirement. Again, that is a reading of the licence identifier in the material, not legal advice.
Editorial conclusion
Adopt Baby Buddy if you already run a server, want the raw event data in your own database, and are willing to treat it as a long-lived Django deployment rather than an app. Do not adopt it if you need a native mobile client as the primary interface, if nobody in the household will maintain a Python service, or if you expect the project to tell you what your baby's data means; it records and displays, and the README's promise of predicting needs is not backed by anything described in the material. Before committing, verify three things: that the demo at demo.baby-buddy.net covers the event types you actually log, that the API endpoints you need are documented at docs.baby-buddy.net, and that your backup routine captures both the database and the uploaded media, because the repository material does not describe an export path that would let you leave cleanly.
Community notes