Self-hosted recipe management, honestly reviewed. What you get when you replace the SaaS apps with a Docker container on your own server.

TL;DR

What it is: GPL-3.0 licensed recipe manager web app — think Paprika or Plan to Eat, but the server is yours and there’s no monthly bill [README][1].
Who it’s for: Home cooks, meal preppers, and food bloggers who want all their recipes in one place, private by default, accessible from any device, without paying a subscription indefinitely.
Cost savings: Plan to Eat runs $4.99/mo ($60/yr). Paprika is $4.99 one-time per platform but splits across devices. Tamari self-hosted runs on a $5–6/mo VPS with unlimited accounts and recipes, or $0 if you use the free public instance at app.tamariapp.com.
Key strength: More complete than you’d expect from a 117-star project — recipe storage, meal planning, shopping lists with barcode scanning, and a built-in Explore database of 107,000+ recipes scraped from 50 sites. Plus a REST API [README].
Key weakness: Single developer, small community, GPL license means embedding in commercial products requires care, and there’s essentially no critical third-party coverage to validate real-world stability claims.

What is Tamari

Tamari is a self-hosted recipe manager web application built by developer Alex Bates using Python and the Flask framework. It stores your personal recipes, plans your meals, manages your shopping lists, and lets you browse a curated collection of over 107,000 external recipes without leaving the app [README].

The name, in this context, is a bit of a search-engine problem: the word “tamari” returns roughly 95% results about Japanese soy sauce before the app appears anywhere. That’s not a product critique — just context for why you’ve probably never heard of it despite it being a fully functional piece of software.

What distinguishes Tamari from the dozen other open-source recipe managers floating around GitHub is the combination of: a usable public instance so you can try it before touching Docker, the Explore feature that scrapes and parses recipes from 50 external sites on demand, and the barcode scanner in the shopping list flow — a detail that suggests the developer actually uses this thing rather than built it as a portfolio piece [README][website].

As of this review the project sits at 117 GitHub stars with 7 forks and was last updated in January 2026. It’s a small project by any measure. If you’re looking for a community-maintained open-source heavyweight with 20,000+ stars and 300 contributors, this isn’t it. If you want a clean, working recipe manager you can self-host in under 10 minutes, it is.

Why people choose it

The honest answer, given the data available, is: people find Tamari because they’re looking for a self-hosted alternative to Paprika, Whisk, or Plan to Eat, and it’s one of the few genuinely complete options that isn’t abandoned or half-built [1].

AlternativeTo users have listed Tamari as an alternative to Foodies.com, Sift Recipe Keeper, Meal37, PrepMate, and GourmetLog — a pattern that suggests people are escaping niche paid apps or dead freemium projects more than leaving mainstream SaaS giants [1]. The listed alternatives on AlternativeTo (ManageMeals, Recipya, kitshn) are all small projects in the same tier, which tells you something about the self-hosted recipe manager space: it’s not a crowded market of mature options.

There are no independent written reviews of the app beyond the AlternativeTo listing. The project’s forum presence on GitHub issues is the closest thing to user feedback. The public instance at app.tamariapp.com makes this easy to evaluate before committing to a server setup — a rare practical touch for a project this size.

The absence of reviews is itself information. This is niche software for a specific type of person who wants digital recipe ownership without ongoing fees. It’s not trying to replace Notion or disrupt the recipe management industry.

Features: what it actually does

Recipe management:

Store title, category, description, time estimates, servings, source URL, nutrition info, ingredients, instructions, and a photo per recipe [README]
If no photo is uploaded, a random cooking-themed placeholder is assigned automatically [README]
Mark off individual ingredients while cooking on the recipe detail page [README]
Real-time search-as-you-type across your recipes [README]
Recipes are private by default; you can make individual recipes public and share a direct URL [README]
Mark as Favorites; assign categories and browse by category [README][website]

Meal planning:

Plan meals up to 30 days in advance [README][website]
Assign specific recipes to specific dates from the Meal Planner view [README]

Shopping lists:

Multiple shopping lists, one per store [README]
Add all ingredients from a recipe to a list with one click [README]
Check off items as you shop [README]
Barcode scanner for adding list items without typing [README]

Explore:

Browse and search a database of over 107,000 recipes from 50 recipe-sharing websites [README]
Tamari fetches and parses the recipe data from the source URL in the background — you never leave the app [website]
One-click import into My Recipes [README][website]

Customization:

Light and dark themes [README]
Four profile pictures and a customizable accent color per account [README]
Choose large or small photo display mode [README]
Sort recipes by title or date added [README]
Instance-wide settings for recipes per page and dynamic image loading [README]
Font size selection [website]

Technical features:

Multi-user support with individual accounts [README]
REST API for programmatic access to recipes, shopping lists, and meal plans [README]
Import/export via ZIP backup [website][docs]
Responsive — works on phones, tablets, and desktops [README]
Optional email-based password reset (requires SMTP configuration) [README]
Save as standalone web app on iPhone/iPad (documented) [docs]

