KitchenOwl: a self-hosted grocery list and recipe manager built on Flask and Flutter
KitchenOwl is a self-hosted grocery list and recipe manager. The backend is made with Flask and the frontend with Flutter. Easily add items to your shopping list before you go shopping. You can also create recipes and add items based on what you want to cook.
At a glance
- What is it?
- KitchenOwl pairs a Flutter client with a Flask backend to sync shopping lists, recipes, meal plans and shared household expenses. It is still labelled a public alpha, so the decision hinges on whether you want to run the server yourself and accept partial offline behaviour.
- Who is it for?
- Adopt KitchenOwl if you want your household's shopping list, recipes, meal plan and shared balances on a server you control, and you are comfortable running a Flask backend behind a Docker image while the project is still in public alpha. Skip it if you need a hardened, guaranteed-stable service, or if you cannot tolerate the documented partial offline support.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 18 days ago.
- What is it written in?
- Mainly Dart, 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 household coordination problem KitchenOwl targets
A shared shopping list is one of those problems that looks trivial until more than one person edits it. Two people add the same item, one buys it, the other keeps it on the list, and the list stops being trusted. KitchenOwl's answer is a server that holds the list, with clients on Android, iOS, web, desktop and Home Assistant all reading and writing to it. The README describes real-time sync between multiple users and a recipe manager that can push ingredients straight onto the shopping list, so the list and the cooking plan are the same data rather than two apps that never talk.
The audience is narrower than a general notes app. It is for a household that already runs something at home, or is willing to, and wants the grocery list to sit next to the recipes and the shared spending record. The expense tracking feature is what separates it from a plain checklist: the README frames balances and household expenses as a first-class part of the product, not an add-on. If you only need a checklist that syncs, this is more machinery than the job requires.
Flask backend, Flutter clients, and where the state lives
The repository is a Dart project by primary language because the Flutter client is the bulk of the code, but the README is explicit that the backend is Flask. The two halves are distributed separately: the Flutter apps ship through Google Play, F-Droid and the App Store, while the server side is published as a Docker image under tombursch/kitchenowl. There is also a separate kitchenowl-backend repository listed under Related, which suggests the server code is not necessarily where you would first look for it.
The data flow implied by the README is client to backend to client: a user adds an item, the Flask server persists it, and other connected clients receive the change in real time. Recipe scraping is handled by the recipe-scrapers library, so importing a recipe from a web page is a server-side operation rather than something the phone parses locally. The README also mentions a Python client and a Home Assistant integration, both of which point at the same backend API rather than at each other.
What the README does not give is a schema, an API reference, or a description of how conflicts between two offline clients are resolved. That is a gap worth noting rather than guessing about.
Partial offline support and what it does not cover
The README's phrasing is careful: "Partial offline support, so you don't lose track of what to buy even when there is no signal." Partial is the operative word. The project does not claim a full offline-first model with conflict resolution on reconnect, and nothing in the supplied material describes how a change made offline merges with a change made on another device in the meantime.
For a shopping list this is usually tolerable. You are in a supermarket basement, you tick off items, and the sync catches up when you surface. The failure mode to think about is two people editing the same list while one is offline: without a documented merge rule, the safe assumption is that the last write to reach the server wins, though the README does not state this. If your household routinely has one person offline for long stretches, treat the offline behaviour as something to verify on a test instance before you rely on it.
Getting a server running from the documented entry points
The README does not inline the deployment commands. It routes you to the get started guide at docs.kitchenowl.org/latest/self-hosting/, and that is the only authoritative source for the current procedure. What the repository does establish is the shape of the deployment: a Docker image, tombursch/kitchenowl, published on DockerHub, with the backend written in Flask. The clients are installed separately from the app stores or from the GitHub releases page for desktop builds.
Because the exact compose file, environment variables and volume layout are not in the README, I will not reproduce them here. Anyone writing them from memory is inventing them. The practical path is to open the self-hosting page, take the compose example as published, and pin the image tag rather than tracking latest, since the release cadence is visible in the repository: v0.7.8 in April 2026, v0.7.9 in June, v0.7.10 in July. A pinned tag means an upgrade is a deliberate edit to one line, not a surprise on the next container restart.
The alpha label is a real constraint, not a disclaimer
The README's status block is unusually direct for a project with app store listings. Public Alpha is checked, with the note "Still working on stuff (rarely things might break)." Public Beta and Public are unchecked. The same README says the project is still in development.
That combination matters because KitchenOwl is not a weekend script. It stores a household's shared spending record and the list that determines whether dinner gets bought. A breaking change in a recipe schema or an expense table is not cosmetic. The release history shows a steady patch cadence through 2026, which is a good sign for responsiveness, but cadence is not the same as a stability guarantee, and the project does not make one.
The second constraint is licensing. KitchenOwl is AGPL-3.0, which the README describes as free to use, study, share and improve. For a household running it at home, that is unremarkable. For anyone who wants to offer a modified KitchenOwl as a network service, the AGPL's network clause is the part to read carefully, and that is a question for a lawyer rather than for this article.
Where KitchenOwl is the wrong tool
If the requirement is a shopping list that works identically with no server at all, KitchenOwl is the wrong shape. It assumes a backend exists and that clients reach it. A peer-to-peer or purely local list app has no server to patch, no container to restart and no database to back up; KitchenOwl trades that simplicity for shared state across a household and across devices.
It is also the wrong tool if the expense tracking needs to satisfy an accountant. The README describes managing balances and tracking expenses of your household. It does not describe double-entry accounting, audit trails, receipt attachment or export formats. Treating it as a lightweight shared ledger is reasonable. Treating it as bookkeeping software is not something the material supports.
Finally, if you need an integration that is not on the list, the README points at a Python client and a Home Assistant integration and stops there. There is no plugin system described, so extending it means working against the Flask API directly.
How KitchenOwl differs from Grocy
The obvious comparison in self-hosted kitchen software is Grocy, which also runs on a server you host and also covers shopping lists and stock. The difference in approach is what each one treats as the centre of the model. Grocy is built around inventory: quantities in the pantry, consumption, expiry, and a shopping list derived from what is running low. KitchenOwl, as described in its README, is built around the list and the recipe: you add items before you shop, you add recipe ingredients to the list, and you plan meals. Stock tracking is not part of the feature set the README lists.
That changes who each one suits. A household that wants to know it has two tins of tomatoes and one expires next month wants an inventory tool. A household that wants a shared list that both people trust, plus recipes that feed into it, wants what KitchenOwl describes. Choosing between them is mostly a question of whether your problem is knowing what you have or agreeing on what to buy.
The other difference worth weighing is the client story. KitchenOwl ships native apps through Google Play, F-Droid and the App Store, plus desktop builds from the releases page. That is a lower barrier for the non-technical half of a household than a web-only interface, and it is the part of KitchenOwl that is hardest to replicate with a smaller project.
Maintenance load and the upgrade question
Running KitchenOwl means running a Flask service, a database behind it, and a container image you keep current. The upgrade cost is the recurring one: the repository shows releases roughly every six to eight weeks through 2026, and each one is a chance for a schema change. Pinning the Docker tag and reading the release notes before moving is the difference between a five-minute upgrade and an evening of recovery.
The client side has its own cost. Mobile apps update through the stores, so a phone may reach a newer client version than your pinned server. Whether that mismatch is tolerated is not documented in the supplied material, and it is one of the first things to test on a staging instance rather than on the household's live list.
On licensing, AGPL-3.0 means the source stays open and modifications you distribute carry the same terms. Self-hosting for your own household does not trigger distribution. Running a modified version as a public service does, and the boundary between those two is a legal question, not a technical one. Nothing here is legal advice.
Editorial conclusion
Adopt KitchenOwl if you want your household's shopping list, recipes, meal plan and shared balances on a server you control, and you are comfortable running a Flask backend behind a Docker image while the project is still in public alpha. Skip it if you need a hardened, guaranteed-stable service, or if you cannot tolerate the documented partial offline support. Before committing, read the self-hosting guide at docs.kitchenowl.org/latest/self-hosting/, confirm the current Docker image tag for tombursch/kitchenowl, and check the release notes for the version you plan to pin.
Community notes