Self-hosted collaborative shopping lists, honestly reviewed. No marketing fluff, just what you actually get.

TL;DR

What it is: A simple Node/VueJS shared list application. The name is literal — you run it on your own server, and everyone in your household shares a real-time list [2].
Who it’s for: Households and small teams who want a fast, mobile-first shared shopping list with zero monthly fees and no dependency on Google Keep, AnyList, or OurGroceries servers.
Cost savings: Shopping list apps like AnyList run $12–15/yr per person or family plan. Not expensive in isolation, but once you’re already running a home server, OSL costs nothing to add.
Key strength: Extremely focused scope. It does shared lists with real-time sync, mobile swipe gestures, and multiple boards — and doesn’t try to also track your pantry inventory, manage recipes, or become a household ERP [2][README].
Key weakness: 178 GitHub stars, AGPL-3.0 license, no offline mode, no authentication system — anyone who knows your instance URL can read and edit your lists [README][2]. Not a tool you expose to the public internet without a VPN or auth layer in front.

What is Our Shopping List

Our Shopping List (OSL) is a web application built on Node.js and VueJS with a MongoDB backend. The stated purpose is exactly what the name says: a shared list app for households, with shopping lists as the primary use case [README].

The project is maintained by a single developer (nanawel on GitHub), has 178 stars, and is licensed under AGPL-3.0, which means you can self-host it freely but any modifications you distribute must be open-sourced [README][2].

What distinguishes OSL from the generic “collaborative to-do list” category is a handful of deliberately chosen design decisions. The UI is mobile-first with swipeable list items — the swipe-to-check interaction feels native on iOS and Android rather than like a desktop UI crammed into a small screen [README]. Items support three fields: name, quantity, and details — simple enough that a non-technical family member won’t need a tutorial [README]. Real-time sync means changes appear on other devices immediately without a manual refresh.

Version 2 introduced boards — a way to group lists under a shared name. Before v2, every list on an instance was visible to every user. Now you can create a board for “Smith Family Shopping” and share just that board’s URL with your household, keeping other boards private by obscurity [README][2]. The v1→v2 migration requires a CLI tool and a data backup, which is worth knowing before you upgrade a running instance [README].

The project also recently added CSV paste import: you can paste a comma-separated list into the search field and bulk-create items, which is useful if you maintain your shopping list in a spreadsheet or notes app [README]. There’s also basic PWA support, meaning it can be added to your phone’s home screen — though full offline mode with deferred sync is explicitly listed as a missing feature [README][2].

At 178 GitHub stars, this is a small project. It’s not in the same conversation as KitchenOwl, Mealie, or Grocy in terms of community size. What it trades away in ecosystem, it gains in simplicity — the codebase is narrow enough that a single developer has kept it maintained and actively developed through two major versions [README].

Why people choose it

The direct third-party reviews of Our Shopping List are sparse — this is a small project, not one the tech press has covered. But the broader articles about self-hosted grocery and list tools provide useful context for who ends up choosing OSL [3][5].

The dominant reason, from what r/selfhosted threads and hosting guides reflect, is scope discipline. The XDA Developers review of Grocy [3] captures the problem this solves: a writer tried Grocy — the comprehensive household management tool — and abandoned it after a week because it required too much discipline to maintain. “Grocy expects me to log inventory updates anytime I pull something out of the fridge or add something to it. That’s great — in theory. But if I were disciplined enough to keep up with that, I probably wouldn’t need an app like Grocy in the first place.” [3]

OSL is the antidote to that pattern. There’s no inventory to maintain. No product database to build. No expiry dates to track. You add an item, someone buys it, someone checks it off. That’s the entire loop.

The MariusHosting roundup of Docker grocery apps [5] lists seven alternatives — Mealie, Tandoor, KitchenOwl, Grocy, RecipeSage, Norish, Bar Assistant — and none of them are described as “just a shared list.” They all bundle recipe management, meal planning, or pantry tracking alongside the shopping list. If you want the shopping list without the surrounding complexity, OSL is one of the few options that doesn’t force a bundle.

The HomeHub article [4] illustrates the opposite end of the spectrum: all-in-one household hubs that fold the shopping list into a larger system alongside chores, expenses, calendars, and files. HomeHub’s shopping list suggests items based on past entries [4] — smarter, but also more infrastructure. For a household that just wants a list that syncs in real time, that intelligence is unnecessary overhead.

The Reddit post [1] about a competing app called “Shopping” highlights one feature gap in OSL worth noting: aisle-based ordering. The competing app lets you associate items with specific store sections so your list follows the store’s physical layout [1]. OSL doesn’t do this — items are sorted by check status and check time, not by aisle. If you shop at the same store every week with a predictable layout, that’s a real missing feature.

Features