What’s notably absent: no recipe scaling interface (adjusting servings), no tagging system beyond categories, no collaborative features for households, and no built-in recipe import from URLs in the standard flow outside the Explore feature.

Pricing: SaaS vs self-hosted math

Tamari has no SaaS tier. The options are self-hosting or using the free public instance.

Free public instance (app.tamariapp.com):

$0. Create an account, use it. Full features. You’re trusting one developer’s server and uptime.

Self-hosted:

Software: $0 (GPL-3.0)
VPS: $5–6/mo on Hetzner, Contabo, or similar. A single Docker container with a small SQLite or volume-backed data store won’t stress a 2GB RAM VPS.
Your time to deploy: under 10 minutes with Docker if you’ve done this before.

What the paid alternatives cost:

Plan to Eat: $4.99/mo ($59.88/yr). Web-based, clean, well-maintained, closed source. No self-host option.
Paprika Recipe Manager: $4.99 one-time per platform (iOS, Android, Mac, Windows sold separately). No web app. The $20 to own it across all your devices still doesn’t give you a shared web interface or API.
Mealime: Free tier, Pro at $5.99/mo. Focused on meal prep with nutrition tracking — less flexible for arbitrary recipe storage.
Whisk (by Samsung Food): Free, but Samsung-owned with unclear long-term trajectory. No self-host option.
Yummly (Whirlpool): Free with premium upsells. Ad-supported. Corporate-owned.

The math for a family using Plan to Eat:

$4.99/mo × 12 = $59.88/yr. Over 3 years: $179.64. Tamari self-hosted on a $6 Hetzner VPS, shared with other services: effectively $0–$6/mo depending on what else you run. If Tamari is the only thing on the box, $72/yr — roughly the same as Plan to Eat, but with unlimited accounts and full data ownership.

If you already run a home server or a VPS for other self-hosted services, Tamari costs nothing beyond a Docker run command.

Deployment reality check

The Docker command in the README is one line [README]:

docker run -d --restart=always -p 4888:4888 -v tamariappdata:/app/appdata --name tamari alexbates/tamari:1.4

That’s it. The container runs on port 4888, stores data in a named volume, and restarts on reboot. No database setup, no environment file to configure (unless you want email), no compose file required for the base case.

What you actually need:

Any Linux machine running Docker (VPS, home server, Raspberry Pi)
If you want HTTPS and a domain: a reverse proxy (Caddy one-liner, or nginx) and a DNS record
If you want password reset by email: SMTP credentials from any email provider (Gmail, Fastmail, Mailgun)

Manual installation on Debian 12 or Ubuntu 24.10 is also documented step-by-step in the README — Python venv, pip install, Flask DB migration, gunicorn. It’s not elegant but it works and the instructions are complete [README].

Documentation coverage is reasonable for a project this size. The docs page at tamariapp.com/docs covers usage, standalone web app setup (iOS), import/export, keyboard shortcuts, API reference, self-hosting, Docker, manual install, autostart, mail settings, reverse proxy, upgrading, and backups [docs]. All the topics a real user hits are documented.

What can go sideways:

The public Docker image is pinned to version tag 1.4 in the README command. If you pull latest instead, you may get an untested build.
GPL-3.0 license means if you embed this in a commercial product or service, the GPL copyleft provisions apply. For personal self-hosting this is irrelevant. For building a business on top of it, it’s a conversation with a lawyer.
The Explore feature scrapes third-party recipe sites. Any site that changes its HTML structure or blocks scrapers will break imports from that source. This is inherent to the approach, not a fixable bug.
With 117 stars and one developer, there’s no commercial entity backing this. Feature requests and bug fixes move at one person’s pace. If the developer stops maintaining it, the software still works — it’s not SaaS — but it won’t evolve.
No mention of database engine in the base Docker deployment. The volume-backed storage works, but for larger personal collections or multi-user deployments, verifying the backup strategy before adding 500 recipes is worth the 5 minutes it takes [docs].

Realistic time estimate for a technical user: 10–20 minutes to a working HTTPS instance. For a non-technical user following the Docker guide with no prior self-hosting experience: 1–3 hours including domain setup and reverse proxy.

Pros and cons

Pros

Single Docker command to deploy. Genuinely the simplest deployment of any recipe manager in this category. No docker-compose, no separate database container, no multi-step initialization [README].
Free public instance. app.tamariapp.com lets you evaluate the full feature set without installing anything. Rare and useful for a project this small.
107,000+ recipe Explore database. The in-app recipe discovery and one-click import from 50 external sites is more useful than it sounds — you don’t need to keep another app open, copy-paste ingredients, or fight with paywalled recipe sites [README][website].
REST API included. Programmatic access to recipes, shopping lists, and meal plans is not a given in this category. It’s there [README].
Barcode scanner in shopping lists. Small detail, real usefulness at the grocery store [README].
Recipes are private by default. You opt in to sharing, not out. The right default [README].
Genuinely responsive. Works on phones and tablets — the developer documented the iOS standalone web app setup specifically [docs].
Import/export backup. ZIP-based full account export so you’re never locked in [website][docs].