Based on the README and the libreselfhosted.com listing:

Core list functionality:

Multiple boards (optional; disable with VITE_APP_SINGLEBOARD_MODE=1 for a single shared space) [README][2]
Each board supports multiple lists [README]
Items with name, quantity, and details fields [README]
Checkable items with two display modes: unchecked items only, or checked items only sorted by check time [README]
Intuitive in-app search [README]
Mass item creation by pasting CSV into the search field [README]

Sync and mobile:

Real-time sync between all connected users — no refresh needed [README][2]
Mobile-first UI with swipeable items [README]
Basic PWA support — installable to home screen [README][2]
No offline mode — explicitly listed as a missing feature; requires network connectivity [README][2]

Deployment:

Docker and Docker Compose support [README][2]
MongoDB backend (4.x required) [README][2]
CLI tool for board and list migration operations [README]

i18n:

Multiple languages available via Weblate community translations [README]
Originally only EN and FR; additional languages contributed by community [README][2]

What’s missing or limited:

No authentication or user accounts — access is controlled by who has the board URL [README]
No aisle/section ordering [1]
No recipe integration or meal planning [5]
No pantry inventory tracking [3]
No offline/deferred sync — this is explicitly acknowledged in the README as a known gap [README][2]
REST API is listed as a canonical feature in the project profile, but the README doesn’t document a public API surface — treat this as internal/undocumented

Pricing: SaaS vs self-hosted math

Our Shopping List has no SaaS tier — it’s self-hosted only.

What you’d pay for comparable commercial apps:

AnyList: ~$12–15/yr for premium features including offline access and family sharing
OurGroceries: family subscription in a similar range
Bring! Grocery Shopping List: free with optional premium
Google Keep: free, but your list data lives on Google’s servers with no data portability guarantee

Self-hosted OSL:

Software license: $0 (AGPL-3.0) [README]
Infrastructure: if you’re already running a home server or NAS, the incremental cost is near zero — MongoDB and Node.js are lightweight
Fresh VPS just for OSL: a $4–6/mo Hetzner or Contabo instance is significant overkill; you’d only run OSL standalone if you’re also running other services on the same server
Domain + reverse proxy: needed for HTTPS, which is needed for PWA install and reliable mobile experience

The honest math here is that you don’t self-host OSL to save money on a $12/yr app. You self-host it because you want your grocery data on your own infrastructure, or because you’re already running a home server and adding one more Docker container costs effectively nothing.

If saving $12/yr is the only goal, stay on the free tier of any commercial app.

Deployment reality check

The standard path is Docker Compose with a MongoDB container. The libreselfhosted.com listing shows a single docker run command with a --link mymongo:mongodb flag, which implies MongoDB runs separately [2]. The docker-compose file in the repository handles both services together.

What you need:

A Linux host with Docker installed
MongoDB 4.x (bundled via docker-compose or external)
A reverse proxy (Caddy or nginx) for HTTPS — required if you want the PWA install to work on iOS/Android
A domain or subdomain pointing at your host

Time estimate: 30–45 minutes for a technical user comfortable with Docker and a reverse proxy. For someone deploying their first Docker app with HTTPS, budget 2–3 hours including DNS propagation.

The v1→v2 migration gotcha: If you’re upgrading an existing OSL instance, version 2’s boards feature changes the data model. You must run CLI commands to migrate existing lists to a board before they’re accessible again [README][2]. The README warns explicitly: “Back up your data before proceeding.” This is a real step — not optional boilerplate. Missing it means your lists become inaccessible (not deleted, but not reachable through the UI) [README].

The authentication gap: OSL has no login system. Boards are accessed by name — share the board name, and anyone can read and edit it. This is fine on a home network behind a VPN, or for a household where everyone gets the URL. It’s a problem if you expose the instance directly to the internet without an auth layer. A basic HTTP auth via your reverse proxy (Caddy’s basicauth directive, for example) is the common workaround, but it’s not built in [README].

MongoDB dependency: MongoDB is a heavier backend than SQLite or Postgres for a list app of this scope. If you’re running on a Raspberry Pi or a low-RAM VPS alongside other services, monitor memory usage. MongoDB 4.x on a constrained host can be the bottleneck.

Pros and cons

Pros

Genuinely focused. Does one thing — shared lists — without scope creep into recipes, pantry tracking, or household management [README]. The Grocy experience [3] is a cautionary tale about what happens when you choose the complex tool when you needed the simple one.
Real-time sync that works. Changes appear on other connected devices immediately [README][2]. This is the core feature and it works correctly.
Mobile-first UX. Swipeable items, a layout that doesn’t feel like a desktop app zoomed out, installable as a PWA — functional on a phone without an app store dependency [README].
Boards for household segmentation. Multiple boards mean different households or use cases can share one instance without seeing each other’s lists [README][2].
CSV paste import. Bulk add items from a spreadsheet or notes app — practical for anyone who plans their shop in advance [README].
AGPL-3.0 and self-hosted. Your list data stays on your hardware. No vendor can discontinue the service or change the pricing model on you.
Active maintenance. Two major versions shipped, CLI migration tooling provided, i18n via Weblate, ongoing commits — this isn’t abandoned software [README].