Cons

One-developer project with 117 stars. If Alex Bates stops working on this tomorrow, you have working software but no upstream bug fixes or new features. There’s no community or company to absorb that.
GPL-3.0, not MIT or Apache. For personal use, irrelevant. For anyone building a business or service on top of it, the copyleft clause matters [1].
No recipe URL import in the standard flow. The Explore feature can fetch recipes, but there’s no “paste a URL from any site” import field outside of that curated 50-site database. If a site isn’t in the Explore index, you’re copying manually.
No recipe scaling. Adjusting a recipe from 4 servings to 6 is manual math. Common feature in paid apps, absent here.
No household/collaborative features. Multiple users can have accounts on the same instance, but there’s no shared recipe library or collaborative shopping list between accounts.
Minimal external validation. No Trustpilot, no G2, no independent written reviews beyond an AlternativeTo listing [1]. You’re evaluating this primarily on the README and by using the public instance.
SEO invisibility. The word “tamari” returns soy sauce results first. If something breaks and you search for help, community resources are thin.
No recipe scaling, tagging, or nutritional goal tracking. If you came from Mealime or Cronometer expecting those workflows, they’re not here.

Who should use this / who shouldn’t

Use Tamari if:

You’re paying for Plan to Eat, Paprika, or a similar recipe app and the ongoing cost annoys you — the math only gets better over time once you’re on your own VPS.
You already run a self-hosted server and adding one more Docker container is trivially easy.
You want to own your recipe data, not have it stored on someone else’s servers behind a subscription.
You want an API to automate things like adding recipes from a meal planning script or reading your shopping list from a home automation system.
You want to try it before committing to anything — app.tamariapp.com exists for exactly this.

Skip it (use the public instance only) if:

You have no experience with Docker or self-hosting and no one to help you set it up. The public instance gives you the same app experience without the server management.

Skip it (pick Mealie or Tandoor) if:

You want a larger self-hosted community, more active development, and a project with thousands of GitHub stars behind it. Mealie and Tandoor Recipes are the more established options in this category with more contributors and ecosystem integrations.
You need deep Home Assistant or Nextcloud integration — those ecosystems have built more around Mealie specifically.

Skip it (stay on Paprika) if:

You’re heavily invested in Paprika’s native iOS/Mac app quality. Web apps running in Safari don’t match the native app polish for recipe step-through while cooking.

Skip it (stay on Plan to Eat) if:

You value a managed service with customer support and reliable uptime over data ownership and cost savings.

Alternatives worth considering

Mealie — The most popular self-hosted recipe manager, significantly more active development, 8,000+ GitHub stars, Home Assistant integration, meal planning, shopping lists. More complex to deploy (docker-compose with a database container). If Tamari’s size concerns you, Mealie is the mature alternative.
Tandoor Recipes — Django-based, strong community, 5,000+ GitHub stars, supports recipe imports via a browser extension, better collaborative features. Heavier than Tamari but more extensible.
Recipya — Newer Go-based project, noted on AlternativeTo as a comparable option [1]. Smaller than Mealie but faster binary.
kitshn — Also listed as a Tamari alternative [1]. Lighter, mobile-first design philosophy.
ManageMeals — Listed as an alternative [1]. Nutrition tracking focus.
Plan to Eat — The honest paid alternative if self-hosting isn’t for you. $4.99/mo, well-maintained, clean interface.
Paprika Recipe Manager — Best choice if you live in native iOS/Mac apps and don’t need a web interface.

For a non-technical founder or home cook evaluating options: the realistic shortlist is Tamari vs Mealie. Tamari wins on deployment simplicity. Mealie wins on community, features, and ecosystem depth. If you want it running in 10 minutes, pick Tamari. If you want the more mature option with Home Assistant integration and a large user base, pick Mealie.

Bottom line

Tamari is a complete recipe manager that does exactly what it says on the tin — stores your recipes, plans your meals, manages your shopping lists, and lets you browse a large external recipe database, all self-hosted for the cost of running a Docker container. It’s not going to displace the major players in self-hosted recipe management, and the single-developer, 117-star reality means you’re betting on one person’s continued interest. But the deployment is genuinely simple, the public demo is available to evaluate immediately, and the feature set is more complete than most projects at this community size. If you’re paying $5/mo for Plan to Eat or maintaining a multi-device Paprika license and you already have a home server, the trade-off is obvious. If you don’t self-host anything currently and this would be your first Docker deployment, test the public instance first and decide whether the experience is worth adding server management to your life.