Cons

No authentication. Access is by URL/board name. Not safe to expose without an auth layer on the reverse proxy [README]. This is the single most important limitation for most self-hosters.
No offline mode. The README explicitly lists this as a known missing feature [README][2]. In areas with spotty cell signal (exactly where you’re likely using a shopping list), this matters.
No aisle ordering. The competing “Shopping” app on r/selfhosted [1] highlights this gap — OSL sorts by check status, not by store layout. For people who shop the same store weekly, this is a real usability deficit.
MongoDB dependency. Heavier than necessary for a list app. A low-power host may struggle, and MongoDB backups require slightly more care than a flat file or SQLite database.
178 stars. This is a one-maintainer project with a small community. Not a death sentence, but a risk factor if your household depends on it. Compared to KitchenOwl or Mealie, the bus factor is higher [README].
AGPL-3.0, not MIT. If you want to embed this in a commercial product or fork it into a service, the copyleft license requires publishing your modifications. For personal self-hosting this doesn’t matter, but it’s worth knowing [2].
No recipe or pantry integration. If you eventually want to generate a shopping list from a meal plan, you’ll need a separate tool [5]. OSL is intentionally not that — but if your needs grow, you’ll outgrow it.

Who should use this / who shouldn’t

Use Our Shopping List if:

You want a shared shopping list that syncs in real time and works well on mobile.
You’re already running a home server or NAS and adding one Docker container is trivial.
You tried Grocy or another full-featured household management tool and found the overhead wasn’t worth it [3].
Your household has non-technical members who need something dead simple — no accounts, no learning curve, just a URL and a list.
You want your grocery data on your own hardware, not Apple’s or Google’s.

Skip it (use Grocy or KitchenOwl) if:

You want to track pantry inventory, set expiry alerts, or generate shopping lists from a meal plan [3][5].
You need recipe management alongside your lists [5].
You want aisle-based ordering that matches your store’s physical layout [1].

Skip it (use HomeHub) if:

You want a broader household hub — chores, expenses, calendar, files — and the shopping list is just one piece [4].

Skip it (use a commercial app) if:

You need reliable offline access — OSL explicitly doesn’t support this yet [README][2].
You’re not running any home server infrastructure and don’t plan to — a $12/yr AnyList subscription is the correct answer.
You want iOS/Android native apps from an app store — OSL is a PWA, which works well but isn’t an App Store download.

Alternatives worth considering

From the MariusHosting roundup [5] and broader context:

KitchenOwl — Self-hosted grocery list + recipe manager + expense tracker. More capable than OSL, more setup. The natural next step if OSL’s scope feels too narrow [5].
Mealie — Recipe manager with shopping list integration. Better if recipe-driven meal planning is the goal [5].
Grocy — Full household management: pantry, shopping, chores, tasks. Powerful but requires significant discipline to maintain [3][5]. The XDA review [3] is a clear-eyed account of where it breaks down for normal households.
HomeHub — All-in-one family hub with shopping list, chores, calendar, expenses, files [4]. Choose it if you want everything in one container.
Tandoor Recipes — Recipe-first with shopping list integration [5]. Good for households that cook from a consistent recipe library.
“Shopping” (smallcodebases) — The r/selfhosted post [1] describes a newer competitor with aisle-based ordering. Fewer stars than OSL but fills a specific gap OSL doesn’t.
Google Keep / Apple Reminders — Free, offline-capable, no infrastructure to maintain. The correct answer if self-hosting isn’t already part of your setup.

Bottom line

Our Shopping List is not trying to replace Grocy, not trying to be KitchenOwl, not trying to manage your whole household. It’s a focused, mobile-first, real-time shared list app — and within that scope it does what it promises. The boards system handles multi-household instances, the mobile UX is genuinely usable, and real-time sync works. The gaps are honest and documented: no offline mode, no authentication built in, no aisle ordering, MongoDB overhead that feels heavy for a list app. At 178 stars it’s a small project with the reliability risks that implies.

For a household already running a home server that wants to stop sharing a Google Keep list, OSL is a clean, low-overhead choice. For anyone whose primary constraint is offline access or who wants lists auto-generated from a meal plan, look at KitchenOwl or Mealie instead. The self-hosting overhead is real regardless of which tool you choose — if you need someone to deploy and configure it for you, that’s what upready.dev handles.